Satu artikel akan membantu anda memahami secara menyeluruh hal ehwal Redis

Artikel ini membawakan anda pengetahuan yang berkaitan tentang Redis, yang terutamanya memperkenalkan kandungan yang berkaitan tentang urus niaga. Ini pada asasnya ialah koleksi perintah yang menyokong pelaksanaan berbilang perintah pada satu masa proses pelaksanaan, arahan dalam baris gilir akan dilaksanakan secara berurutan; mari kita lihat, saya harap ia akan membantu semua orang.

Pembelajaran yang disyorkan: Tutorial video Redis

Pengenalan kepada transaksi Redis

Redis is just Menyediakan fungsi transaksi yang mudah. Intipatinya ialah satu set perintah Sesuatu transaksi menyokong pelaksanaan berbilang arahan pada satu masa Semasa pelaksanaan transaksi, arahan dalam baris gilir akan dilaksanakan secara berurutan urutan perintah transaksi ini. Proses pelaksanaan perintah dilaksanakan secara berurutan, tetapi atomicity tidak dijamin. Ia tidak boleh mempunyai tahap pengasingan seperti MySQL, dan ia boleh melancarkan semula data dan operasi lanjutan lain selepas masalah berlaku. Ini akan dianalisis secara terperinci kemudian.

Arahan transaksi asas Redis

Redis menyediakan arahan asas berikut yang berkaitan dengan transaksi.

MULTIBuka urus niaga, Redis akan menambah perintah berikutnya pada baris gilir tanpa benar-benar melaksanakannya sehingga penggunaan berikutnya EXEC untuk melaksanakan perintah ini secara atom dan berurutan EXEC melaksanakan semua blok transaksi Perintah DISCARD membatalkan urus niaga dan berhenti melaksanakan semua arahan dalam blok transaksi WATCH memantau satu atau lebih kunci Jika kunci ini diubah suai oleh perintah lain sebelum urus niaga dilaksanakan, urus niaga akan ditamatkan dan transaksi tidak akan dilaksanakan. . Sebarang arahan UNWATCH membatalkan pemantauan semua kunci dengan arahan WATCH

Secara amnya, transaksi Redis yang mudah dibahagikan kepada bahagian berikut:

Laksanakan arahan MULTI untuk membuka urus niaga. Selepas urus niaga dimulakan, berbilang arahan untuk melaksanakan perintah akan dimasukkan ke dalam baris gilir mengikut urutan Jika peletakan berjaya, mesej QUEUED akan dikembalikan. Jalankan perintah EXEC untuk menyerahkan transaksi Redis akan melaksanakan perintah dalam baris gilir dalam urutan dan mengembalikan hasil semua perintah dalam urutan. (Jika anda ingin berhenti melakukan transaksi, laksanakan DISCARD).

Rajah berikut memperkenalkan secara ringkas proses pelaksanaan transaksi Redis:

Contoh Analisis

Mari kita lihat beberapa contoh praktikal di bawah alami transaksi di Redis. Kami juga menyebut sebelum ini bahawa transaksi Redis bukanlah transaksi sebenar dan tidak dapat memenuhi sepenuhnya ciri ACID transaksi standard. Melalui contoh berikut, mari kita lihat apakah masalah dengan transaksi "versi bankrap" Redis.

[A] Laksanakan penyerahan seperti biasa

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
127.0.0.1:6379> SET b 2
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
127.0.0.1:6379> GET a
"1"
127.0.0.1:6379> GET b
"2"

Selepas memulakan urus niaga, arahan yang diserahkan akan ditambahkan pada baris gilir (BERGITAL) Selepas melaksanakan EXEC, arahan akan dilaksanakan langkah dengan langkah dan hasilnya akan dikembalikan. Adakah ini kelihatan serupa dengan operasi transaksi yang biasa kami gunakan dalam MySQL, seperti mulakan transaksi dan komit?

[B] Batalkan urus niaga seperti biasa

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
127.0.0.1:6379> SET b 2
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> 
127.0.0.1:6379> GET a
(nil)
127.0.0.1:6379> GET b
(nil)

Selepas membuka urus niaga, jika anda tidak mahu meneruskan transaksi, gunakan BUANG untuk membatalkan Arahan yang diserahkan sebelum ini sebenarnya tidak dilaksanakan, dan nilai kunci yang berkaitan akan kekal tidak berubah. Ini juga kelihatan serupa dengan transaksi MySQL, sama seperti memulakan transaksi dan rollback.

[C]WATCH monitoring key

-- 线程 1 中执行
127.0.0.1:6379> del a
(integer) 1
127.0.0.1:6379> get a
(nil)
127.0.0.1:6379> SET a 0
OK
127.0.0.1:6379> WATCH a
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
----------------------------------------- 线程 2 中执行
----------------------------------------- 127.0.0.1:6379> SET a 2
----------------------------------------- OK
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> GET a
"2"

TONTON nilai a sebelum memulakan transaksi, dan kemudian mulakan transaksi. Nilai a ditetapkan dalam urutan lain (SET a 2), dan kemudian EXEC dilaksanakan untuk melaksanakan transaksi Hasilnya adalah sifar,
menunjukkan bahawa transaksi tidak dilaksanakan. Oleh kerana nilai a berubah selepas WATCH, transaksi telah dibatalkan.

Perlu diambil perhatian bahawa ini tidak ada kaitan dengan masa transaksi dimulakan, dan tidak ada kaitan dengan susunan di mana MULTI dan benang lain menetapkan nilai a. Asalkan berubah selepas TENGOK. Tidak kira sama ada transaksi telah dimulakan, ia akan dibatalkan apabila melaksanakan transaksi (EXEC).
Dalam keadaan biasa, apabila melaksanakan perintah EXEC dan DISCARD, UNWATCH akan dilaksanakan secara lalai.

[D] Ralat sintaks

127.0.0.1:6379> SET a 1
OK
127.0.0.1:6379> SET b 2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 11
QUEUED
127.0.0.1:6379> SETS b 22
(error) ERR unknown command 'SETS'
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> GET a
"1"
127.0.0.1:6379> GET b
"2"

Apabila Redis memulakan transaksi, jika terdapat ralat sintaks dalam arahan tambahan, penyerahan transaksi akan gagal. Dalam kes ini, tiada satu pun arahan dalam baris gilir transaksi akan dilaksanakan. Seperti dalam contoh di atas, nilai a dan b adalah kedua-dua nilai asal.
Ralat jenis ini yang berlaku sebelum EXEC, seperti ralat nama perintah, ralat parameter perintah, dsb., akan dikesan sebelum EXEC dilaksanakan Oleh itu, apabila ralat ini berlaku, transaksi akan dibatalkan dan semua arahan dalam transaksi akan dibatalkan tidak akan dilaksanakan. (Adakah keadaan ini kelihatan seperti putar balik)

[E] Ralat masa jalan

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
127.0.0.1:6379> SET b hello
QUEUED
127.0.0.1:6379> INCR b
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
127.0.0.1:6379> GET a
"1"
127.0.0.1:6379> GET b
"hello"

当 Redis 开启一个事务后，添加的命令没有出现前面说的语法错误，但是在运行时检测到了类型错误，导致事务最提交失败（说未完全成功可能更准确点）。此时事务并不会回滚，而是跳过错误命令继续执行。
如上面的例子，未报错的命令值已经修改，a 被设置成了 1，b 被设置为了 hello，但是报错的值未被修改，即 INCR b 类型错误，并未执行，b 的值也没有被再更新。

Redis 事务与 ACID

通过上面的例子，我们已经知道 Redis 的事务和我们通常接触的 MySQL 等关系数据库的事务还有有一定差异的。它不保证原子性。同时 Redis 事务也没有事务隔离级别的概念。下面我们来具体看下 Redis 在 ACID 四个特性中，那些是满足的，那些是不满足的。
事务执行可以分为命令入队（EXEC 执行前）和命令实际执行（EXEC 执行之后）两个阶段。下面我们在分析的时候，很多时候都会分这两种情况来分析。

原子性（A）

上面的实例分析中，[A]，[B]，[C]三种正常的情况，我们可以很明显的看出，是保证了原子性的。
但是一些异常情况下，是不满足原子性的。

如 [D] 所示的情况，客户端发送的命令有语法错误，在命令入队列时 Redis 就判断出来了。等到执行 EXEC 命令时，Redis 就会拒绝执行所有提交的命令，返回事务失败的结果。此种情况下，事务中的所有命令都不会被执行了，是保证了原子性的。 如 [E] 所示的情况，事务操作入队时，命令和操作类型不匹配，此时 Redis 没有检查出错误（这类错误是运行时错误）。等到执行 EXEC 命令后，Redis 实际执行这些命令操作时，就会报错。需要注意的是，虽然 Redis 会对错误的命令报错不执行，但是其余正确的命令会依次执行完。此种情况下，是无法保证原子性的。 在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。此时，如果开启了 AOF 日志，那么只会有部分事务操作被记录到 AOF 日志中。使用redis-check-aof工具检测 AOF 日志文件，可以把未完成的事务操作从 AOF 文件中去除。这样一来，使用 AOF 文件恢复实例后，事务操作不会被再执行，从而保证了原子性。若使用的 RDB 模式，最新的 RDB 快照是在 EXEC 执行之前生成的，使用快照恢复之后，事务中的命令也都没有执行，从而保证了原子性。若 Redis 没有开启持久化，则重启后内存中的数据全部丢失，也就谈不上原子性了。 一致性（C）

一致性指的是事务执行前后，数据符合数据库的定义和要求。这点在 Redis 事务中是满足的，不论是发生语法错误还是运行时错误，错误的命令均不会被执行。

EXEC 执行之前，入队报错（实例分析中的语法错误）

事务会放弃执行，故可以保证一致性。

EXEC 执行之后，实际执行时报错（实例分析中的运行时错误）

错误的命令不会被执行，正确的命令被执行，一致性可以保证。

EXEC 执行时，实例宕机

若 Redis 没有开启持久化，实例宕机重启后，数据都没有了，数据是一致的。
若配置了 RDB 方式，RDB 快照不会在事务执行时执行。所以，若事务执行到一半，实例发生了故障，此时上一次 RDB 快照中不会包含事务所做的修改，而下一次 RDB 快照还没有执行，实例重启后，事务修改的数据会丢失，数据是一致的。若事务已经完成，但新一次的 RDB 快照还没有生成，那事务修改的数据也会丢失，数据也是一致的。
若配置了 AOF 方式。当事务操作还没被记录到 AOF 日志时，实例就发生故障了，使用 AOF 日志恢复后数据是一致的。若事务中的只有部分操作被记录到 AOF 日志，可以使用 redis-check-aof清除事务中已经完成的操作，数据库恢复后数据也是一致的。

隔离性（I） 并发操作在 EXEC 执行前，隔离性需要通过 WATCH 机制来保证 并发操作在 EXEC 命令之后，隔离性可以保证

情况 a 可以参考前面的实例分析 WATCH 命令的使用。
情况 b，由于 Redis 是单线程执行命令，EXEC 命令执行后，Redis 会保证先把事务队列中的所有命令执行完之后再执行之后的命令。

持久性（D）

Jika Redis tidak mendayakan kegigihan, maka semua data akan disimpan dalam memori Setelah dimulakan semula, data akan hilang, jadi ketahanan transaksi pada masa ini tidak dapat dijamin.
Jika Redis telah menghidupkan kegigihan, data mungkin masih hilang apabila kejadian ranap dan dimulakan semula, jadi ketahanan tidak dapat dijamin sepenuhnya.
Oleh itu, kita boleh mengatakan bahawa transaksi Redis tidak semestinya menjamin ketahanan, dan hanya boleh menjamin ketahanan dalam keadaan khusus.

Berkenaan mengapa Redis masih kehilangan data selepas menghidupkan kegigihan, penulis akan menyusun artikel berasingan yang berkaitan dengan kegigihan dan tuan-hamba Redis untuk memperkenalkannya.
Jika mod RDB dikonfigurasikan, selepas transaksi dilaksanakan tetapi sebelum petikan RDB seterusnya dilaksanakan, tika Redis ranap dan data akan hilang
Jika mod AOF dikonfigurasikan dan tiga parameter daripada mod AOF Pilihan konfigurasi tidak, setiap saat, dan sentiasa juga boleh menyebabkan kehilangan data.

Ringkasnya, urus niaga Redis menyokong ACID:

Ia mempunyai tahap keatoman tertentu, tetapi tidak menyokong pemulangan semula Ia memenuhi ketekalan dan pengasingan serta tidak dapat menjamin ketahanan gulung balik? prestasi Redis persekitaran pengeluaran.

Untuk ralat logik, contohnya, apabila menambah 1, hasilnya ditulis sebagai menambah 2. Keadaan ini tidak boleh diselesaikan dengan berpatah balik.

Redis mengejar kesederhanaan dan kecekapan, tetapi pelaksanaan transaksi tradisional agak rumit, yang bertentangan dengan idea reka bentuk Redis. Apabila kita menikmati kelajuan Redis, kita tidak boleh meminta lebih daripadanya.

Pembelajaran yang disyorkan:
Tutorial video Redis

Atas ialah kandungan terperinci Satu artikel akan membantu anda memahami secara menyeluruh hal ehwal Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!