什么是Redis事務

Redis 事務的本質(zhì)是一組命令的集合。事務支持一次執(zhí)行多個命令，一個事務中所有命令都會被序列化。在事務執(zhí)行過程，會按照順序串行化執(zhí)行隊列中的命令，其他客戶端提交的命令請求不會插入到事務執(zhí)行命令序列中。

總結說：redis事務就是一次性、順序性、排他性的執(zhí)行一個隊列中的一系列命令。

Redis事務相關命令和使用

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事務相關的命令。

• MULTI ：開啟事務，redis會將后續(xù)的命令逐個放入隊列中，然后使用EXEC命令來原子化執(zhí)行這個命令系列。
• EXEC：執(zhí)行事務中的所有操作命令。
• DISCARD：取消事務，放棄執(zhí)行事務塊中的所有命令。
• WATCH：監(jiān)視一個或多個key,如果事務在執(zhí)行前，這個key(或多個key)被其他命令修改，則事務被中斷，不會執(zhí)行事務中的任何命令。
• UNWATCH：取消WATCH對所有key的監(jiān)視。

標準的事務執(zhí)行

給k1、k2分別賦值，在事務中修改k1、k2，執(zhí)行事務后，查看k1、k2值都被修改。

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 11
QUEUED
127.0.0.1:6379> set k2 22
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
127.0.0.1:6379> get k1
"11"
127.0.0.1:6379> get k2
"22"
127.0.0.1:6379>

事務取消

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 33
QUEUED
127.0.0.1:6379> set k2 34
QUEUED
127.0.0.1:6379> DISCARD
OK

事務出現(xiàn)錯誤的處理

• 語法錯誤（編譯器錯誤）

在開啟事務后，修改k1值為11，k2值為22，但k2語法錯誤，最終導致事務提交失敗，k1、k2保留原值。

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 11
QUEUED
127.0.0.1:6379> sets k2 22
(error) ERR unknown command `sets`, with args beginning with: `k2`, `22`, 
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379>

• Redis類型錯誤（運行時錯誤）

在開啟事務后，修改k1值為11，k2值為22，但將k2的類型作為List，在運行時檢測類型錯誤，最終導致事務提交失敗，此時事務并沒有回滾，而是跳過錯誤命令繼續(xù)執(zhí)行， 結果k1值改變、k2保留原值

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k1 v2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 11
QUEUED
127.0.0.1:6379> lpush k2 22
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> get k1
"11"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379>

CAS操作實現(xiàn)樂觀鎖

WATCH 命令可以為 Redis 事務提供 check-and-set （CAS）行為。

被 WATCH 的鍵會被監(jiān)視，并會發(fā)覺這些鍵是否被改動過了。 如果有至少一個被監(jiān)視的鍵在 EXEC 執(zhí)行之前被修改了， 那么整個事務都會被取消， EXEC 返回nil-reply來表示事務已經(jīng)失敗。

舉個例子， 假設我們需要原子性地為某個值進行增 1 操作（假設 INCR 不存在）。

val = GET mykey
val = val + 1
SET mykey $val

上面的這個實現(xiàn)在只有一個客戶端的時候可以執(zhí)行得很好。 但是， 當多個客戶端同時對同一個鍵進行這樣的操作時， 就會產(chǎn)生競爭條件。舉個例子， 如果客戶端 A 和 B 都讀取了鍵原來的值， 比如 10 ， 那么兩個客戶端都會將鍵的值設為 11 ， 但正確的結果應該是 12 才對。

有了 WATCH ，我們就可以輕松地解決這類問題了：

WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

使用上面的代碼， 如果在 WATCH 執(zhí)行之后， EXEC 執(zhí)行之前， 有其他客戶端修改了 mykey 的值， 那么當前客戶端的事務就會失敗。 程序需要做的， 就是不斷重試這個操作， 直到?jīng)]有發(fā)生碰撞為止。

這種形式的鎖被稱作樂觀鎖， 它是一種非常強大的鎖機制。 并且因為大多數(shù)情況下， 不同的客戶端會訪問不同的鍵， 碰撞的情況一般都很少， 所以通常并不需要進行重試。

---

• watch是如何監(jiān)視實現(xiàn)的呢？

Redis使用WATCH命令來決定事務是繼續(xù)執(zhí)行還是回滾，那就需要在MULTI之前使用WATCH來監(jiān)控某些鍵值對，然后使用MULTI命令來開啟事務，執(zhí)行對數(shù)據(jù)結構操作的各種命令，此時這些命令入隊列。

當使用EXEC執(zhí)行事務時，首先會比對WATCH所監(jiān)控的鍵值對，如果沒發(fā)生改變，它會執(zhí)行事務隊列中的命令，提交事務；如果發(fā)生變化，將不會執(zhí)行事務中的任何命令，同時事務回滾。當然無論是否回滾，Redis都會取消執(zhí)行事務前的WATCH命令。

• watch 命令實現(xiàn)監(jiān)視

在事務開始前用WATCH監(jiān)控k1，之后修改k1為11，說明事務開始前k1值被改變，MULTI開始事務，修改k1值為12，k2為22，執(zhí)行EXEC，發(fā)回nil，說明事務回滾；查看下k1、k2的值都沒有被事務中的命令所改變。

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> WATCH k1
OK
127.0.0.1:6379> set k1 11
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 12
QUEUED
127.0.0.1:6379> set k2 22
QUEUED
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> get k1
"11"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379>

---

Redis事務執(zhí)行步驟

通過上文命令執(zhí)行，很顯然Redis事務執(zhí)行是三個階段：

• 開啟：以MULTI開始一個事務

• 入隊：將多個命令入隊到事務中，接到這些命令并不會立即執(zhí)行，而是放到等待執(zhí)行的事務隊列里面

• 執(zhí)行：由EXEC命令觸發(fā)事務

當一個客戶端切換到事務狀態(tài)之后， 服務器會根據(jù)這個客戶端發(fā)來的不同命令執(zhí)行不同的操作：

• 如果客戶端發(fā)送的命令為 EXEC 、 DISCARD 、 WATCH 、 MULTI 四個命令的其中一個， 那么服務器立即執(zhí)行這個命令。
• 與此相反， 如果客戶端發(fā)送的命令是 EXEC 、 DISCARD 、 WATCH 、 MULTI 四個命令以外的其他命令， 那么服務器并不立即執(zhí)行這個命令， 而是將這個命令放入一個事務隊列里面， 然后向客戶端返回 QUEUED 回復。

更深入的理解

我們再通過幾個問題來深入理解Redis事務。

為什么 Redis 不支持回滾？

如果你有使用關系式數(shù)據(jù)庫的經(jīng)驗， 那么 “Redis 在事務失敗時不進行回滾，而是繼續(xù)執(zhí)行余下的命令”這種做法可能會讓你覺得有點奇怪。

以下是這種做法的優(yōu)點：

• Redis 命令只會因為錯誤的語法而失敗（并且這些問題不能在入隊時發(fā)現(xiàn)），或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應該在開發(fā)的過程中被發(fā)現(xiàn)，而不應該出現(xiàn)在生產(chǎn)環(huán)境中。
• 因為不需要對回滾進行支持，所以 Redis 的內(nèi)部可以保持簡單且快速。

有種觀點認為 Redis 處理事務的做法會產(chǎn)生 bug ， 然而需要注意的是， 在通常情況下， 回滾并不能解決編程錯誤帶來的問題。 舉個例子， 如果你本來想通過 INCR 命令將鍵的值加上 1 ， 卻不小心加上了 2 ， 又或者對錯誤類型的鍵執(zhí)行了 INCR ， 回滾是沒有辦法處理這些情況的。

如何理解Redis與事務的ACID？

一般來說，事務有四個性質(zhì)稱為ACID，分別是原子性，一致性，隔離性和持久性。這是基礎，但是很多文章對Redis 是否支持ACID有一些異議，我覺的有必要梳理下：

• 原子性atomicity

首先通過上文知道 運行期的錯誤是不會回滾的，很多文章由此說Redis事務違背原子性的；而官方文檔認為是遵從原子性的。

Redis官方文檔給的理解是，Redis的事務是原子性的：所有的命令，要么全部執(zhí)行，要么全部不執(zhí)行。而不是完全成功。

• 一致性consistency

redis事務可以保證命令失敗的情況下得以回滾，數(shù)據(jù)能恢復到?jīng)]有執(zhí)行之前的樣子，是保證一致性的，除非redis進程意外終結。

• 一致性consistency

redis事務可以保證命令失敗的情況下得以回滾，數(shù)據(jù)能恢復到?jīng)]有執(zhí)行之前的樣子，是保證一致性的，除非redis進程意外終結。但是，Redis不像其它結構化數(shù)據(jù)庫有隔離級別這種設計。

• 持久性Durability

redis事務是不保證持久性的，這是因為redis持久化策略中不管是RDB還是AOF都是異步執(zhí)行的，不保證持久性是出于對性能的考慮。

?

?

?

?

?

?