Masalah dwitulisan  Membina sistem teragih yang boleh dipercayai, sangat tersedia, berskala memerlukan pematuhan kepada teknik, prinsip dan corak tertentu. Reka bentuk sistem sedemikian melibatkan menangani pelbagai cabaran. Antara isu yang paling lazim dan asas ialah   . masalah dwitulisan    ialah cabaran yang timbul dalam sistem teragih, terutamanya apabila berurusan dengan berbilang sumber data atau pangkalan data yang perlu disegerakkan. Ia merujuk kepada kesukaran untuk memastikan perubahan data ditulis secara konsisten ke pelbagai stor data, seperti pangkalan data atau cache, tanpa memperkenalkan isu seperti ketidakkonsistenan data, konflik atau kesesakan prestasi. "Masalah penulisan dwi"  Seni bina perkhidmatan mikro dan pangkalan data corak bagi setiap perkhidmatan memberi anda banyak faedah, seperti penggunaan dan penskalaan bebas, kegagalan terpencil dan potensi peningkatan halaju pembangunan. Walau bagaimanapun, operasi memerlukan perubahan antara pelbagai perkhidmatan mikro, memaksa anda memikirkan penyelesaian yang boleh dipercayai untuk menangani masalah ini.   Hampir contoh sebenar  Mari kita pertimbangkan senario di mana domain kami melibatkan penerimaan permohonan pinjaman, menilai mereka dan kemudian menghantar makluman pemberitahuan kepada pelanggan.  Berdasarkan semangat prinsip tanggungjawab tunggal, undang-undang Conway, dan pendekatan reka bentuk dipacu domain, selepas beberapa sesi pencerobohan peristiwa, keseluruhan domain dipecahkan kepada tiga subdomain dengan konteks sempadan yang ditakrifkan yang mempunyai sempadan yang jelas, model domain dan bahasa di mana-mana.    ditugaskan untuk menyiapkan dan menyusun permohonan pinjaman baharu. Sistem   menilai aplikasi ini dan membuat keputusan berdasarkan data yang diberikan. Proses penilaian ini, termasuk KYC/KYB, antifraud dan semakan risiko kredit, boleh memakan masa, memerlukan keupayaan untuk mengendalikan beribu-ribu permohonan secara serentak. Akibatnya, fungsi ini telah diwakilkan kepada perkhidmatan mikro khusus dengan pangkalan datanya sendiri, membolehkan penskalaan bebas. Yang pertama kedua  Tambahan pula, subsistem ini diuruskan oleh dua pasukan berbeza, masing-masing mempunyai kitaran keluaran sendiri, perjanjian tahap perkhidmatan (SLA) dan keperluan skalabiliti.    , perkhidmatan pemberitahuan khusus disediakan untuk menghantar makluman kepada pelanggan.  Akhir sekali Berikut ialah huraian terperinci tentang kes penggunaan utama sistem:  Seorang pelanggan mengemukakan permohonan pinjaman.  Perkhidmatan Permohonan Pinjaman merekodkan permohonan baharu dengan status "Pending" dan memulakan proses penilaian dengan memajukan permohonan kepada Perkhidmatan Penilaian.  Perkhidmatan Penilaian menilai permohonan pinjaman yang masuk dan seterusnya memaklumkan keputusan tersebut kepada Perkhidmatan Permohonan Pinjaman.  Setelah menerima keputusan, Perkhidmatan Permohonan Pinjaman mengemas kini status permohonan pinjaman dengan sewajarnya dan mencetuskan Perkhidmatan Pemberitahuan untuk memaklumkan kepada pelanggan tentang hasilnya.  Perkhidmatan Pemberitahuan memproses permintaan ini dan menghantar pemberitahuan kepada pelanggan melalui e-mel, SMS atau kaedah komunikasi pilihan lain, mengikut tetapan pelanggan.  Ia adalah sistem yang agak mudah dan primitif pada pandangan pertama, tetapi mari kita selami bagaimana perkhidmatan permohonan Pinjaman memproses arahan serah permohonan pinjaman.  Kami boleh mempertimbangkan dua pendekatan untuk interaksi perkhidmatan:    Dalam pendekatan ini, perkhidmatan mengemas kini pangkalan data setempatnya (commit) dan kemudian menerbitkan acara atau mesej kepada perkhidmatan lain. First-Local-Commit-Then-Publish:    Sebaliknya, kaedah ini melibatkan penerbitan acara atau mesej sebelum melakukan perubahan pada pangkalan data setempat. First-Publish-Then-Local-Commit:  Kedua-dua kaedah mempunyai kelemahan mereka dan hanya sebahagiannya gagal-selamat untuk komunikasi dalam sistem teragih.     Ini ialah rajah jujukan menggunakan pendekatan pertama.  Dalam senario ini, Perkhidmatan Permohonan Pinjaman menggunakan pendekatan   , di mana ia mula-mula melakukan transaksi dan kemudian cuba menghantar pemberitahuan kepada sistem lain. Walau bagaimanapun, proses ini terdedah kepada kegagalan jika, sebagai contoh, terdapat isu rangkaian, Perkhidmatan Penilaian tidak tersedia, atau Perkhidmatan Permohonan Pinjaman menghadapi ralat Habis Ingatan (OOM) dan ranap. Dalam kes sedemikian, mesej akan hilang, meninggalkan Penilaian tanpa notis permohonan pinjaman baharu, melainkan langkah tambahan dilaksanakan. First-Local-Commit-Then-Publish     Dan yang kedua.  Dalam senario   , Perkhidmatan Permohonan Pinjaman menghadapi risiko yang lebih ketara. Ia mungkin memaklumkan Perkhidmatan Penilaian tentang aplikasi baharu tetapi gagal menyimpan kemas kini ini secara setempat disebabkan masalah seperti isu pangkalan data, ralat memori atau pepijat kod. Pendekatan ini boleh membawa kepada ketidakkonsistenan yang ketara dalam data, yang boleh menyebabkan masalah serius, bergantung pada cara Perkhidmatan Semakan Pinjaman mengendalikan permohonan yang masuk. First-Publish-Then-Local-Commit  Oleh itu, kita mesti mengenal pasti penyelesaian yang menawarkan mekanisme yang teguh untuk menerbitkan acara kepada pengguna luar. Tetapi, sebelum menyelidiki penyelesaian yang berpotensi, kita harus terlebih dahulu menjelaskan jenis jaminan penghantaran mesej yang boleh dicapai dalam sistem yang diedarkan.  Jaminan penghantaran mesej  Terdapat empat jenis jaminan yang boleh kami capai.  Tiada jaminan  Tiada jaminan bahawa mesej akan dihantar ke destinasi. Pendekatan   adalah tepat mengenai perkara ini. Pengguna mungkin menerima mesej sekali, beberapa kali, atau tidak sama sekali. First-Local-Commit-Then-Publish  Paling banyak sekali penghantaran  Paling banyak sekali penghantaran bermakna mesej akan dihantar ke destinasi paling banyak 1 kali. Pendekatan   boleh dilaksanakan dengan cara ini juga dengan dasar cuba semula percubaan dengan nilai satu. First-Local-Commit-Then-Publish  Sekurang-kurangnya sekali penghantaran\Pengguna akan menerima dan memproses setiap mesej tetapi mungkin menerima mesej yang sama lebih daripada sekali.  Tepat sekali penghantaran\Tepat sekali penghantaran bermakna pengguna akan menerima mesej dengan berkesan sekali.  Secara teknikal, adalah mungkin untuk dicapai dengan transaksi Kafka dan pelaksanaan idempoten khusus pengeluar dan pengguna.  Dalam kebanyakan kes, jaminan penghantaran   menangani banyak isu dengan memastikan mesej dihantar sekurang-kurangnya sekali, tetapi pengguna mesti mempunyai idempoten. Walau bagaimanapun, memandangkan kegagalan rangkaian yang tidak dapat dielakkan, semua logik pengguna mestilah idempoten untuk mengelakkan pemprosesan mesej pendua, tanpa mengira jaminan pengeluar. Oleh itu, keperluan ini bukanlah satu kelemahan kerana ia mencerminkan realiti. 'sekurang-kurangnya sekali'  Penyelesaian  Terdapat banyak penyelesaian untuk masalah ini, yang mempunyai kelebihan dan kekurangannya.   Komit dua fasa  Menurut Wikipedia, Komit Dua Fasa (2PC) ialah protokol transaksi teragih yang digunakan dalam sains komputer dan sistem pengurusan pangkalan data untuk memastikan ketekalan dan kebolehpercayaan transaksi yang diedarkan. Ia direka untuk situasi di mana berbilang sumber (cth, pangkalan data) perlu mengambil bahagian dalam satu transaksi, dan ia memastikan sama ada kesemuanya melakukan transaksi atau kesemuanya membatalkannya, dengan itu mengekalkan konsistensi data. Kedengarannya seperti yang kita perlukan, tetapi Komit Dua Fasa mempunyai beberapa kelemahan:  Jika satu sumber yang mengambil bahagian menjadi tidak bertindak balas atau mengalami kegagalan, keseluruhan proses boleh disekat sehingga isu itu diselesaikan. Ini boleh membawa kepada potensi masalah prestasi dan ketersediaan.  Komit Dua Fasa tidak menyediakan mekanisme toleransi kesalahan terbina dalam. Ia bergantung pada mekanisme luaran atau campur tangan manual untuk menangani kegagalan.  Tidak semua pangkalan data moden menyokong Komit Dua Fasa.   Pangkalan data dikongsi  Penyelesaian yang paling jelas untuk seni bina perkhidmatan mikro ialah menggunakan corak (atau kadangkala anti-corak) — pangkalan data dikongsi. Pendekatan ini sangat intuitif jika anda memerlukan konsistensi transaksi merentas berbilang jadual dalam pangkalan data yang berbeza, hanya gunakan satu pangkalan data dikongsi untuk perkhidmatan mikro ini.  Kelemahan pendekatan ini termasuk memperkenalkan satu titik kegagalan, menghalang penskalaan pangkalan data bebas, dan mengehadkan keupayaan untuk menggunakan penyelesaian pangkalan data berbeza yang paling sesuai untuk keperluan dan kes penggunaan tertentu. Selain itu, pengubahsuaian kepada pangkalan kod mikroperkhidmatan akan diperlukan untuk menyokong bentuk transaksi yang diedarkan.   Peti keluar transaksi  '   ' ialah corak reka bentuk yang digunakan dalam sistem teragih untuk memastikan penyebaran mesej yang boleh dipercayai, walaupun dalam menghadapi sistem pemesejan yang tidak boleh dipercayai. Ia melibatkan penyimpanan peristiwa dalam jadual 'OutboxEvents' yang ditetapkan dalam transaksi yang sama seperti operasi itu sendiri. Pendekatan ini selaras dengan baik dengan sifat ACID pangkalan data hubungan. Sebaliknya, banyak pangkalan data No-SQL tidak menyokong sepenuhnya sifat ACID, sebaliknya memilih prinsip teorem CAP dan falsafah BASE, yang mengutamakan ketersediaan dan konsistensi akhirnya daripada konsistensi yang ketat. Kotak keluar transaksi  Peti keluar transaksi menyediakan   dan boleh dilaksanakan dengan beberapa pendekatan: sekurang-kurangnya sekali jaminan  Tailing log transaksi  Penerbit undian  Pendekatan   membayangkan penggunaan penyelesaian khusus pangkalan data seperti CDC (Tukar Tangkapan Data). Kelemahan utama pendekatan itu ialah: tailing log transaksi  Penyelesaian khusus pangkalan data  Peningkatan kependaman disebabkan oleh spesifik pelaksanaan CDC  Kaedah lain ialah   , yang memudahkan pemuatan peti keluar dengan mengundi jadual peti keluar. Kelemahan utama pendekatan ini ialah potensi peningkatan beban pangkalan data, yang boleh membawa kepada kos yang lebih tinggi. Tambahan pula, bukan semua pangkalan data No-SQL menyokong pertanyaan yang cekap untuk segmen dokumen tertentu. Oleh itu, mengekstrak keseluruhan dokumen boleh mengakibatkan kemerosotan prestasi. Publisher Polling  Berikut ialah rajah jujukan kecil yang menerangkan cara ia berfungsi.    Dengar sendiri  Cabaran utama dengan corak Peti Keluar Transaksi terletak pada pergantungannya pada sifat ACID pangkalan data. Ia mungkin mudah dalam pangkalan data OLTP biasa tetapi menimbulkan cabaran dalam alam NoSQL. Untuk menangani perkara ini, penyelesaian yang berpotensi adalah dengan memanfaatkan log tambahan (contohnya, Kafka) terus daripada memulakan pemprosesan permintaan.  Daripada memproses terus arahan 'serahkan permohonan pinjaman', kami segera menghantarnya ke topik Kafka dalaman dan kemudian mengembalikan keputusan 'diterima' kepada pelanggan. Walau bagaimanapun, memandangkan kemungkinan besar arahan itu masih perlu diproses, kami tidak boleh segera memaklumkan keputusan itu kepada pelanggan. Untuk mengurus ketekalan akhirnya ini, kami boleh menggunakan teknik seperti tinjauan panjang, tinjauan pendapat yang dimulakan pelanggan, kemas kini UI yang optimistik atau menggunakan WebSockets atau Acara Dihantar Pelayan untuk pemberitahuan. Walau bagaimanapun, ini adalah topik yang berbeza sama sekali, jadi mari kita kembali kepada subjek awal kita.  Kami menghantar mesej mengenai topik Kafka dalaman. Perkhidmatan Permohonan Pinjaman kemudian menggunakan mesej ini — arahan yang sama yang diterima daripada pelanggan — dan mula memproses. Pertama, ia melaksanakan beberapa logik perniagaan; hanya selepas logik ini berjaya dilaksanakan dan hasilnya berterusan, ia menerbitkan mesej baharu mengenai topik Kafka awam.  Mari kita lihat sedikit pseudo-kod.   public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); }    Jangan risau, memandangkan offset belum dilakukan, mesej akan dicuba semula. Bagaimana jika pemprosesan logik perniagaan gagal?    Jangan risau, kerana logik perniagaan adalah idempoten, ia tidak akan membuat permohonan pinjaman pendua. Sebaliknya, ia akan cuba menghantar semula mesej kepada topik Kafka awam. Bagaimana jika menghantar acara baharu kepada Kafka gagal?    Jangan risau, kerana logik perniagaan adalah idempoten, ia tidak akan membuat permohonan pinjaman pendua. Sebaliknya, ia akan menghantar semula mesej kepada topik Kafka awam dan berharap komit offset berjaya kali ini. Bagaimana jika mesej dihantar ke Kafka, tetapi komit offset gagal?  Kelemahan utama pendekatan ini termasuk kerumitan tambahan yang dikaitkan dengan gaya pengaturcaraan baharu, ketekalan akhirnya (kerana pelanggan tidak akan segera mengetahui hasilnya), dan keperluan untuk semua logik perniagaan menjadi idempoten.  Sumber acara  Apakah sumber acara, dan bagaimanakah ia boleh digunakan di sini? Penyumberan acara ialah corak seni bina perisian yang digunakan untuk memodelkan keadaan sistem dengan menangkap semua perubahan pada datanya sebagai satu siri peristiwa tidak berubah. Peristiwa ini mewakili fakta atau peralihan keadaan dan berfungsi sebagai sumber tunggal kebenaran untuk keadaan semasa sistem. Jadi, secara teknikalnya, dengan melaksanakan sistem penyumberan acara, kami sudah mempunyai semua acara dalam EventStore, dan EventStore ini boleh digunakan oleh pengguna sebagai satu sumber kebenaran tentang apa yang berlaku. Tidak ada keperluan untuk penyelesaian pangkalan data khusus untuk menjejaki semua perubahan atau kebimbangan mengenai pesanan, satu-satunya masalah ialah duduk di sebelah baca kerana untuk mendapatkan keadaan sebenar entiti diperlukan untuk memainkan semula semua acara.  Kesimpulan  Dalam artikel ini, kami menyemak beberapa pendekatan untuk membina pemesejan yang boleh dipercayai dalam sistem teragih. Terdapat beberapa cadangan yang mungkin kami pertimbangkan semasa membina sistem dengan ciri-ciri ini  Sentiasa membangunkan pengguna idempoten kerana kegagalan rangkaian tidak dapat dielakkan.  Berhati-hati menggunakan   dengan pemahaman yang jelas tentang keperluan jaminan. First-Local-Commit-Then-Publish  Jangan sekali-kali menggunakan pendekatan   kerana ia boleh menyebabkan ketidakkonsistenan data yang teruk dalam sistem anda. First-Publish-Then-Local-Commit  Jika keputusan pilihan pangkalan data sedia ada berkemungkinan besar mungkin berubah atau strategi teknikal membayangkan untuk memilih penyelesaian storan terbaik untuk masalah itu — jangan bina perpustakaan kongsi dengan mengikat kepada penyelesaian pangkalan data seperti   . CDC  Gunakan pendekatan   sebagai penyelesaian standard untuk mencapai sekurang-kurangnya sekali jaminan. Peti Keluar Transaksi  Pertimbangkan untuk menggunakan pendekatan   apabila pangkalan data No-SQL dimanfaatkan. Dengar sendiri  Kali seterusnya, kita akan melihat contoh yang lebih praktikal untuk melaksanakan Peti Keluar Transaksi. Lihat  awak!

Read My Stories

Audio ini dihasilkan dalam bahasa asal cerita!

Terlalu panjang; Untuk membaca

Make resilience your competitive advantage

Pemesejan Boleh Dipercayai dalam Sistem Teragih

About Author

KOMEN

GANTUNG TANDA

ARTIKEL INI DIBENTANGKAN DALAM

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps