你瞭解Redis事務嗎

2022-08-01 18:06:49

前言

說到事務，大家會立刻想到Mysql的事務，所謂的事務就是對資料進行一系列的操作，要麼都執行成功，要麼都執行失敗，事務提供了原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、永續性(Durability),簡稱ACID。這些屬性既包括了對事務執行結果的要求，也有對資料庫在事務執行前後的資料狀態變化的要求。那麼Redis的事務能支援ACID嗎？

ACID屬性說明

原子性(Atomicity)

事務中的全部操作在資料庫中是不可分割的，要麼全部完成，要麼全部不執行。

一致性(Consistency)

事務的執行使資料從一個狀態轉換為另一個狀態,在事務開始之前和事務結束之後，資料庫的完整性約束沒有被破壞。

隔離性(Isolation)

事務的隔離性要求每個讀寫事務的物件對其他事務的操作物件相互分離，即該事務提交前對其他事務都不可見。

永續性(Durability)

資料庫執行事務後，資料的修改要被持久化儲存下來。當資料庫重啟後，資料的值需要是被修改後的值。

Redis如何實現事務

實現原理

Redis事務的執行包含了三個步驟，具體如下：

使用者端使用MULTI命令顯式地開啟一個事務。
使用者端把事務中本身要執行的具體操作（例如增刪改資料）傳送給伺服器端。這些操作就是Redis 本身提供的資料讀寫命令，雖然這些命令被使用者端傳送到了伺服器端，但是Redis範例只是把這些命令暫存到一個命令佇列中，並不會立即執行。
Redis執行EXEC命令執行事務提交，伺服器端收到EXEC命令後，才會實際執行命令佇列中的所有命令。

事務相關命令

MULTI ：開啟事務
EXEC：提交事務，執行命令佇列中所有的操作命令。
DISCARD:放棄一個事務，清空命令佇列，但是無法支援事務的回滾。
WATCH:檢測一個或多個鍵的值在事務執行的期間是否發生變化，如果發生變化，那麼當前事務放棄執行。

Redis的事務如何支援ACID

Redis事務的支援原子性嗎？

情況一：執行事務在入隊時就報錯，那麼Redis會放棄事務執行，從而保證事務原子性。
情況二：命令在入隊時沒報錯，但是實際執行時卻報錯，無法保證事務原子性。

情況一範例說明

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)

說明：在執行exec命令之前，如果發生語法錯誤(使用了不存在的命令)，那麼命令入隊時,Redis就會報錯並且記錄錯誤，等到執行Exec命令之後，Redi會拒絕所有提交的命令，事務執行失敗。這種情況Reids的事務是可以支援原子性。

情況二範例說明

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"

說明: s2的值為v2，當執行incr命令時報報錯，因為incr只能新增integer的型別值，但是這種情況下我們發現Redis的事務沒有進行回滾，後面的命令能夠執行成功，所以這種情況下時無法保證事務的原子性。

Redis事務的支援一致性嗎？

情況一：命令入隊時就報錯

針對第一種情況，事務本身就會被放棄執行，所以可以保證事務的一致性。

情況二：命令入隊時沒報錯，實際執行時報錯

針對第二種情況，有錯誤的命令不會被執行，正確的命令可以正常執行，也不會改變資料庫的一致性。

情況三：Exec執行命令Redis範例發生故障

如果Redis持久化設定為RDB，那麼生成RDB快照不會在事務執行時執行，所以事務命令操作的結果不會被儲存到RDB快照中，使用RDB快照進行恢復時，資料庫裡的資料也是一致的。
如果Reids持久化設定為AOF，而事務操作還沒有被記錄到AOF紀錄檔時，範例就發生了故障，那麼，使用AOF紀錄檔恢復的資料庫資料是一致的。如果只有部分操作被記錄到了AOF紀錄檔，我們可以使用 redis-check-aof 清除事務中已經完成的操作，資料庫恢復後也是一致的。

Redis事務的支援隔離性嗎？

Redis實現事務的隔離性，需要通過watch命令來支援事務隔離性。Watch的原理是，在事務執行前，監控一個或者多個鍵的變化時，當事務呼叫EXEC命令執行時，WATCH機制會先檢查監控的鍵是否被其它使用者端修改了。如果修改了監聽的值，就放棄事務執行，避免事務的隔離性被破壞。

範例說明

使用者端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)

使用者端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"

說明：使用者端1使用watch檢測balance，在開啟事務後，在使用者端2執行更改balance的值操作，模擬其他使用者端在事務執行期間更改watch監控的資料，然後再執行使用者端1的EXEC命令，發現事務未成功執行。

Redis事務的支援永續性嗎？

Redis的事務無法支援永續性，如果Redis使用了RDB模式，一個事務執行後，當下一次的RDB快照還未執行前，Redis發生了範例宕機，那麼這種情況下，事務修改的資料是無法保證持久化的，如果Redis採用AOF模式，如論持久化設定為no、everysec和always都可能會存在資料丟失，所以，不管 Redis採用那種持久化模式，事務的永續性都無法支援。