Ketika Anda menggunakan operasi yang pada akhirnya konsisten yang terdiri dari serangkaian langkah, pola Kompensasi Transaksi dapat berguna. Secara khusus, jika satu atau beberapa langkah gagal, Anda dapat menggunakan pola Kompensasi Transaksi untuk membatalkan pekerjaan yang dilakukan langkah-langkah. Biasanya, Anda menemukan operasi yang mengikuti model konsistensi akhir dalam aplikasi yang dihosting cloud yang menerapkan proses dan alur kerja bisnis yang kompleks.
Konteks dan masalah
Aplikasi yang berjalan di cloud sering memodifikasi data. Data ini terkadang tersebar di berbagai sumber data di lokasi geografis yang berbeda. Untuk menghindari ketidaksesuaian dan meningkatkan performa dalam lingkungan terdistribusi, aplikasi tidak boleh mencoba memberikan konsistensi transaksional yang kuat. Sebaliknya, aplikasi harus menerapkan konsistensi akhirnya. Dalam model konsistensi akhirnya, operasi bisnis yang khas terdiri dari serangkaian langkah terpisah. Meskipun operasi melakukan langkah-langkah ini, tampilan keseluruhan status sistem mungkin tidak konsisten. Tetapi ketika operasi selesai dan semua langkah telah berjalan, sistem harus menjadi konsisten lagi.
Primer Konsistensi Data memberikan informasi tentang mengapa transaksi terdistribusi tidak diskalakan dengan baik. Sumber daya ini juga mencantumkan prinsip model konsistensi akhirnya.
Tantangan dalam model konsistensi akhirnya adalah cara menangani langkah yang gagal. Setelah kegagalan, Anda mungkin perlu membatalkan semua pekerjaan yang langkah-langkah sebelumnya dalam operasi selesai. Namun, Anda tidak selalu dapat mengembalikan data, karena instans bersamaan aplikasi lainnya mungkin telah mengubahnya. Bahkan dalam kasus di mana instans bersamaan belum mengubah data, membatalkan langkah mungkin lebih kompleks daripada memulihkan status asli. Mungkin perlu untuk menerapkan berbagai aturan khusus bisnis. Misalnya, lihat situs web perjalanan yang dijelaskan bagian Contoh nanti di artikel ini.
Jika operasi yang menerapkan konsistensi akhir mencakup beberapa penyimpanan data heterogen, membatalkan langkah-langkah dalam operasi mengharuskan mengunjungi setiap penyimpanan data secara bergantian. Untuk mencegah sistem tetap tidak konsisten, Anda harus dengan andal membatalkan pekerjaan yang Anda lakukan di setiap penyimpanan data.
Data yang terpengaruh oleh operasi yang menerapkan konsistensi akhir tidak selalu disimpan dalam database. Misalnya, pertimbangkan lingkungan arsitektur berorientasi layanan (SOA). Operasi SOA dapat memanggil tindakan dalam layanan dan menyebabkan perubahan status yang dipegang oleh layanan tersebut. Untuk membatalkan operasi, Anda juga harus membatalkan perubahan status ini. Proses ini dapat melibatkan pemanggilan layanan lagi dan melakukan tindakan lain yang membalikkan efek yang pertama.
Solusi
Solusinya adalah dengan menerapkan transaksi kompensasi. Langkah-langkah dalam transaksi kompensasi membatalkan efek dari langkah-langkah dalam operasi asli. Pendekatan intuitif adalah mengganti status saat ini dengan status sistem berada di awal operasi. Tetapi transaksi kompensasi tidak selalu dapat mengambil pendekatan itu, karena mungkin menimpa perubahan yang telah dilakukan oleh instans bersamaan aplikasi lainnya. Sebaliknya, transaksi kompensasi harus merupakan proses cerdas yang memperhitungkan pekerjaan apa pun yang dilakukan instans bersamaan. Proses ini biasanya khusus aplikasi, didorong oleh sifat pekerjaan yang dilakukan operasi asli.
Pendekatan umum menggunakan alur kerja untuk menerapkan operasi yang pada akhirnya konsisten yang membutuhkan kompensasi. Saat operasi asli berlanjut, sistem mencatat informasi tentang setiap langkah, termasuk cara membatalkan pekerjaan yang dilakukan langkah tersebut. Jika operasi gagal kapan saja, alur kerja memutar balik melalui langkah-langkah yang telah selesai. Pada setiap langkah, alur kerja melakukan pekerjaan yang membalikkan langkah tersebut.
Dua poin penting adalah:
- Transaksi kompensasi mungkin tidak perlu membatalkan pekerjaan dalam urutan terbalik yang tepat dari operasi asli.
- Mungkin untuk melakukan beberapa langkah batalkan secara paralel.
Pendekatan ini mirip dengan strategi Sagas yang dibahas dalam blog Clemens Vasters.
Transaksi kompensasi adalah operasi yang akhirnya konsisten itu sendiri, sehingga juga dapat gagal. Sistem harus dapat melanjutkan transaksi kompensasi pada titik kegagalan dan melanjutkan. Mungkin perlu mengulangi langkah yang gagal, jadi Anda harus menentukan langkah-langkah dalam transaksi kompensasi sebagai perintah idempotensi. Untuk informasi selengkapnya, lihat Pola Idempotency di blog Jonathan Oliver.
Dalam beberapa kasus, intervensi manual mungkin menjadi satu-satunya cara untuk pulih dari langkah yang gagal. Dalam situasi ini, sistem harus menaikkan pemberitahuan dan memberikan informasi sebanyak mungkin tentang alasan kegagalan.
Masalah dan pertimbangan
Pertimbangkan poin-poin berikut saat Anda memutuskan cara menerapkan pola ini:
Mungkin tidak mudah untuk menentukan kapan langkah dalam operasi yang menerapkan konsistensi akhirnya gagal. Langkah mungkin tidak langsung gagal. Sebaliknya, mungkin akan diblokir. Anda mungkin perlu menerapkan mekanisme waktu habis.
Tidak mudah untuk menggeneralisasi logika kompensasi. Transaksi kompensasi khusus aplikasi. Ini bergantung pada aplikasi yang memiliki cukup informasi untuk dapat membatalkan efek dari setiap langkah dalam operasi yang gagal.
Mengimbangi transaksi tidak selalu berfungsi. Anda harus menentukan langkah-langkah dalam transaksi kompensasi sebagai perintah idempotent. Jika Anda melakukannya, langkah-langkahnya dapat diulang jika transaksi kompensasi itu sendiri gagal.
Infrastruktur yang menangani langkah-langkah harus memenuhi kriteria berikut:
- Ini tangguh dalam operasi asli dan dalam transaksi kompensasi.
- Ini tidak kehilangan informasi yang diperlukan untuk mengkompensasi langkah yang gagal.
- Ini dengan andal memantau kemajuan logika kompensasi.
Transaksi kompensasi tidak selalu mengembalikan data sistem ke statusnya pada awal operasi asli. Sebaliknya, transaksi mengkompensasi pekerjaan yang berhasil diselesaikan operasi sebelum gagal.
Urutan langkah-langkah dalam transaksi kompensasi belum tentu merupakan kebalikan dari langkah-langkah dalam operasi asli. Misalnya, satu penyimpanan data mungkin lebih sensitif terhadap inkonsistensi daripada penyimpanan data lainnya. Langkah-langkah dalam transaksi kompensasi yang membatalkan perubahan pada penyimpanan ini harus terjadi terlebih dahulu.
Langkah-langkah tertentu dapat membantu meningkatkan kemungkinan bahwa aktivitas keseluruhan berhasil. Secara khusus, Anda dapat menempatkan kunci berbasis waktu habis jangka pendek pada setiap sumber daya yang diperlukan untuk menyelesaikan operasi. Anda juga dapat memperoleh sumber daya ini terlebih dahulu. Kemudian, lakukan pekerjaan hanya setelah Anda memperoleh semua sumber daya. Selesaikan semua tindakan sebelum kunci kedaluwarsa.
Logika coba lagi yang lebih pemaaf dari biasanya dapat membantu meminimalkan kegagalan yang memicu transaksi kompensasi. Jika langkah dalam operasi yang menerapkan konsistensi akhir gagal, coba tangani kegagalan sebagai pengecualian sementara dan ulangi langkah tersebut. Hentikan operasi dan mulai transaksi kompensasi hanya jika langkah gagal berulang kali atau tidak dapat dipulihkan.
Saat menerapkan transaksi kompensasi, Anda menghadapi banyak tantangan yang sama dengan yang Anda hadapi saat menerapkan konsistensi akhir. Untuk informasi selengkapnya, lihat bagian "Pertimbangan untuk Menerapkan Konsistensi Akhir" di Data Consistency Primer.
Kapan menggunakan pola ini
Gunakan pola ini hanya untuk operasi yang harus dibatalkan jika gagal. Jika memungkinkan, solusi desain untuk menghindari kompleksitas membutuhkan transaksi kompensasi.
Desain beban kerja
Arsitek harus mengevaluasi bagaimana pola Transaksi Kompensasi dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:
| Pilar | Bagaimana pola ini mendukung tujuan pilar |
|---|---|
| Keputusan desain keandalan membantu beban kerja Anda menjadi tahan terhadap kerusakan dan untuk memastikan bahwa keputusan tersebut pulih ke status berfungsi penuh setelah kegagalan terjadi. | Tindakan kompensasi mengatasi kerusakan dalam jalur beban kerja penting dengan menggunakan proses seperti secara langsung menggulung balik perubahan data, merusak kunci transaksi, atau bahkan menjalankan perilaku sistem asli untuk membalikkan efek. - ALUR KRITIS RE:02 - RE:09 Pemulihan bencana |
Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.
Contoh
Pelanggan menggunakan situs web perjalanan untuk memesan rencana perjalanan. Satu rencana perjalanan mungkin terdiri dari serangkaian penerbangan dan hotel. Pelanggan yang melakukan perjalanan dari Seattle ke London dan kemudian ke Paris mungkin melakukan langkah-langkah berikut saat membuat rencana perjalanan:
- Pesan kursi di penerbangan F1 dari Seattle ke London.
- Pesan kursi di penerbangan F2 dari London ke Paris.
- Pesan kursi di penerbangan F3 dari Paris ke Seattle.
- Pesan kamar di hotel H1 di London.
- Pesan kamar di hotel H2 di Paris.
Langkah-langkah tersebut merupakan operasi yang akhirnya konsisten, meskipun setiap langkah merupakan tindakan yang terpisah. Selain melakukan langkah-langkah ini, sistem juga harus merekam operasi penghitung untuk membatalkan setiap langkah. Informasi ini diperlukan jika pelanggan membatalkan rencana perjalanan. Langkah-langkah yang diperlukan untuk melakukan operasi penghitung kemudian dapat berjalan sebagai transaksi kompensasi.
Langkah-langkah dalam transaksi kompensasi mungkin bukan kebalikan dari langkah-langkah asli. Selain itu, logika di setiap langkah dalam transaksi kompensasi harus mempertimbangkan aturan khusus bisnis. Misalnya, membatalkan reservasi penerbangan mungkin tidak memberi pelanggan pengembalian dana sepenuhnya.
Gambar berikut menunjukkan langkah-langkah dalam transaksi jangka panjang untuk memesan rencana perjalanan. Anda juga dapat melihat langkah-langkah kompensasi transaksi yang membatalkan transaksi.
Catatan
Anda mungkin dapat melakukan langkah-langkah dalam mengkompensasi transaksi secara paralel, tergantung pada bagaimana Anda merancang logika kompensasi untuk setiap langkah.
Dalam banyak solusi bisnis, kegagalan satu langkah tidak selalu mengharuskan menggulung balik sistem dengan menggunakan transaksi kompensasi. Misalnya, pertimbangkan skenario situs web perjalanan. Misalkan pelanggan memesan penerbangan F1, F2, dan F3 tetapi tidak dapat memesan kamar di hotel H1. Lebih baik menawarkan kamar kepada pelanggan di hotel yang berbeda di kota yang sama daripada membatalkan penerbangan. Pelanggan masih dapat memutuskan untuk membatalkan. Dalam hal ini, transaksi kompensasi berjalan dan membatalkan pemesanan untuk penerbangan F1, F2, dan F3. Tetapi pelanggan harus membuat keputusan ini, bukan sistem.
Langkah berikutnya
- Data Consistency Primer. Pola Transaksi Kompensasi sering digunakan untuk membatalkan operasi yang menerapkan model konsistensi akhirnya. Primer ini memberikan informasi tentang manfaat dan trade-off dari konsistensi akhir.
- Pola Idempotensi. Dalam transaksi kompensasi, yang terbaik adalah menggunakan perintah idempogen. Posting blog ini menjelaskan faktor-faktor yang perlu dipertimbangkan ketika Anda menerapkan idempotensi.
Sumber daya terkait
- Pola Pengawas Agen Penjadwal. Artikel ini menjelaskan cara menerapkan sistem tangguh yang melakukan operasi bisnis yang menggunakan layanan dan sumber daya terdistribusi. Dalam sistem ini, Anda terkadang perlu menggunakan transaksi kompensasi untuk membatalkan pekerjaan yang dilakukan operasi.
- Pola percobaan ulang. Mengkompensasi transaksi dapat secara komputasi menuntut. Anda dapat mencoba meminimalkan penggunaannya dengan menggunakan pola Coba Lagi untuk menerapkan kebijakan efektif untuk mencoba kembali operasi yang gagal.
- Pola transaksi terdistribusi Saga. Artikel ini menjelaskan cara menggunakan pola Saga untuk mengelola konsistensi data di seluruh layanan mikro dalam skenario transaksi terdistribusi. Pola Saga menangani pemulihan kegagalan dengan mengimbangi transaksi.
- Pola Pipa dan Filter. Artikel ini menjelaskan pola Pipa dan Filter, yang dapat Anda gunakan untuk menguraikan tugas pemrosesan kompleks ke dalam serangkaian elemen yang dapat digunakan kembali. Anda dapat menggunakan pola Pipa dan Filter dengan pola Kompensasi Transaksi sebagai alternatif untuk menerapkan transaksi terdistribusi.
- Desain untuk penyembuhan diri. Panduan ini menjelaskan cara merancang aplikasi penyembuhan diri. Anda dapat menggunakan kompensasi transaksi sebagai bagian dari pendekatan penyembuhan diri.