Bagaimana untuk menyelesaikan masalah transaksi diedarkan Java Spring Boot

1. Apakah itu pampasan terbalik

Pertama sekali, izinkan saya menerangkan istilah kepada anda Apabila anda melihat maklumat yang berkaitan dengan transaksi yang diedarkan, anda akan sering melihat istilah: Pampasan terbalik<.>. Apakah pampasan terbalik?

Ia melalui kemas kini SQL, dan kemudian perubahan dalam pemulihan data perkhidmatan B .

Terdapat tiga konsep teras dalam Seata:

• TC (Penyelaras Transaksi) - penyelarasan transaksi Pengarang: Mengekalkan status urus niaga global dan cawangan, dan memacu penyerahan atau pemulangan transaksi global.

• TM (Pengurus Urus Niaga) - Pengurus Transaksi: Tentukan skop transaksi global, mulakan urus niaga global, lakukan atau tarik balik urus niaga global.

• RM (Pengurus Sumber) - Pengurus Sumber: mengurus sumber (Sumber) untuk pemprosesan transaksi cawangan, berbincang dengan TC untuk mendaftar transaksi cawangan dan melaporkan status transaksi cawangan, dan memacu cawangan transaksi Komit atau tarik balik.

Mari kita lihat gambar berikut:

Dengan kata lain, di manakah anotasi ini harus ditambah? Tempat untuk menambah anotasi ini sebenarnya adalah pengurus transaksi TM. @GlobalTransactional

Pertama lihat gambar berikut:

Gambar ini melibatkan tiga konsep:

• AP: Tidak perlu dikatakan, AP ialah aplikasi itu sendiri.

• RM: RM ialah pengurus sumber, yang merupakan peserta transaksi Dalam kebanyakan kes, ia merujuk kepada pangkalan data A urus niaga yang diedarkan sering melibatkan berbilang RM.

• TM: TM ialah pengurus urus niaga, yang mencipta transaksi teragih dan menyelaraskan pelaksanaan dan status setiap sub-urus niaga dalam urus niaga yang diedarkan kepada Operasi khusus yang dilakukan pada RM.

Contohnya, gambar berikut:

Ini dipanggil komit dua fasa.

Untuk meringkaskan: Dalam penyerahan dua fasa, urus niaga dibahagikan kepada peserta (seperti setiap perkhidmatan khusus dalam gambar di atas) dan penyelaras akan memberitahu penyelaras tentang kejayaan atau kegagalan operasi , dan kemudian penyelaras akan menentukan kejayaan atau kegagalan operasi berdasarkan keputusan semua peserta Maklumat maklum balas menentukan sama ada setiap peserta harus menyerahkan operasi atau menggugurkan operasi Peserta di sini boleh difahami sebagai RM, dan penyelaras boleh difahami sebagai TM.

Walau bagaimanapun, pelbagai mod urus niaga yang diedarkan dalam Seata pada asasnya berkembang berdasarkan penyerahan dua fasa, jadi ia tidak betul-betul sama.

4. Mod AT

Mod AT ialah mod rollback transaksi automatik sepenuhnya.

Secara keseluruhannya, mod AT ialah evolusi protokol komit dua fasa:

• Satu fasa: data perniagaan dan rekod log putar balik dilakukan dalam tempatan yang sama transaksi, Lepaskan kunci tempatan dan sumber sambungan.

• Fasa kedua terbahagi kepada dua situasi: 2.1 Serahkan secara tidak segerak, yang diselesaikan dengan sangat cepat. 2.2 Rollback melakukan pampasan terbalik melalui log rollback satu peringkat.

Logik umum adalah seperti di atas. Mari kita lihat cara mod AT berfungsi melalui kes tertentu:

Anggapkan terdapat produk jadual perniagaan, seperti. berikut:

Sekarang kami mahu melakukan operasi kemas kini berikut:

update product set name = 'GTS' where name = 'TXC';

langkah Sebagai berikut:

Fasa satu:

• Parse SQL: dapatkan jenis SQL (KEMASKINI), jadual (produk), keadaan ( di mana nama = 'TXC') dan maklumat lain yang berkaitan.

• Imej pra-pertanyaan: Berdasarkan maklumat bersyarat yang diperoleh daripada penghuraian, hasilkan pernyataan pertanyaan dan cari data (cari data sebelum kemas kini).

• Laksanakan kemas kini SQL di atas.

• Pertanyaan selepas cermin: Berdasarkan hasil pracermin, cari data melalui kunci utama.

• Masukkan log balik: Gabungkan data cermin sebelum dan selepas serta maklumat berkaitan SQL perniagaan ke dalam rekod log balik, dan masukkan ke dalam jadual UNDO_LOG.

• Sebelum menyerahkan, daftarkan cawangan dengan TC: mohon kunci global untuk rekod dengan nilai kunci utama bersamaan dengan 1 dalam jadual produk.

• Penyerahan urus niaga setempat: Kemas kini data perniagaan diserahkan bersama-sama dengan LOG BALIK yang dijana dalam langkah sebelumnya.

• Laporkan hasil penyerahan transaksi tempatan kepada TC.

Fasa kedua:

Fasa kedua dibahagikan kepada dua situasi, commit atau rollback.

Mari kita lihat langkah pemulangan semula:

• Mula-mula terima permintaan pemulangan cawangan daripada TC, mulakan transaksi setempat dan lakukan perkara berikut operasi.

• Cari rekod UNDO LOG yang sepadan melalui XID dan ID Cawangan (rekod ini menyimpan imej yang sepadan sebelum dan selepas pengubahsuaian data).

• Pengesahan data: Bandingkan imej pasca dalam UNDO LOG dengan data semasa Jika terdapat perbezaan, ini bermakna data telah diubah suai oleh tindakan selain daripada transaksi global semasa . Keadaan ini perlu dikendalikan mengikut dasar konfigurasi.

• Jana dan laksanakan penyataan rollback berdasarkan maklumat berkaitan imej dan SQL perniagaan sebelumnya dalam UNDO LOG: update product set name = 'TXC' where id = 1;

• Serahkan Hal ehwal tempatan. Dan laporkan hasil pelaksanaan transaksi tempatan (iaitu, hasil pengembalian transaksi cawangan) kepada TC.

Mari kita lihat langkah penyerahan:

• Terima permintaan penyerahan cawangan daripada TC dan letakkan permintaan itu ke dalam tugas tak segerak Dalam baris gilir, hasil penyerahan yang berjaya dikembalikan serta-merta kepada TC.

• Permintaan penyerahan cawangan dalam fasa tugas tak segerak akan memadamkan rekod UNDO LOG yang sepadan secara tak segerak dan dalam kelompok.

Ini adalah langkah yang hampir sama. Idea ini agak jelas Apabila anda ingin mengemas kini rekod, sistem menjana JSON untuk kandungan sebelum dan selepas kemas kini rekod. Dan simpannya dalam jadual log batal Jika anda ingin melancarkan semula pada masa hadapan, kemas kini data mengikut rekod dalam log batal (pampasan terbalik Jika anda tidak mahu kembali pada masa hadapan, padamkan rekod dalam log asal.

Dalam keseluruhan proses, pembangun hanya perlu membuat jadual log batal asal tambahan, dan kemudian menambah @GlobalTransactional anotasi yang mana transaksi global perlu diproses.

Penyerahan, pemulangan dan pemulangan lain semuanya automatik sepenuhnya, yang lebih mudah dilakukan. Jadi jika anda memilih untuk menggunakan seata untuk mengendalikan transaksi yang diedarkan dalam projek anda, kebarangkalian untuk menggunakan mod AT masih agak tinggi.

5. Mod TCC

Mod TCC (Cuba-Sahkan-Batal) mempunyai sedikit rasa manual Ia juga dua peringkat, tetapi ia berbeza daripada AT lihatlah.

Terdapat carta alir TCC di laman web rasmi, mari kita lihat:

Seperti yang anda lihat, TCC juga dibahagikan kepada dua Peringkat:

• Peringkat pertama adalah menyediakan Pada peringkat ini, ia terutamanya melakukan pengesanan dan tempahan sumber, seperti pemindahan bank, kami mula-mula menyemak sama ada wang pengguna cukup tak cukup, buang saja kalau tak normal bekukan dulu kalau dah cukup.

• Peringkat kedua ialah commit atau rollback Ini terutamanya menunggu peringkat pertama setiap transaksi cawangan dilaksanakan Selepas semua pelaksanaan selesai, masing-masing akan melaporkan keadaannya sendiri kepada TC. dan TC akan membuat statistik Jika TC mendapati bahawa tiada pengecualian dalam setiap urus niaga cawangan, ia akan memberitahu semua orang untuk menyerahkannya bersama-sama jika TC mendapati bahawa mana-mana urus niaga cawangan adalah tidak normal, ia akan memberitahu semua orang untuk melancarkan semula.

Kemudian anda mungkin mendapati bahawa proses di atas melibatkan sejumlah tiga kaedah, sediakan, komit dan tarik balik Ketiga-tiga kaedah ini adalah kaedah yang ditentukan pengguna sepenuhnya, kami perlu melaksanakannya diri kita sendiri, jadi saya berkata dari awal bahawa TCC adalah mod manual.

Berbanding dengan AT, semua orang mendapati bahawa mod TCC sebenarnya tidak bergantung pada sokongan urus niaga pangkalan data asas Dalam erti kata lain, ia tidak penting walaupun pangkalan data asas anda tidak menyokong urus niaga , commit dan rollback adalah tiga Semua kaedah ditulis oleh pembangun sendiri Kita hanya boleh melancarkan proses yang sepadan dengan tiga kaedah ini.

6. Mod XA

Jika anda mengetahui transaksi XA pangkalan data MySQL, anda akan segera memahami apa itu mod XA dalam seata.

Spesifikasi XA ialah standard pemprosesan transaksi (DTP) teragih yang ditakrifkan oleh organisasi X/Open.

Spesifikasi XA menerangkan antara muka antara pengurus transaksi global dan pengurus sumber tempatan. Tujuan spesifikasi XA adalah untuk membenarkan berbilang sumber (seperti pangkalan data, pelayan aplikasi, baris gilir mesej, dll.) diakses dalam transaksi yang sama, supaya sifat ACID kekal sah merentas aplikasi.

Spesifikasi XA menggunakan komit dua fasa untuk menjamin bahawa semua sumber melakukan atau menarik balik sebarang transaksi tertentu pada masa yang sama.

Spesifikasi XA telah dicadangkan pada awal 1990-an. Pada masa ini, hampir semua pangkalan data arus perdana menyediakan sokongan untuk spesifikasi XA.

Transaksi XA adalah berdasarkan protokol komit dua fasa. Penyelaras transaksi diperlukan untuk memastikan semua peserta transaksi telah menyelesaikan kerja penyediaan (fasa pertama). Jika penyelaras menerima mesej bahawa semua peserta sudah bersedia, ia akan memberitahu bahawa semua transaksi boleh dilakukan (fasa 2). MySQL memainkan peranan sebagai peserta dalam transaksi XA ini, bukan penyelaras (pengurus transaksi).

Transaksi XA MySQL dibahagikan kepada XA dalaman dan XA luaran. XA luaran boleh mengambil bahagian dalam urus niaga teragih luaran dan memerlukan lapisan aplikasi untuk campur tangan sebagai penyelaras urus niaga XA dalaman digunakan untuk urus niaga silang enjin di bawah contoh yang sama, dengan Binlog sebagai penyelaras Contohnya, apabila enjin storan melakukan commit perlu Maklumat ditulis pada log binari, yang merupakan transaksi XA dalaman yang diedarkan, kecuali peserta dalam log binari adalah MySQL sendiri. MySQL memainkan peranan sebagai peserta dalam transaksi XA, bukan penyelaras.

Dengan kata lain, MySQL secara semula jadi boleh melaksanakan transaksi teragih melalui spesifikasi XA, tetapi ia hanya memerlukan sokongan beberapa aplikasi luaran . Mari kita lihat proses penggunaan mod XA dalam Seata.

Mari kita lihat gambar rasmi dahulu:

Seperti yang anda lihat, ini juga merupakan dua peringkat penyerahan :

• Fasa 1: Operasi SQL Perniagaan dilakukan di cawangan XA Selepas cawangan XA selesai, penyediaan XA dilaksanakan dan RM menyokong protokol XA untuk memastikan kegigihan ( Iaitu, sebarang kemalangan berikutnya tidak akan menyebabkan pemulangan menjadi mustahil).

• Fasa kedua dibahagikan kepada dua situasi: komit atau rollback:

• Penyerahan cawangan: laksanakan komit cawangan XA

• Pemulihan cawangan: Laksanakan pemulangan cawangan XA

Perbezaan antara dua mod sebelumnya ialah pemulangan semula dalam mod XA ialah pemulangan semula yang serius , ialah pemulangan seperti yang kita fahami dalam erti kata tradisional, bukannya pampasan terbalik.

7. Mod Saga

Akhirnya, mari kita lihat mod saga ini jarang digunakan, jadi semua orang boleh memahaminya.

Mod saga ialah penyelesaian transaksi panjang yang disediakan oleh seata Walau bagaimanapun, urus niaga yang lama adalah perkara yang harus kita elakkan dalam pembangunan kerana ia tidak cekap dan boleh menyebabkan kebuntuan dengan mudah.

Mod saga ini sedikit seperti enjin proses Pembangun mula-mula melukis enjin proses dengan sendiri dan memasukkan semua kaedah yang terlibat dalam keseluruhan transaksi Apabila setiap kaedah mengembalikan sesuatu, ia adalah perkara biasa tidak normal, kemudian teruskan jika ia adalah normal, satu set proses lain akan dilaksanakan, maksudnya, kita perlu menyediakan dua set kaedah terlebih dahulu , dan set kedua adalah untuk pengecualian Proses pelaksanaan seterusnya adalah serupa dengan yang berikut:

Yang hijau adalah proses biasa, dan yang merah adalah proses yang sedang. digulung semula selepas pengecualian berlaku. Rollback juga merupakan sejenis pampasan terbalik.

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah transaksi diedarkan Java Spring Boot. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!