Spesifikasi XA
XA adalah spesifikasi antarmuka (yaitu, fungsi antarmuka) antara middleware transaksi dan database yang ditentukan oleh X/Open DTP, yang digunakan oleh middleware transaksi untuk memberi tahu database tentang awal, akhir, komitmen, rollback, dll. transaksi. Fungsi antarmuka XA disediakan oleh vendor database.
Perjanjian pengajuan orde kedua dan perjanjian pengajuan orde ketiga berasal dari ide ini. Dapat dikatakan bahwa commit dua tahap sebenarnya adalah kunci untuk mengimplementasikan transaksi terdistribusi XA (tepatnya: commit dua tahap terutama memastikan atomisitas transaksi terdistribusi: yaitu, semua node melakukan semua atau tidak sama sekali)
2 Buah
Komitmen Dua Fase mengacu pada algoritma yang dirancang untuk menjaga konsistensi dalam penerapan transaksi untuk semua node berdasarkan arsitektur sistem terdistribusi di bidang jaringan komputer dan database. Seringkali, commit dua tahap juga disebut sebagai protokol. Dalam sistem terdistribusi, setiap node dapat mengetahui keberhasilan atau kegagalan operasinya sendiri, tetapi tidak dapat mengetahui keberhasilan atau kegagalan operasi node lain. Ketika transaksi menjangkau beberapa node, untuk mempertahankan karakteristik ACID transaksi, komponen yang bertindak sebagai koordinator perlu diperkenalkan untuk mengontrol hasil semua node (disebut peserta) dan pada akhirnya menginstruksikan node ini untuk benar-benar mengirimkan hasil (seperti menulis data yang diperbarui ke disk, dll.). Oleh karena itu, ide algoritma dari pengajuan dua tahap dapat diringkas sebagai berikut: peserta akan memberi tahu koordinator tentang keberhasilan atau kegagalan operasi, dan kemudian koordinator akan memutuskan apakah akan mengajukan operasi atau membatalkan operasi berdasarkan informasi umpan balik dari semua peserta.
Yang disebut dua tahap adalah: tahap pertama: tahap persiapan (tahap pemungutan suara) dan tahap kedua: tahap pengajuan (tahap eksekusi).
Tahap persiapan
Koordinator transaksi (manajer transaksi) mengirimkan pesan Siapkan ke setiap peserta (manajer sumber daya), dan setiap peserta mengembalikan kegagalan secara langsung (seperti verifikasi izin yang gagal), atau mengeksekusi transaksi secara lokal, menulis log pengulangan dan pembatalan lokal, tetapi tidak melakukan, dan mencapai status "semuanya siap, hanya angin timur yang terutang".
Tahap persiapan dapat dibagi lagi menjadi tiga langkah berikut:
1) Node koordinator bertanya kepada semua node peserta apakah mereka dapat melakukan pemungutan suara dan mulai menunggu tanggapan dari setiap node peserta.
2) Simpul peserta melakukan semua operasi transaksi hingga kueri dimulai, dan menulis informasi Urungkan dan Ulangi informasi ke log. (Catatan: Jika berhasil, setiap peserta telah melakukan operasi transaksi)
3) Setiap simpul peserta menanggapi pertanyaan yang diprakarsai oleh simpul koordinator. Jika operasi transaksi node peserta benar-benar berhasil dieksekusi, itu mengembalikan pesan "Setuju"; Jika operasi transaksi simpul peserta benar-benar gagal, itu mengembalikan pesan "dibatalkan".
Tahap pengiriman
Jika koordinator menerima pesan kegagalan atau batas waktu dari peserta, koordinator akan mengirimkan pesan rollback langsung ke setiap peserta. Jika tidak, kirim pesan Commit ; Peserta melakukan operasi commit atau rollback sesuai dengan instruksi koordinator untuk melepaskan semua sumber daya kunci yang digunakan dalam proses transaksi. (Catatan: Sumber daya kunci harus dirilis di tahap akhir)
Selanjutnya, proses tahap pengajuan dibahas secara terpisah dalam dua kasus.
Ketika pesan terkait yang diterima oleh simpul koordinator dari semua simpul peserta adalah Setuju:
Tahap pengiriman
Jika koordinator menerima pesan kegagalan atau batas waktu dari peserta, koordinator akan mengirimkan pesan rollback langsung ke setiap peserta. Jika tidak, kirim pesan Commit ; Peserta melakukan operasi commit atau rollback sesuai dengan instruksi koordinator untuk melepaskan semua sumber daya kunci yang digunakan dalam proses transaksi. (Catatan: Sumber daya kunci harus dirilis di tahap akhir)
Selanjutnya, proses tahap pengajuan dibahas secara terpisah dalam dua kasus.
Ketika pesan terkait yang diterima oleh simpul koordinator dari semua simpul peserta adalah Setuju:
1) Node koordinator mengeluarkan permintaan "komitmen" ke semua node peserta.
2) Node peserta secara resmi menyelesaikan operasi dan melepaskan sumber daya yang ditempati selama periode transaksi.
3) Node peserta mengirimkan pesan "Selesai" ke node koordinator.
4) Node koordinator menyelesaikan transaksi setelah menerima umpan balik pesan "Selesai" dari semua node peserta.
1) Node koordinator mengeluarkan permintaan "rollback" ke semua node peserta.
2) Node peserta menggunakan informasi Undo yang ditulis sebelumnya untuk melakukan rollback dan melepaskan sumber daya yang ditempati selama periode transaksi.
3) Node peserta mengirimkan pesan "rollback complete" ke node koordinator.
4) Node koordinator membatalkan transaksi setelah menerima umpan balik pesan "Rollback Complete" dari semua node peserta.
Komitmen fase 2 tampaknya menyediakan operasi atom, tetapi sayangnya, commit tahap 2 masih memiliki beberapa kekurangan:
1. Masalah pemblokiran sinkron. Selama eksekusi, semua node yang berpartisipasi melakukan pemblokiran transaksi. Saat peserta menempati sumber daya publik, simpul pihak ketiga lainnya harus diblokir untuk mengakses sumber daya publik.
2. Titik kegagalan tunggal. Karena pentingnya koordinator, sekali koordinator gagal. Para peserta akan terus memblokir penyumbatan. Apalagi pada tahap kedua, jika koordinator gagal, semua peserta masih dalam keadaan mengunci sumber daya transaksi dan tidak dapat melanjutkan untuk menyelesaikan operasi transaksi. (Jika koordinator menutup telepon, Anda dapat memilih kembali koordinator, tetapi tidak dapat menyelesaikan masalah bahwa peserta diblokir karena koordinator turun)
3. Inkonsistensi data. Pada tahap kedua dari commit tahap kedua, ketika koordinator mengirimkan permintaan commit ke peserta, pengecualian jaringan lokal terjadi atau koordinator gagal selama proses permintaan commit yang menyebabkan hanya beberapa peserta yang menerima permintaan commit tersebut. Setelah menerima permintaan penerapan ini, peserta ini akan melakukan operasi penerapan tersebut. Namun, mesin lain yang tidak menerima permintaan penerapan tidak dapat mengeksekusi penerapan transaksi. Akibatnya, konsistensi departemen data terjadi di seluruh sistem terdistribusi.
4. Masalah yang tidak dapat diselesaikan pada tahap kedua: Koordinator turun setelah mengirim pesan komit, dan satu-satunya peserta yang menerima pesan ini juga down. Jadi kalaupun fasilitator memilih fasilitator baru melalui perjanjian pemilihan, status transaksi tidak pasti, dan tidak ada yang tahu apakah transaksi tersebut telah diajukan.
3 Buah
Tiga fase commit, juga dikenal sebagai protokol tiga fase komit, adalah versi yang ditingkatkan dari commit dua fase (2PC).
Tidak seperti penerapan dua tahap, ada dua perubahan pada penerapan tiga tahap.
1. Perkenalkan mekanisme batas waktu. Pada saat yang sama, mekanisme batas waktu diperkenalkan baik pada fasilitator maupun peserta.
2. Masukkan tahap persiapan pada tahap pertama dan kedua. Ini memastikan bahwa status semua simpul yang berpartisipasi konsisten hingga tahap penerapan akhir.
Dengan kata lain, selain memperkenalkan mekanisme timeout, 3PC sekali lagi membagi tahap persiapan 2PC menjadi dua, sehingga ada tiga tahap CanCommit, PreCommit, dan DoCommit dalam tiga tahap commit.
Tahap CanCommit
Tahap CanCommit 3PC sebenarnya sangat mirip dengan tahap persiapan 2PC. Koordinator mengirimkan permintaan penerapan ke peserta, yang mengembalikan respons Ya jika mereka dapat melakukan komitmen, atau respons Tidak.
1. Pertanyaan Transaksi: Fasilitator mengirimkan permintaan CanCommit kepada peserta. Tanyakan apakah Anda dapat melakukan operasi penerapan transaksi. Kemudian mulailah menunggu tanggapan dari peserta.
2. Tanggapan Umpan Balik Setelah menerima permintaan CanCommit, peserta akan mengembalikan tanggapan Ya dan masuk ke status siap jika menganggap transaksi dapat dieksekusi dengan lancar. Jika tidak, umpan balik Tidak
Fase PraKomitmen
Fasilitator memutuskan apakah akan menghafal operasi PreCommit transaksi berdasarkan respons peserta atau tidak. Tergantung pada tanggapannya, ada dua kemungkinan.
Jika umpan balik yang diterima fasilitator dari semua peserta adalah jawaban Ya, maka pra-eksekusi transaksi dilakukan.
1. Kirim Permintaan PreCommit Fasilitator mengirimkan permintaan PreCommit kepada peserta dan melanjutkan ke tahap Persiapan.
2. Pra-Komitmen Transaksi Setelah peserta menerima permintaan PreCommit, peserta melakukan operasi transaksi dan mencatat informasi pembatalan dan pengulangan dalam log transaksi.
3. Umpan Balik Respons Jika peserta berhasil menjalankan operasi transaksi, respons ACK dikembalikan sambil mulai menunggu instruksi akhir.
1. Kirim permintaan interupsi Fasilitator mengirimkan permintaan pembatalan ke semua peserta.
2. Menghentikan transaksi Setelah peserta menerima permintaan ABORT dari koordinator (atau setelah batas waktu, permintaan dari koordinator belum diterima), interupsi transaksi dieksekusi.
Tahap komitmen transaksi nyata ini juga dapat dibagi menjadi dua situasi berikut.
Melakukan penerapan
1. Kirim permintaan commit Koordinasi menerima respons ACK yang dikirim oleh peserta, kemudian dia akan beralih dari status pra-commit ke status commit. dan mengirim permintaan doCommit ke semua peserta.
2. Pengajuan Transaksi Setelah menerima permintaan doCommit, peserta mengeksekusi commit transaksi formal. dan melepaskan semua sumber daya transaksi setelah menyelesaikan penerapan transaksi.
3. Tanggapi umpan balik Setelah transaksi diajukan, kirimkan tanggapan Ack ke koordinator.
4. Selesaikan transaksi Setelah koordinator menerima respon ACK dari semua peserta, transaksi selesai.
Jika koordinator tidak menerima respons ACK dari peserta (mungkin bukan respons ACK dari penerima, atau respons mungkin telah habis waktunya), maka transaksi interupsi dieksekusi.
1. Kirim permintaan interupsi Fasilitator mengirimkan permintaan pembatalan ke semua peserta
2. Pengembalian Transaksi Setelah menerima permintaan ABORT, peserta menggunakan informasi pembatalan yang tercatat dalam Fase 2 untuk melakukan operasi pengembalian transaksi, dan melepaskan semua sumber daya transaksi setelah menyelesaikan pengembalian.
3. Hasil umpan balik Setelah peserta menyelesaikan rollback transaksi, kirim pesan ACK ke koordinator
4. Menghentikan transaksi Setelah koordinator menerima pesan ACK dari peserta, transaksi terganggu.
Perbedaan antara 2PC dan 3PC
Relatif terhadap 2PC, 3PC terutama memecahkan masalah titik kegagalan tunggal dan mengurangi pemblokiran, karena begitu peserta gagal menerima pesan dari koordinator tepat waktu, ia mengeksekusi commit secara default. Alih-alih menahan sumber daya transaksi sepanjang waktu dan berada dalam keadaan pemblokiran. Namun mekanisme ini juga menyebabkan masalah konsistensi data, karena respons pembatalan yang dikirim oleh koordinator tidak diterima oleh peserta tepat waktu karena alasan jaringan, kemudian peserta mengeksekusi operasi commit setelah menunggu timeout. Ini menciptakan inkonsistensi data dengan peserta lain yang menerima perintah pembatalan dan melakukan pengembalian.
|
Diposting pada 17/03/2021 10.15.10
|
|
|
