Transaksi dalam Redis Cluster adalah cerita yang berbeda dari transaksi dengan Redis Standalone.
TL;DR;
Itu lebih merupakan masalah konseptual mengenai jaminan dan pertukaran daripada masalah klien.
Penjelasan
Di Redis Cluster, node tertentu adalah master untuk satu atau lebih hash-slot, itulah skema partisi untuk memisahkan data di antara beberapa node. Satu hash-slot, dihitung dari kunci yang digunakan dalam perintah, tinggal di satu node. Perintah dengan banyak kunci dibatasi untuk menghasilkan slot hash yang sama. Jika tidak, mereka ditolak. Rasi bintang seperti itu disebut slot silang.
Transaksi tampaknya menjadi solusi untuk mengeksekusi perintah ke kunci slot silang tetapi pada titik tertentu, seseorang akan meninggalkan ruang lingkup satu node dan akan membutuhkan node lain untuk melanjutkan transaksi. Ini bisa terjadi jika satu kunci hidup di satu simpul dan kunci lainnya tinggal di simpul lain. Masih belum ada koordinasi transaksi dan hal itu terkadang dapat menjadi masalah bagi Redis Cluster.
API tingkat tinggi yang menyediakan dukungan transaksional untuk Redis Cluster menghadapi banyak masalah dan sejauh ini ada dua strategi, cara menangani transaksi di Redis Cluster:
Mendukung transaksi jika semua kunci terletak pada satu node
Opsi ini memungkinkan transaksi berfitur lengkap. Pustaka klien diperlukan untuk melacak node transaksi dijalankan dan melarang kunci di luar rentang slot selama transaksi berlangsung. Karena slot hanya dapat ditentukan dengan menggunakan perintah yang berisi kunci, klien perlu menetapkan tanda transaksional dan pada perintah pertama yang berisi kunci, perintah MULTI harus dikeluarkan, tepat sebelum perintah pertama dalam transaksi. Batasan di sini jelas merupakan persyaratan untuk memiliki semua kunci yang terletak di satu node.
Transaksi terdistribusi
Dalam hal ini, beberapa transaksi dimulai pada semua node yang bergabung dengan transaksi terdistribusi. Transaksi terdistribusi ini dapat menyertakan kunci dari semua node master. Setelah transaksi dijalankan, library klien memicu eksekusi transaksi, library mengumpulkan semua hasil (untuk mempertahankan urutan hasil perintah) dan mengembalikannya ke pemanggil.
Gaya transaksi ini transparan bagi klien. Segera setelah kunci pada simpul tertentu diminta dan simpul tersebut belum menjadi bagian dari transaksi, aMULTI perintah dikeluarkan untuk bergabung dengan node ke transaksi. Kekurangannya disini adalah transaksi tidak bisa bersyarat lagi (WATCH ). Transaksi individu tidak memiliki pengetahuan apakah kunci diubah pada node yang berbeda, sehingga satu transaksi dapat dibatalkan sementara transaksi lainnya akan berhasil. Kedengarannya seperti komitmen dua fase.
Kesimpulan
Transaksi Redis terasa seperti kumpulan perintah atom yang dapat dibuat bersyarat. Penting untuk diingat bahwa eksekusi perintah ditunda karena hasil baca kembali pada saat eksekusi transaksi dan bukan pada saat perintah dikeluarkan.
Untuk Redis Cluster, klien belum memutuskan strategi global. Aman untuk menjalankan transaksi pada node Redis Cluster tertentu tetapi Anda terbatas pada kunci yang dilayani oleh node tersebut. Kedua strategi yang mungkin memiliki properti yang mungkin berguna untuk kasus penggunaan tertentu tetapi juga memiliki keterbatasan.
