Masalah
Hampir semua sistem informasi membutuhkan penyimpanan data secara berkelanjutan. Di sebagian besar sistem dengan beban kecil dan menengah, fungsi ini dilakukan oleh DBMS relasional, yang keunggulannya tidak dapat disangkal adalah jaminan konsistensi data.
Contoh klasik yang menjelaskan apa itu konsistensi data - operasi transfer dana dari satu akun ke akun lainnya. Pada saat operasi mengubah saldo dari satu akun telah selesai dan yang lain belum punya waktu, kegagalan dapat terjadi. Kemudian dana akan didebit dari satu akun, tetapi tidak akan dikreditkan ke akun lain. Keadaan sistem data ini disebut tidak konsisten, dan, mungkin, tidak perlu menjelaskan apa akibatnya. DBMS relasional menyediakan mekanisme transaksi yang menjamin konsistensi data pada waktu tertentu. Suatu transaksi adalah serangkaian operasi terbatas yang mentransfer satu status konsisten ke status konsisten lainnya.
Jika terjadi kesalahan pada langkah apa pun, DBMS membatalkan semua operasi yang dilakukan sebelumnya dan mengembalikan data ke kondisi semula yang disepakati. Dengan kata lain, semua operasi akan dilakukan, atau tidak satu pun.
Adapun sistem skala besar, jauh dari selalu mungkin untuk menggunakan satu database di dalamnya karena beban yang terlalu berat. Dalam kasus seperti itu, setiap modul sistem (layanan) disediakan dengan basis datanya sendiri yang terpisah. Dalam kasus ini, muncul pertanyaan bagaimana memastikan konsistensi data untuk arsitektur cluster tersebut.
Memecahkan Konsistensi Data
Salah satu solusinya adalah transaksi terdistribusi. Pertama, semua node cluster harus menyetujui bahwa operasi itu mungkin, maka perubahan dilakukan ke semua node. Karena node tidak memiliki perangkat penyimpanan umum, satu-satunya cara untuk mencapai pendapat umum adalah dengan menyetujui menggunakan beberapa protokol konsensus terdistribusi.
Protokol sederhana untuk menangkap transaksi global adalah komitmen dua fase (2PC). Node yang melakukan transaksi dianggap sebagai koordinator. Pada tahap persiapan (persiapan), koordinator memberi tahu node lain tentang komit transaksi dan menunggu konfirmasi dari mereka bahwa mereka siap berkomitmen. Jika setidaknya satu node tidak siap, transaksi terputus. Pada fase komit, koordinator menginformasikan semua node keputusan untuk melakukan transaksi. Setelah menerima konfirmasi dari semua orang bahwa semuanya baik-baik saja, koordinator juga menangkap transaksi.
Gambar 1 - Skema umum dari komitmen dua fase
Protokol ini menghindari pesan minimum, tetapi tidak kuat. Misalnya, jika koordinator gagal setelah fase persiapan, node yang tersisa tidak memiliki informasi tentang apakah transaksi harus dilakukan atau dibatalkan (mereka harus menunggu kegagalan diperbaiki). Kelemahan serius lain dari 2PC (dan protokol transaksi terdistribusi lainnya, misalnya 3PC) adalah bahwa ketika jumlah node cluster bertambah, kinerja dari komitmen dua fase menurun.
Gambar 2 - Ketergantungan kecepatan komit dua-basis pada jumlah server dalam cluster DBMS
Selain itu, pendekatan transaksi terdistribusi memberlakukan batasan: semua modul sistem harus menggunakan DBMS yang sama, yang tidak selalu nyaman.
Pilihan lain adalah menyediakan mekanisme yang memungkinkan Anda untuk bekerja dengan basis data berbeda (untuk layanan) sebagai satu basis data (untuk menyelesaikan masalah dengan integritas data dalam basis data terdistribusi). Pada saat yang sama, analog tertentu dari suatu transaksi untuk sistem terdistribusi ("transaksi bisnis") diperlukan.
Dalam transaksi biasa, serta dalam komitmen dua fase, semua operasi dikendalikan oleh mekanisme transaksi (menggunakan kunci), dan ini dilakukan untuk memberikan kemampuan untuk memutar kembali operasi apa pun (pendekatan pesimistis - kami menganggap setiap operasi berpotensi menyebabkan kegagalan). Ini adalah hambatan dari sistem. Alternatifnya adalah apa yang disebut pendekatan optimis: kami percaya bahwa sebagian besar operasi diselesaikan dengan sukses. Kami juga melakukan tindakan tambahan atas fakta kegagalan. Yaitu mengurangi biaya untuk sebagian besar operasi, yang mengarah pada peningkatan produktivitas.
Apa itu Saga dan bagaimana cara kerjanya
Alternatif transaksi untuk arsitektur layanan mikro adalah Saga. Saga (saga) adalah serangkaian langkah yang dilakukan oleh berbagai modul sistem (layanan); Layanan saga juga diperlukan, yang bertanggung jawab untuk operasi (transaksi bisnis) secara keseluruhan. Langkah-langkah dihubungkan melalui grafik acara. Setelah saga selesai, sistem harus pergi dari satu negara yang disepakati ke negara lain (jika eksekusi berhasil), atau kembali ke negara yang disepakati sebelumnya (jika terjadi pembatalan).
Bagaimana cara menerapkan pengembalian atau kemunduran dari transaksi bisnis? Untuk melakukan ini, hikayat ini menggunakan mekanisme pembatalan langkah-langkah (tindakan kompensasi). Misalnya, salah satu langkah berhasil (misalnya, entri ditambahkan ke tabel database pengguna), tetapi salah satu langkah berikut gagal, dan seluruh kisah harus dibatalkan. Kemudian layanan yang sama menerima perintah - batalkan tindakan. Namun dalam DBMS layanan, transaksi lokal telah selesai, catatan pengguna telah ditambahkan. Kemudian, untuk kembali ke keadaan sebelumnya, layanan harus melakukan tindakan kompensasi (dalam contoh kami, hapus catatan). Pembatalan langkah-langkah memungkinkan atomicity ("semua atau tidak sama sekali") diimplementasikan dalam kerangka saga - semua langkah dilakukan atau dikompensasi.
Gambar 3 - Mekanisme Saga dan sifat dari efek kompensasi
Pada Gambar 3, langkah-langkah saga ditetapkan sebagai T1 ... T4, tindakan kompensasi: C1 ... C4.
Sagas mendukung idempotensi langkah (tindakan yang pengulangan berulangnya setara dengan satu langkah). Pendekatan sag memberikan kesempatan untuk mengulangi langkah apa pun (misalnya, jika Anda tidak menerima respons atas penyelesaian yang berhasil). Idempotency juga memungkinkan Anda untuk memulihkan keadaan saat data hilang pada sembarang simpul (kegagalan dan pemulihan). Saat melakukan langkah, setiap layanan harus menentukan (dengan kunci idempotency) apakah sudah melakukan langkah ini atau tidak (jika tidak, jalankan, atau lewati). Untuk tindakan kompensasi, dimungkinkan juga untuk menambahkan kunci idempotensi dan pengulangan operasi (memastikan kegigihan / stabilitas).
Ringkasan
Dari empat persyaratan untuk sistem transaksi ACID (atomisitas, konsistensi, isolasi, stabilitas), mekanisme penurunan memungkinkan tiga untuk dilaksanakan - semua kecuali isolasi. Kurangnya isolasi dapat menyebabkan anomali ("bacaan kotor", "bacaan yang tidak dapat diulang", menulis ulang perubahan antara transaksi bisnis yang berbeda, dll.). Untuk mengatasi situasi seperti itu, diperlukan untuk menggunakan mekanisme tambahan, misalnya, versi objek yang bisa berubah.
Sagas memungkinkan Anda untuk menyelesaikan tugas-tugas berikut:
- Berikan perubahan data dependen untuk data penting bisnis;
- Mampu menetapkan urutan langkah-langkah yang ketat;
- Mematuhi konsistensi 100% (mengoordinasikan data bahkan dalam kasus kecelakaan);
- Berikan pemeriksaan kinerja di semua tingkatan.
Cakupan dan contoh aplikasi
Sagas sering digunakan pada sistem dengan sejumlah besar permintaan. Misalnya, layanan email populer, jejaring sosial. Namun, pendekatan ini dapat menemukan aplikasi dalam proyek-proyek skala kecil.
Perusahaan kami memiliki pengalaman dalam mengembangkan sistem akuntansi untuk perusahaan besar yang dirancang untuk beberapa lusin pengguna dan semua data disimpan dalam satu DBMS relasional. Masalah muncul ketika menerapkan perhitungan otomatis pekerjaan yang direncanakan: dalam beberapa kasus, perhitungannya sangat besar dan membutuhkan penyisipan jutaan catatan dalam tabel DBMS, yang secara signifikan memuat DBMS dan memperlambat operasi seluruh sistem.
Sebuah solusi ditemukan - untuk menempatkan logika perhitungan kerja ke dalam layanan terpisah dengan DBMS sendiri untuk menyimpan karya itu sendiri dan objek terkait. Konsistensi data dipastikan oleh saga. Jika perhitungan gagal, maka modul utama aplikasi menerima perintah untuk membatalkan operasi perhitungan logis.
Pustaka yang mendukung Saga
Aplikasi ini dikembangkan di .Net, dan untuk teknologi ini ada beberapa perpustakaan pengelola layanan dengan dukungan untuk kisah-kisah. Kami melihat perpustakaan NServiceBus, MassTransit, dan Rebus. Sebagai hasilnya, kami memilih Rebus - perpustakaan ini lebih mudah dipelajari, sambil sepenuhnya menyadari prinsip saga dan bebas untuk digunakan. NServiceBus dan MassTransit adalah alat yang lebih canggih dengan banyak fitur tambahan. Mereka tidak diperlukan sebagai bagian dari tugas kami, tetapi mungkin disarankan untuk menggunakannya dalam proyek masa depan dengan logika yang lebih kompleks.