Semua operasi dalam urus niaga tidak boleh dibahagikan dalam pangkalan data, sama ada semua telah selesai atau tidak ada yang dilaksanakan.
Pelaksanaan transaksi menukar data dari satu keadaan ke keadaan lain Sebelum urus niaga bermula dan selepas urus niaga tamat, kekangan integriti pangkalan data tidak dilanggar.
Pengasingan transaksi memerlukan objek setiap transaksi baca-tulis diasingkan daripada objek operasi urus niaga lain, iaitu transaksi tidak kelihatan kepada transaksi lain sebelum ini. ia komited.
Selepas pangkalan data melaksanakan transaksi, pengubahsuaian data mesti diteruskan. Apabila pangkalan data dimulakan semula, nilai data perlu menjadi nilai yang diubah suai.
Pelaksanaan transaksi Redis merangkumi tiga langkah, seperti berikut:
Pelanggan end menggunakan arahan MULTI untuk memulakan transaksi secara eksplisit.
Pelayan menerima operasi khusus yang dihantar oleh pelanggan (seperti menambah, memadam dan mengubah suai data) dan melaksanakannya dalam transaksi. Operasi ini ialah perintah baca dan tulis data yang disediakan oleh Redis sendiri Walaupun arahan ini dihantar ke pelayan oleh klien, contoh Redis hanya menyimpan sementara arahan ini dalam baris gilir arahan dan tidak melaksanakannya dengan serta-merta.
Hanya apabila arahan EXEC diterima dan dilaksanakan, Redis akan melakukan transaksi dan benar-benar melaksanakan semua arahan dalam baris gilir transaksi.
MULTI: buka transaksi
EXEC: lakukan transaksi dan laksanakan arahan Semua arahan operasi dalam baris gilir.
BUANG: Batalkan transaksi dan kosongkan baris gilir arahan, tetapi tidak boleh menyokong pemulangan transaksi.
TONTON: Kesan sama ada nilai satu atau lebih kunci berubah semasa pelaksanaan transaksi Jika ia berubah, maka transaksi semasa meninggalkan pelaksanaan.
Situasi 1: Ralat dilaporkan semasa melaksanakan transaksi apabila ia ditambahkan pada baris gilir, kemudian Redis akan menyerahkan pelaksanaan transaksi untuk memastikan atomicity transaksi.
Senario 2: Arahan tidak melaporkan ralat apabila ia berada dalam baris gilir, tetapi ralat dilaporkan apabila ia benar-benar dilaksanakan Keatoman transaksi tidak boleh dijamin.
Contoh perihalan kes satu
127.0.0.1:6379> multi OK 127.0.0.1:6379> set t1 v1 QUEUED 127.0.0.1:6379> set t2 v2 QUEUED 127.0.0.1:6379> setget t3 (error) ERR unknown command 'setget' 127.0.0.1:6379> set t4 v4 QUEUED 127.0.0.1:6379> exec (error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379> get t4 (nil)
Penjelasan: Sebelum melaksanakan perintah exec, jika ralat sintaks berlaku (arahan tidak wujud digunakan), maka apabila arahan beratur, Redis akan melaporkan ralat dan merekodkan ralat Selepas arahan Exec dilaksanakan, Redi akan menolak semua arahan yang diserahkan dan pelaksanaan transaksi akan gagal. Dalam kes ini, transaksi Reid boleh menyokong atomicity.
Contoh perihalan kes 2
127.0.0.1:6379> multi OK 127.0.0.1:6379> incr s2 QUEUED 127.0.0.1:6379> set a1 v1 QUEUED 127.0.0.1:6379> set a2 v2 QUEUED 127.0.0.1:6379> exec 1) (error) ERR value is not an integer or out of range 2) OK 3) OK 127.0.0.1:6379> get a2 "v2"
Penjelasan: Nilai s2 ialah v2 Apabila melaksanakan perintah incr, ralat dilaporkan kerana incr hanya boleh menambah nilai jenis integer, tetapi dalam kes ini. kami mendapati Transaksi Redis tidak ditarik balik, dan arahan seterusnya boleh dilaksanakan dengan jayanya, jadi keatomisan transaksi tidak dapat dijamin dalam kes ini.
Dalam kes pertama, urus niaga itu sendiri akan ditinggalkan, jadi konsistensi transaksi boleh dijamin.
Dalam kes kedua, arahan yang salah tidak akan dilaksanakan, tetapi arahan yang betul boleh dilaksanakan secara normal, dan Akan mengubah ketekalan pangkalan data.
Jika kegigihan Redis ditetapkan kepada RDB, petikan RDB yang dijana tidak akan dilaksanakan apabila transaksi dilaksanakan, jadi transaksi Hasil operasi arahan tidak akan disimpan ke petikan RDB Apabila menggunakan petikan RDB untuk pemulihan, data dalam pangkalan data akan konsisten.
Jika kegigihan Reids ditetapkan kepada AOF dan kejadian gagal sebelum operasi transaksi direkodkan dalam log AOF, maka data pangkalan data yang dipulihkan menggunakan log AOF adalah konsisten . Jika hanya beberapa operasi direkodkan dalam log AOF, kami boleh menggunakan redis-check-aof untuk mengosongkan operasi yang telah selesai dalam transaksi, dan pangkalan data akan konsisten selepas pemulihan.
Untuk mencapai pengasingan transaksi Redis, anda perlu menggunakan arahan jam tangan. Prinsip Watch ialah apabila memantau perubahan dalam satu atau lebih kunci sebelum transaksi dilaksanakan, apabila transaksi memanggil arahan EXEC untuk melaksanakan, mekanisme WATCH akan terlebih dahulu menyemak sama ada kunci yang dipantau telah diubah suai oleh pelanggan lain. Jika nilai pendengar diubah suai, pelaksanaan transaksi ditinggalkan untuk mengelakkan pengasingan transaksi daripada dimusnahkan.
Contoh penerangan
Klien 1:
127.0.0.1:6379> get blance "100" 127.0.0.1:6379> watch blance OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> decrby blance 10 QUEUED 127.0.0.1:6379> incrby blance 10 QUEUED 127.0.0.1:6379> exec (nil)
Klien 2:
127.0.0.1:6379> get blance "100" 127.0.0.1:6379> set blance 90 OK 127.0.0.1:6379> get blance "90"
Penjelasan: Pelanggan 1 menggunakan jam tangan untuk mengesan baki, selepas membuka transaksi, lakukan operasi menukar nilai baki pada pelanggan 2, simulasi pelanggan lain menukar data yang dipantau oleh jam tangan semasa pelaksanaan transaksi, dan kemudian laksanakan perintah EXEC pelanggan 1, dan mendapati transaksi itu tidak berjaya dilaksanakan.
Transaksi Redis tidak boleh menyokong kegigihan Jika Redis menggunakan mod RDB, selepas transaksi dilaksanakan, tetapi sebelum petikan RDB seterusnya dilaksanakan, kejadian Redis ranap tahan lama. Jika Redis menggunakan mod AOF, kehilangan data mungkin berlaku tanpa mengira sama ada konfigurasi kegigihan adalah tidak, setiap saat atau sentiasa.
Atas ialah kandungan terperinci Bagaimana untuk melaksanakan transaksi Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!