Distribusi grafis: konsistensi akhir, konsistensi hanya akan terlambat, tetapi tidak pernah absen

Dalam artikel ini, kami terus membahas konten terkait yang didistribusikan.

Dalam hal sistem terdistribusi, "konsistensi" tidak dapat dihindari, kali ini kita akan berbicara tentang konsistensi akhir.

Konsistensi tertinggi adalah gagasan inti dari sebagian besar sistem terdistribusi yang tersedia.

Diperkirakan beberapa orang belum memahami konsistensi akhir, mari kita beri pengantar singkat:

Konsistensi akhir mengacu pada fakta bahwa semua data yang tersebar di node yang berbeda dalam sistem akhirnya dapat mencapai keadaan konsisten yang memenuhi definisi bisnis setelah jangka waktu tertentu.

Fokus pada:

  1. Ini adalah konsistensi data, bukan konsistensi transaksi (ACID adalah konsistensi transaksi);
  2. Kondisi keberadaan: banyak node / sistem;
  3. Ketidakkonsistenan mungkin bersifat sementara, tetapi harus konsisten pada akhirnya (hantu tahu berapa lama "akhirnya")

Oke, teksnya dimulai.

Jangan melihat permukaan sungai yang datar seperti cermin, tetapi lihatlah dasar airnya

Singkatnya, konsistensi ultimat, prosesnya longgar dan hasilnya ketat. Terlepas dari proses perantara, hasilnya harus memenuhi persyaratan bisnis dan memenuhi persyaratan konsistensi data.

Meskipun dalam implementasinya ada berbagai skema, namun ide dasarnya tetap sama. Marilah kita sekarang mengabaikan proses kebingungan dan menyelidiki esensi dari konsistensi akhir.

Apa masalahnya menjadi miskin dan tidak miskin? Kekacauan itu sama dengan waktu murni

Saat pertama kali masuk industri, kemampuan saya terbatas, saya masih pemula dan hanya bisa membuat beberapa modul fungsional kecil. Yang paling membuat saya terkesan adalah modul pesanan.

Pengguna menempatkan pesanan, dan modul pesanan menjalankan logika bisnis pesanan yang sesuai setelah menerima permintaan pesanan. Terakhir, pesanan akan dimasukkan ke dalam tabel pesanan, dan hasil pesanan akan dikembalikan ke pengguna. Setelah pengguna menyelesaikan, modul pesanan akan memperbarui status pesanan sesuai dengan situasi pembayaran.

Mengenai hal ini, bagi saya seorang technical scum, pada awalnya membutuhkan banyak tangan dan kaki, namun pada akhirnya saya menjadi tangan yang familiar, dan saya menjadi terbiasa dengan perawatan modul ini.

Setelah kehidupan kecil yang sederhana untuk sementara waktu, tugas baru ada di sini!

Manajer produk memberi tahu saya bahwa departemen audit data menginginkan modul pesanan yang saya pelihara untuk mendistribusikan data pesanan kepada mereka tepat waktu setelah pesanan selesai. Mereka menyediakan antarmuka bagi saya untuk mengirim data langsung kepada mereka.

Dua masalah muncul:

Masalah 1: Waktu tunggu pengguna menjadi lebih lama

Implementasi yang paling sederhana adalah setelah saya memperbarui data pesanan, saya memanggil antarmuka yang diberikan oleh departemen audit data untuk meneruskan data pesanan.

Namun, rangkaian proses dari penyelesaian pengguna yang berhasil hingga pembaruan status pesanan disinkronkan, dengan asumsi bahwa waktu yang dibutuhkan untuk rangkaian proses ini adalah n milidetik. Ini berarti pengguna harus menunggu setidaknya n milidetik. Jika waktu operasi yang diunggah ke departemen audit data ditambahkan, dengan asumsi m milidetik, seluruh pengguna harus menunggu selama n + m milidetik.

Biaya waktu tunggu untuk pengguna seluruh fungsi meningkat dan pengalaman menurun. Seperti yang ditunjukkan di bawah ini:

Pertanyaan 2: Keberhasilan sebagian, kegagalan sebagian

Setelah memperkenalkan antarmuka baru, memanggil antarmuka ini mungkin gagal pada waktu-waktu tertentu, seperti masalah jaringan, masalah verifikasi, dan kegagalan layanan antarmuka, karena berbagai alasan. Jadi pertanyaannya adalah, apa yang harus dilakukan jika antarmuka baru gagal?

Jika pembaruan pesanan berhasil, gagal saat dikirim ke departemen audit data. Situasi ini akan membuat pemrosesan modul pesanan selanjutnya menjadi sangat memalukan.

Pertama-tama, Anda tidak dapat kembali ke klien untuk mengatakan bahwa penyelesaian Anda gagal kali ini, dan permintaan tidak gagal. Mengapa Anda mengatakan bahwa orang lain gagal? Kedua, Anda tidak bisa mengatakan bahwa bisnis ini sukses, karena audit data sebenarnya cukup penting, merupakan bagian penting dari business logic.

Ini benar-benar dilema.
Masukkan deskripsi gambar di sini

Salah satu solusi untuk kedua masalah ini adalah konsistensi akhirnya.

Kami telah berbicara tentang CAP sebelumnya, mengetahui bahwa jika Anda mengorbankan tingkat konsistensi tertentu, Anda dapat menjamin ketersediaan dan toleransi kesalahan partisi. Konsistensi utama adalah bahwa tidak ada jaminan bahwa semua data akan memenuhi kebutuhan bisnis pada saat yang sama, tetapi kami dapat menjamin bahwa setiap saat layanan tersedia secara internal untuk layanan eksternal.

Kakak keempat, saya biasanya suka bermain game, jadi mari kita gunakan contoh membeli Switch on Taobao untuk menjelaskan konsistensi terakhir:

Jika Anda ingin membeli game versi digital dan Switch on Taobao secara bersamaan, Anda bisa mendapatkan versi digital dari game tersebut segera setelah Anda membayar, tetapi untuk Switch yang dibeli, Anda harus menunggu beberapa hari, Tunggu sampai pengiriman ekspres tiba di rumah.

Mari kita pilah detail dari contoh ini:

  • Pertama-tama, harus ada pedagang di Taobao yang menjual Switch dan game digital kepada pelanggan untuk menerima pesanan kami dan memberi Anda nomor pelacakan.
  • Anda mendapatkan versi digital dari game tersebut, tetapi Anda tidak mendapatkan Switchnya.
  • Anda tidak tahu bagaimana Switch disiapkan untuk Anda di belakang pedagang ini. Apakah karena dia harus pergi ke pedagang lain untuk menyeberang barang ketika dia kehabisan stok, atau menunggu dua hari sebelum mengirimkannya kepada Anda (keterlambatan pengiriman dapat memberi Anda sesuatu yang lain) Alasannya tidak akan terulang). Ini tidak penting, yang penting adalah Anda menjelaskan bahwa pihak lain akan menyelesaikan pesanan setelah dia mengambil pesanan.
  • Setelah pesanan Anda berhasil dilakukan, Anda akan memiliki jaminan. Anda akhirnya akan mendapatkan Switch, tetapi Anda mungkin tidak yakin kapan akan menerimanya.

Setelah beberapa hari, Anda akhirnya menerima barangnya, selamat atas keberhasilan Anda masuk ke Switch.

Contoh di atas adalah apa yang kami sebut konsistensi akhir. Namun, ada satu hal yang sangat, sangat penting yang belum disorot, yaitu, apa alasan yang mendorong kami untuk menggunakan konsistensi akhir?

Jawabannya adalah distribusi data.

Hanya di atas kertas saya merasa dangkal, dan saya benar-benar tahu bagaimana melakukannya

Mengapa kita membutuhkan konsistensi akhir?

Karena kita perlu mendistribusikan data ke tempat yang berbeda, dan karena data didistribusikan ke tempat yang berbeda, hal itu akan menyebabkan ketidakkonsistenan dalam keberhasilan atau kegagalan distribusi dalam proses distribusi menengah, dan gagasan konsistensi akhirnya diperlukan untuk menangani. dengan Terjadi ini.

Hmm, sebarkan datanya ... Oke, apa menurut Anda?
Masukkan deskripsi gambar di sini

Benar, situasi distribusi data dapat ditangani dengan mendistribusikan pesan melalui MQ, dan ini adalah cara yang paling umum digunakan untuk mencapai konsistensi akhir.

Kami mengemas data untuk didistribusikan ke dalam pesan, dan kemudian mengirimkannya ke middleware MQ. Middleware akan menyiarkan data ini ke semua layanan yang ingin menerima pesan ini. Layanan ini yang menerima pesan secara mandiri memproses data sesuai dengan kondisi bisnis mereka sendiri.

Kembali ke contoh modul pesanan kami, kami dapat menggunakan konsistensi akhirnya dalam dua cara.

  1. Masukkan database terlebih dahulu, kemudian kirim pesan ke data audit
    Masukkan deskripsi gambar di sini

Dengan cara ini, modul pesanan pertama-tama memperbarui status pesanan. Kemudian, kemas data pesanan menjadi pesan dan kirimkan ke MQ, dan tugas modul pesanan selesai. Tugas yang tersisa adalah agar departemen audit data melakukan pemrosesan yang sesuai setelah mendapatkan pesan dari MQ sesuai dengan bisnisnya sendiri.

Dalam metode ini, kami tidak hanya memastikan bahwa pembaruan database berhasil, tetapi juga bahwa datanya dikirim ke MQ. Akhirnya, ketika departemen audit data menerima pesan tersebut dan melakukan pemrosesan yang sesuai berdasarkan konten pesan, keseluruhan data mencapai keadaan akhir yang konsisten.

  1. Masukkan hanya ke MQ

Dengan cara ini, setelah order module secara langsung menerima permintaan, ia mengemas data ke dalam pesan dan meletakkannya di MQ.

Kemudian, modul pesanan itu sendiri dan layanan departemen audit data masing-masing mendapatkan pesan yang sesuai dari MQ, dan kemudian memperbarui database sesuai dengan logika bisnis mereka sendiri, dan mereka harus melalui audit mereka sendiri, dan akhirnya mencapai status Konsisten.

Teratai kecil menunjukkan tanduknya yang tajam, dan capung telah lama berada di atas kepala mereka

Dalam contoh di atas, kami menjelaskan ide inti dari konsistensi akhir.Kami tidak menjamin bahwa status data dapat memenuhi persyaratan bisnis secara real time, tetapi seperti belanja online kami, kami dapat menjamin bahwa kebutuhan bisnis akan terpenuhi setelah jangka waktu tertentu.

Namun, meskipun sederhana untuk mengatakannya, di manakah dunia ini begitu mudah? Menurut bisnis yang berbeda, konsistensi akhir telah membedakan berbagai gagasan realisasi. seperti,

Coba lagi + mode mundur

Saat kami melakukan pembayaran, kami perlu menyimpan akun. Jika akun tidak berhasil, kami mungkin ingin mencoba lagi sebanyak mungkin. Saat percobaan ulang mencapai batas tertentu, kami bahkan perlu memberi tahu sistem upstream untuk menyediakan antarmuka coba lagi dan pembatalan, sehingga downstream dapat memberi tahu upstream untuk mengirim ulang pesan, atau untuk sementara membatalkan operasi.

Mode tugas perbaikan

Setelah kami gagal melakukan pembayaran dan akuntansi, kami mencoba mode coba lagi + mundur untuk membatalkan operasi, kemudian kami dapat membuat tugas perbaikan saat ini, dan kemudian melakukan tugas ini ketika kami dapat memastikan bahwa akuntansi berhasil.

Mode pesan asinkron

Ketika kita melakukan transfer, kita harus memastikan bahwa transfer A keluar dan transfer B ke dalam jenis bisnis ini sangat konsisten. Namun, layanan silang mungkin diperlukan saat ini. Di saat yang sama, kami juga ingin memastikan performa semaksimal mungkin. Kemudian, saat ini, pertama-tama kita dapat membuat operasi tulis lokal ke database dan pesan yang perlu lintas layanan menjadi transaksi, dan kemudian, sesuai dengan status pesan yang sedang diproses, keseluruhan transaksi dilakukan dan digulung kembali.

Dapat dilihat bahwa ada banyak cara untuk mencapai konsistensi akhir, tetapi tidak pernah bisa lepas dari inti, yang mendistribusikan data melalui antrian pesan. Setelah memahami prinsip fundamental ini, akan lebih mudah bagi kita untuk memahami berbagai transaksi terdistribusi dan konsensus terdistribusi di masa mendatang.

Selesai

Comments

Popular posts from this blog

Apakah alien hidup di alam semesta? Atau hidup di bumi?

Prediksi tren mandiri 2021: model butik menempati arus utama, ketiga jenis penjual ini lebih kompetitif