Ringkaskan 7 penyelesaian untuk transaksi yang diedarkan (penyelesaian teori)

Tujuh penyelesaian paling klasik untuk transaksi yang diedarkan

Dengan perkembangan pesat perniagaan dan kerumitan perniagaan yang semakin meningkat, hampir setiap sistem syarikat akan Daripada monolitik kepada diedarkan, terutamanya kepada seni bina perkhidmatan mikro. Kemudian anda pasti akan menghadapi masalah transaksi yang diedarkan.

Artikel ini mula-mula memperkenalkan teori asas yang berkaitan, kemudian meringkaskan penyelesaian urus niaga paling klasik, dan akhirnya memberikan penyelesaian kepada pelaksanaan sub-urus niaga yang tidak tertib (idempotence, pampasan batal dan masalah tergantung). Kongsi Kepada semua orang.

Teori Asas

Sebelum menerangkan penyelesaian khusus, mari kita fahami terlebih dahulu pengetahuan teori asas yang terlibat dalam transaksi teragih.

Mari kita ambil pemindahan sebagai contoh A perlu memindahkan 100 yuan kepada B. Kemudian baki kepada A ialah -100 yuan, dan baki kepada B ialah 100 yuan dan B 100 berjaya pada masa yang sama , atau gagal kedua-duanya pada masa yang sama. Mari lihat bagaimana masalah ini diselesaikan dalam pelbagai senario.

Transaksi

Fungsi mengendalikan berbilang penyata secara keseluruhan dipanggil transaksi pangkalan data. Urus niaga pangkalan data memastikan semua operasi dalam skop transaksi boleh berjaya atau gagal.

Transaksi mempunyai 4 sifat: atomicity, konsistensi, pengasingan dan ketahanan. Empat sifat ini sering dipanggil sifat ASID.

• Atomicity: Semua operasi dalam transaksi sama ada selesai sepenuhnya atau tidak selesai, dan tidak akan berakhir pada mana-mana peringkat pertengahan. Jika ralat berlaku semasa pelaksanaan transaksi, ia akan dipulihkan kepada keadaan sebelum transaksi dimulakan, seolah-olah transaksi itu tidak pernah dilaksanakan.
• Ketekalan: Integriti pangkalan data tidak terjejas sebelum transaksi bermula dan selepas transaksi tamat. Integriti termasuk kekangan utama asing, kekangan yang ditentukan aplikasi, dll. tidak akan dimusnahkan.
• Pengasingan: Pangkalan data membenarkan berbilang transaksi serentak untuk membaca, menulis dan mengubah suai datanya pada masa yang sama Pengasingan boleh menghalang ketidakkonsistenan data akibat pelaksanaan silang apabila berbilang transaksi dilaksanakan serentak.
• Ketahanan: Selepas transaksi selesai, pengubahsuaian data adalah kekal dan tidak akan hilang walaupun sistem gagal.

Jika sistem perniagaan kami tidak rumit dan kami boleh mengubah suai data dan melengkapkan pemindahan dalam satu pangkalan data dan satu perkhidmatan, maka kami boleh menggunakan transaksi pangkalan data untuk memastikan penyelesaian perniagaan pemindahan yang betul.

Transaksi Teragih

Perniagaan pindahan antara bank adalah senario transaksi teragih biasa Andaikan A perlu memindahkan wang kepada B merentas bank, maka ia melibatkan data dua bank dan tidak boleh diluluskan melalui pangkalan data tempatan satu pangkalan data ASID pemindahan jaminan transaksi hanya boleh diselesaikan melalui transaksi yang diedarkan.

Urus niaga teragih bermaksud bahawa pemula transaksi, pengurus sumber dan sumber serta penyelaras transaksi terletak pada nod yang berbeza pada sistem yang diedarkan. Dalam perniagaan pemindahan di atas, operasi pengguna A-100 dan operasi pengguna B 100 tidak terletak pada nod yang sama. Pada asasnya, transaksi yang diedarkan adalah untuk memastikan pelaksanaan operasi data yang betul dalam senario yang diedarkan.

Transaksi teragih dalam persekitaran teragih, untuk memenuhi keperluan ketersediaan, prestasi dan perkhidmatan yang terdegradasi, dan mengurangkan keperluan untuk konsistensi dan pengasingan, dalam satu pihak ikut teori BASE (teori berkaitan BASE, melibatkan banyak kandungan, Pelajar yang berminat boleh merujuk kepada teori ASAS):

• Ketersediaan Asas (Ketersediaan Asas)
• Keadaan lembut (Keadaan lembut)
• Konsistensi Konsistensi Akhirnya )

Begitu juga, urus niaga yang diedarkan juga sebahagiannya mengikut spesifikasi ACID:

• Atomicity: ikut ketat
• Konsistensi: selepas transaksi selesai Konsistensi adalah ketat diikuti; konsistensi dalam transaksi boleh dilonggarkan dengan sewajarnya
• Pengasingan: urus niaga selari tidak boleh terjejas; Penyelesaian transaksi yang diedarkan
• Disebabkan oleh penyelesaian transaksi yang diedarkan, jaminan ACID yang lengkap tidak dapat dicapai Tiada penyelesaian sempurna yang dapat menyelesaikan semua masalah perniagaan. Oleh itu, dalam aplikasi sebenar, penyelesaian transaksi teragih yang paling sesuai akan dipilih berdasarkan ciri perniagaan yang berbeza.

Komit/XA dua fasa

XA ialah spesifikasi transaksi teragih yang dicadangkan oleh organisasi X/Open Spesifikasi XA terutamanya mentakrifkan pengurus transaksi (global) dan (tempatan). Antara muka antara pengurus sumber (RM). Pangkalan data tempatan seperti mysql memainkan peranan RM dalam XA

XA dibahagikan kepada dua fasa:

Fasa pertama (persediaan): iaitu semua peserta RM bersedia untuk melaksanakan transaksi dan mengunci sumber yang diperlukan untuk hidup. Apabila peserta sudah bersedia, ia melaporkan kepada TM bahawa ia sudah bersedia.

Fasa kedua (commit/rollback): Apabila pengurus transaksi (TM) mengesahkan bahawa semua peserta (RM) sudah bersedia, ia menghantar arahan komit kepada semua peserta.

Pangkalan data arus perdana pada asasnya menyokong transaksi XA, termasuk mysql, oracle, sqlserver, postgre

Transaksi XA terdiri daripada satu atau lebih pengurus sumber (RM), pengurus transaksi (TM) dan program Aplikasi (ApplicationProgram ).

Tiga peranan RM, TM dan AP di sini ialah pembahagian peranan klasik, yang akan dijalankan melalui Saga, Tcc dan mod transaksi lain yang seterusnya.

Mengambil pemindahan di atas sebagai contoh, rajah jujukan transaksi XA yang berjaya dilengkapkan adalah seperti berikut:

Sekiranya mana-mana peserta gagal membuat persediaan, maka TM akan memaklumkan semua penyempurnaan Persediaan peserta melakukan rollback.

Ciri-ciri transaksi XA ialah:

• Mudah dan mudah difahami, lebih mudah untuk dibangunkan
• Penguncian sumber jangka panjang, konkurensi rendah

Sekiranya pembaca ingin mendalami XA, go language, PHP, Python, Java, C#, Node, dll. boleh rujuk DTM

SAGA

Saga ialah kertas pangkalan data ini Penyelesaian yang disebut oleh sagas. Idea teras adalah untuk membahagikan urus niaga panjang kepada berbilang urus niaga pendek tempatan, yang diselaraskan oleh penyelaras urus niaga Saga Jika ia berakhir seperti biasa, ia akan diselesaikan secara normal.

Mengambil pemindahan di atas sebagai contoh, gambar rajah jujukan transaksi SAGA yang berjaya dilengkapkan adalah seperti berikut:

Setelah Saga mencapai peringkat Batal, kemudian Batal dalam logik perniagaan Kegagalan tidak dibenarkan. Jika kejayaan tidak dikembalikan kerana rangkaian atau kegagalan sementara yang lain, TM akan terus mencuba semula sehingga Batal mengembalikan kejayaan.

Ciri urus niaga Saga:

• Konkurensi tinggi, tidak perlu mengunci sumber untuk masa yang lama seperti transaksi XA
• Perlu menentukan operasi biasa dan operasi pampasan, dan volum pembangunan lebih kecil daripada XA
• Konsistensi adalah lemah untuk pemindahan, mungkin berlaku pengguna A telah menolak wang, tetapi pemindahan terakhir gagal lagi

Terdapat. banyak kandungan SAGA dalam kertas kerja, termasuk dua jenis Strategi pemulihan termasuk pelaksanaan serentak urus niaga cawangan Perbincangan kami di sini hanya merangkumi SAGA yang paling mudah

SAGA boleh digunakan untuk banyak senario, urus niaga panjang dan senario perniagaan yang. tidak sensitif kepada keputusan pertengahan

Sekiranya pembaca ingin mempelajari lebih lanjut SAGA, mereka boleh merujuk kepada DTM, yang merangkumi contoh pemulangan kejayaan dan kegagalan SAGA, serta pengendalian pelbagai pengecualian rangkaian.

TCC

Konsep TCC (Try-Confirm-Cancel) pertama kali diterbitkan oleh Pat Helland pada tahun 2007 dalam artikel bertajuk "Life beyond Distributed Transactions: an Apostate's Opinion" Kertas kerja yang dibentangkan.

TCC dibahagikan kepada 3 fasa

• Fasa percubaan: cuba laksanakan, lengkapkan semua semakan perniagaan (konsistensi), simpan sumber perniagaan yang diperlukan (kuasi-pengasingan)
• Fasa Sahkan: Sahkan bahawa pelaksanaan benar-benar melaksanakan perniagaan, tanpa sebarang pemeriksaan perniagaan dan hanya menggunakan sumber perniagaan yang dikhaskan dalam fasa Cuba Operasi Sahkan memerlukan reka bentuk idempoten dan percubaan semula diperlukan selepas Sahkan gagal.
• Batalkan fasa: Batalkan pelaksanaan dan lepaskan sumber perniagaan yang dikhaskan dalam fasa Cuba. Skim pengendalian pengecualian dalam fasa Batal pada asasnya adalah sama seperti dalam fasa Sahkan, dan memerlukan reka bentuk idempoten.

Mengambil pemindahan di atas sebagai contoh, amaun biasanya dibekukan dalam Cuba tetapi tidak ditolak, amaun ditolak dalam Sahkan, dan amaun tidak dibekukan dalam Batal A rajah jujukan transaksi TCC yang berjaya adalah seperti berikut:

Fasa Sahkan/Batal TCC tidak dibenarkan untuk mengembalikan kegagalan dari segi logik perniagaan Jika kejayaan tidak dapat dikembalikan kerana rangkaian atau kegagalan sementara yang lain , TM akan terus mencuba lagi , sehingga Sahkan/Batal berjaya kembali.

Ciri TCC adalah seperti berikut:

• Konkurensi tinggi dan tiada penguncian sumber jangka panjang.
• Jumlah pembangunan adalah besar dan antara muka Cuba/Sahkan/Batal perlu disediakan.
• Konsistensi adalah baik, dan tidak akan ada situasi di mana SAGA telah menolak wang dan kemudian gagal untuk memindahkan wang
• TCC sesuai untuk perniagaan jenis pesanan dan perniagaan dengan kekangan status perantaraan

Jika pembaca ingin mempelajari lebih lanjut TCC, mereka boleh merujuk kepada DTM

Jadual Mesej Tempatan

Jadual Mesej Tempatan pada asalnya adalah artikel diterbitkan oleh arkitek eBay Dan Pritchett kepada ACM pada tahun 2008. Inti reka bentuk adalah untuk memastikan pelaksanaan tugas secara tidak segerak yang memerlukan pemprosesan yang diedarkan melalui mesej.

Proses umum adalah seperti berikut:

Menulis mesej tempatan dan operasi perniagaan diletakkan dalam satu transaksi, memastikan atomicity perniagaan dan penghantaran mesej, atau mereka semua Berjaya atau gagal semuanya.

Mekanisme toleransi kesalahan:

• Apabila urus niaga potongan baki gagal, urus niaga akan ditarik balik terus tanpa langkah seterusnya
• Mesej pengeluaran jujukan gagal, dan urus niaga penambahan baki gagal. >Pengeluar memerlukan tambahan Mencipta jadual mesej

Setiap jadual mesej setempat perlu ditinjau

Jika logik pengguna tidak boleh berjaya melalui percubaan semula, maka lebih banyak mekanisme diperlukan untuk melancarkan operasi

• Terpakai kepada perniagaan yang boleh dilaksanakan secara tak segerak dan operasi berikutnya tidak memerlukan pemulangan

• Mesej Transaksi

  Dalam penyelesaian jadual mesej tempatan di atas, pengeluar perlu membuat jadual mesej tambahan dan meninjau jadual mesej tempatan, yang mengenakan beban perniagaan yang berat. Sumber terbuka Alibaba RocketMQ 4.3 dan kemudian secara rasmi menyokong mesej transaksi Mesej transaksi ini pada asasnya meletakkan jadual mesej tempatan pada RocketMQ untuk menyelesaikan masalah atomicity penghantaran mesej dan pelaksanaan transaksi tempatan di bahagian pengeluaran.

  Penghantaran dan penyerahan mesej transaksi:

  • Hantar mesej (separuh mesej)
  • Pelayan menyimpan mesej dan membalas hasil penulisan mesej
  • Laksanakan urus niaga tempatan mengikut hasil penghantaran (jika penulisan gagal, separuh mesej tidak kelihatan kepada perniagaan pada masa ini dan logik tempatan tidak dilaksanakan)
  • Laksanakan Komit atau Rollback mengikut status transaksi setempat (Operasi komit menerbitkan mesej, dan mesej digunakan) Kelihatan)

  Carta aliran penghantaran biasa adalah seperti berikut:

  

  Proses pampasan:

  Untuk transaksi tanpa Mesej Komit/Rollback (mesej dalam status belum selesai), mulakan "semakan" daripada pelayan
  Pengeluar menerima mesej semakan dan mengembalikan status transaksi tempatan yang sepadan kepada mesej, iaitu Commit atau Rollback
  Pelan mesej transaksi dan jadual mesej setempat Mekanismenya sangat serupa, perbezaan utama ialah operasi jadual tempatan berkaitan asal digantikan dengan antara muka pertanyaan terbalik

  ciri-ciri mesej urus niaga adalah seperti berikut:

  • Urus niaga yang lama hanya perlu dibahagikan kepada berbilang tugas , dan menyediakan antara muka semak terbalik yang mudah digunakan
  • Jika logik pengguna tidak boleh berjaya melalui percubaan semula, maka lebih banyak mekanisme diperlukan untuk melancarkan operasi

  Terpakai kepada aplikasi yang boleh Perniagaan yang dilaksanakan secara tidak segerak dan operasi seterusnya tidak memerlukan pemulangan

  Jika pembaca mahu untuk mengkaji lebih lanjut mesej transaksi, mereka boleh merujuk kepada DTM, atau Rocketmq

  Pemberitahuan usaha terbaik

  Pihak yang memulakan pemberitahuan akan cuba sedaya upaya untuk memberitahu penerima hasil pemprosesan perniagaan melalui mekanisme tertentu. Khususnya:

  Terdapat mekanisme pemberitahuan ulangan mesej tertentu. Oleh kerana pihak yang menerima pemberitahuan mungkin tidak menerima pemberitahuan itu, mekanisme tertentu mesti disediakan untuk memberitahu mesej berulang kali.
  Mekanisme membaca pruf mesej. Jika penerima tidak dimaklumkan walaupun usaha terbaiknya, atau jika penerima ingin menggunakan semula mesej selepas menggunakannya, penerima boleh secara aktif bertanya kepada pemberi maklumat untuk mendapatkan maklumat mesej untuk memenuhi permintaan.
  Jadual mesej tempatan dan mesej transaksi yang diperkenalkan sebelum ini ialah kedua-dua mesej yang boleh dipercayai. Bagaimanakah ia berbeza daripada pemberitahuan usaha terbaik yang diperkenalkan di sini?

  Konsistensi mesej yang boleh dipercayai Pihak pemberitahuan yang memulakan perlu memastikan bahawa mesej itu dihantar dan dihantar kepada pihak pemberitahuan yang menerima Kunci kebolehpercayaan mesej itu dijamin oleh pihak pemberitahuan yang memulakan.

  Pemberitahuan usaha terbaik, pihak yang memulakan pemberitahuan akan cuba sedaya upaya untuk memberitahu pihak yang menerima hasil pemprosesan perniagaan, tetapi mesej itu mungkin tidak diterima pada masa ini, pihak yang menerima perlu menghubungi secara aktif antara muka pihak yang memulakan untuk menanyakan pemprosesan perniagaan Akibatnya, kunci kepada kebolehpercayaan pemberitahuan terletak pada pihak yang menerima pemberitahuan.

  Bagi penyelesaiannya, pemberitahuan usaha terbaik memerlukan:

  • Sediakan antara muka supaya penerima pemberitahuan boleh menanyakan hasil pemprosesan perniagaan melalui antara muka
  • Baris gilir mesej Mekanisme ACK, mesej Baris gilir meningkatkan selang pemberitahuan secara beransur-ansur pada selang 1min, 5min, 10min, 30min, 1j, 2j, 5j dan 10j sehingga had atas tetingkap masa yang diperlukan untuk pemberitahuan dicapai. Tiada lagi pemberitahuan kemudian

  Pemberitahuan usaha terbaik sesuai untuk jenis pemberitahuan perniagaan Sebagai contoh, hasil transaksi WeChat dimaklumkan kepada setiap pedagang melalui pemberitahuan usaha terbaik Terdapat kedua-dua pemberitahuan panggilan balik dan antara muka pertanyaan transaksi

  Mod transaksi AT

  Ini ialah mod transaksi dalam seata projek sumber terbuka Alibaba, juga dikenali sebagai FMT dalam Ant Financial. Kelebihannya ialah mod urus niaga digunakan dengan cara yang serupa dengan mod XA Perniagaan tidak perlu menulis pelbagai operasi pampasan, dan pengembalian secara automatik dilengkapkan dengan rangka kerja -kunci jangka, yang tidak memenuhi senario konkurensi tinggi. Dari perspektif prestasi, mod AT lebih tinggi daripada XA, tetapi ia turut membawa masalah baharu seperti pemulangan semula yang kotor. Pelajar yang berminat boleh merujuk kepada seata-AT

  Pengendalian Pengecualian

  Masalah seperti kegagalan rangkaian dan perniagaan mungkin berlaku dalam semua aspek transaksi yang diedarkan Masalah ini memerlukan kaedah perniagaan untuk urus niaga yang diedarkan tiga ciri rollback anti-udara, mati pucuk, dan anti-gantung.

  Pengecualian

  Yang berikut menggunakan urus niaga TCC untuk menggambarkan pengecualian ini:

  Kembali kosong:

  Apabila tiada sumber TCC dipanggil Dalam kes kaedah Cuba, kaedah Batal dua peringkat dipanggil Kaedah Batal perlu mengenali bahawa ini adalah rollback kosong dan kemudian terus mengembalikan kejayaan.

  Sebabnya ialah apabila urus niaga cawangan mengalami masa henti perkhidmatan atau keabnormalan rangkaian, panggilan urus niaga cawangan direkodkan sebagai kegagalan Pada masa ini, fasa Cuba sebenarnya tidak dilaksanakan apabila kerosakan dipulihkan. urus niaga yang diedarkan digulung semula Kaedah Batal dua peringkat akan dipanggil, menyebabkan pemulangan kosong.

  Mati pucuk:

  Memandangkan sebarang permintaan mungkin mempunyai anomali rangkaian dan permintaan berulang, semua cawangan transaksi yang diedarkan perlu memastikan mati pucuk

  Penggantungan:

  Penggantungan bermaksud bahawa untuk transaksi yang diedarkan, antara muka Batal peringkat kedua dilaksanakan sebelum antara muka Try.

  Sebabnya ialah apabila RPC memanggil transaksi cawangan cuba, transaksi cawangan didaftarkan dahulu, dan kemudian panggilan RPC dilaksanakan Jika rangkaian yang dipanggil oleh RPC sesak pada masa ini, selepas RPC habis masa, TM akan memberitahu RM untuk melancarkan semula transaksi yang diedarkan Mungkin selepas pemulangan selesai, permintaan RPC Try sampai kepada peserta dan sebenarnya dilaksanakan.

  Mari kita lihat gambarajah masa anomali rangkaian untuk lebih memahami masalah di atas
  

  • Apabila permintaan pemprosesan perniagaan 4, Batal dilaksanakan sebelum Cuba , perlu kendalikan rollback kosong
  • Apabila permintaan pemprosesan perniagaan 6, Batal dilaksanakan berulang kali dan perlu diidentifikasikan
  • Apabila permintaan pemprosesan perniagaan 8, Try dilaksanakan selepas Batal dan penggantungan perlu dikendalikan

  Menghadapi anomali rangkaian kompleks di atas, penyelesaian yang dicadangkan oleh pelbagai syarikat pada masa ini ialah pihak perniagaan menggunakan kunci unik untuk bertanya sama ada operasi yang berkaitan telah selesai, dan jika ia telah selesai, ia secara langsung akan mengembalikan kejayaan. Logik penghakiman yang berkaitan adalah kompleks, mudah ralat, dan mempunyai beban perniagaan yang berat.

  Halangan sub-urus niaga

  Dalam projek https://github.com/yedf/dtm, teknologi halangan sub-transaksi muncul menggunakan teknologi ini, kesan ini boleh dicapai rajah skema:
  

  Selepas semua permintaan ini mencapai halangan sub-urus niaga: permintaan yang tidak normal akan ditapis; Selepas pembangun menggunakan halangan sub-urus niaga, semua pengecualian yang disebutkan di atas dikendalikan dengan betul, dan pembangun perniagaan hanya perlu menumpukan pada logik perniagaan sebenar, dan bebannya dikurangkan dengan banyak.
  Halangan sub-transaksi menyediakan kaedah ThroughBarrierCall Prototaip kaedah ialah:

  func ThroughBarrierCall(db *sql.DB, transInfo *TransInfo, busiCall BusiFunc)

  Pemaju perniagaan boleh menulis logik mereka sendiri yang berkaitan dalam busiCall dan memanggil fungsi ini. ThroughBarrierCall memastikan bahawa busiCall tidak akan dipanggil dalam senario seperti rollback kosong dan penggantungan apabila perniagaan dipanggil berulang kali, terdapat kawalan idempoten untuk memastikan bahawa ia hanya diserahkan sekali.

  Halangan sub-transaksi akan mengurus TCC, SAGA, mesej transaksi, dll., dan juga boleh diperluaskan ke kawasan lain

  Prinsip halangan sub-transaksi

  Prinsip teknologi halangan sub-transaksi ialah dalam Dalam pangkalan data tempatan, wujudkan jadual status transaksi cawangan sub_trans_barrier Kunci unik ialah id-sub-transaksi id-sub-transaksi nama cawangan (cuba|sahkan|batalkan)

  .
  • Buka transaksi
  • jika Jika ia adalah cawangan Try, maka masukkan abaikan dimasukkan ke dalam gid-branchid-try Jika ia berjaya dimasukkan, logik dalam halangan dipanggil
  • Jika ia adalah cawangan Sahkan, kemudian masukkan abaikan dimasukkan ke dalam gid-branchid-confirm Jika ia berjaya dimasukkan, maka Panggil logik dalam halangan
  • Jika ia adalah cawangan Batal, masukkan abaikan. ke dalam gid-branchid-try, dan kemudian masukkan gid-branchid-cancel Jika cubaan tidak dimasukkan dan membatalkan berjaya dimasukkan, panggil logik dalam halangan
  • Logik dalam halangan mengembalikan kejayaan, melakukan transaksi. , dan mengembalikan kejayaan
  • Logik dalam halangan mengembalikan ralat, melancarkan transaksi dan mengembalikan ralat

  Di bawah mekanisme ini, pengecualian rangkaian diselesaikan Isu berkaitan

  • Kawalan pampasan kosong--jika Try tidak dilaksanakan dan Batal dilaksanakan secara langsung, kemudian Batal yang dimasukkan ke dalam gid-branchid-try akan berjaya, tanpa menggunakan logik dalam halangan, memastikan kawalan pampasan kosong
  • Kawalan mati pucuk--Tiada kunci unik boleh dimasukkan berulang kali dalam mana-mana cawangan, memastikan ia tidak akan dilaksanakan berulang kali
  • Kawalan anti-gantung--Cuba dilaksanakan selepas Batal, kemudian cabang gid yang dimasukkan Jika -cuba tidak berjaya, ia tidak akan dilaksanakan, memastikan kawalan anti-gantung

  Mekanisme serupa digunakan untuk SAGA, mesej transaksi, dsb.

  Ringkasan halangan sub-transaksi

  Teknologi halangan sub-transaksi dipelopori oleh https://github.com/yedf/dtm Kepentingannya terletak pada mereka bentuk yang ringkas dan mudah. melaksanakan algoritma, dan menyediakan algoritma yang ringkas dan mudah dilaksanakan Kepentingan antara muka yang digunakan dalam Capital adalah untuk mereka bentuk algoritma yang ringkas dan mudah untuk dilaksanakan serta menyediakan antara muka yang ringkas dan mudah digunakan kedua-dua item ini, pembangun dibebaskan sepenuhnya daripada pemprosesan pengecualian rangkaian.

  Teknologi ini pada masa ini perlu digandingkan dengan pengurus transaksi yedf/dtm Pada masa ini, SDK telah diberikan kepada pembangun bahasa Go dan Python. SDK untuk bahasa lain sedang dalam perancangan. Untuk rangka kerja transaksi teragih yang lain, selagi maklumat transaksi teragih yang sesuai disediakan, teknologi itu boleh dilaksanakan dengan cepat mengikut prinsip di atas.

  Ringkasan

  Artikel ini memperkenalkan beberapa teori asas urus niaga yang diedarkan dan menerangkan penyelesaian transaksi teragih yang biasa digunakan juga diberikan dalam separuh kedua artikel , klasifikasi dan penyelesaian yang elegan.

  yedf/dtm menyokong TCC, XA, SAGA, mesej transaksi, pemberitahuan usaha terbaik (dilaksanakan menggunakan mesej transaksi), dan menyediakan sokongan protokol HTTP dan gRPC, yang sangat mudah diakses.

  yedf/dtm telah menyokong klien dalam Python, Java, PHP, C#, Node dan bahasa lain, lihat: SDK untuk setiap bahasa.

  Selamat datang semua orang melawati projek https://github.com/yedf/dtm dan berikan bintang untuk menyokongnya!

Atas ialah kandungan terperinci Ringkaskan 7 penyelesaian untuk transaksi yang diedarkan (penyelesaian teori). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!