redis防坑指南－事務

相關指令介紹：

（學習影片分享：redis影片教學）

注意：

------MULTI,EXEC,DISCARD才是明確開啟並控制交易的常用指令，可類比關聯式資料庫中的 BEGAIN,COMMIT,ROLLBACK（事實上，差距很大）；

------WATCH指令的使用是為了解決交易並發產生的不可重複讀和幻讀的問題（簡單理解為給Key加鎖）；

#Redis交易

MULTI, EXEC, DISCARD and WATCH 是Redis事務的基礎。用來明確開啟並控制一個事務，它們允許在一個步驟中執行一組命令。並提供兩個重要的保證：

事務中的所有命令都會被序列化並按順序執行。在執行Redis事務的過程中，不會出現由另一個客戶端發出的請求。這保證命令佇列 作為一個單獨的原子操作被執行。

佇列中的指令要麼全部被處理，要麼全部被忽略。 EXEC命令觸發事務中所有命令的執行，因此，當客戶端在事務上下文中失去與伺服器的連接，如果發生在調用MULTI命令之前，則不執行任何commands；如果在此之前EXEC命令被調用，則所有的commands都被執行。

同時，redis使用AOF(append-only file)，使用額外的write操作將交易寫入磁碟。如果發生宕機，進程奔潰等情況，可以使用redis-check-aof tool 修復append-only file，使服務正常啟動，並恢復部分操作。

用法

使用MULTI指令明確開啟Redis交易。該命令總是以OK回應。此時使用者可以發出多個命令，Redis不會執行這些命令，而是將它們排隊。 EXEC被呼叫後，所有的指令都會被執行。而呼叫DISCARD可以清除事務中的commands佇列並退出事務。

以下範例以原子方式，遞增鍵foo和bar。

>MULTI
OK
>INCR foo
QUEUED
>INCR bar
QUEUED
>EXEC
1）（整数）1
2）（整数）1

從上面的命令執行中可以看出，EXEC傳回一個數組，其中每個元素都是事務中單一命令的回傳結果，而且順序與命令的發出順序相同。 當Redis連線處於MULTI請求的上下文中時，所有命令將以字串QUEUED（從Redis協定的角度作為狀態回復發送）作為回复，並在命令佇列中排隊。只有EXEC被呼叫時，排隊的命令才會被執行，此時才會有真正的回傳結果。

交易中的錯誤

交易期間，可能會遇到兩種指令錯誤：

在呼叫EXEC指令之前出現錯誤（COMMAND排隊失敗）。例如，命令可能存在語法錯誤（參數數量錯誤，錯誤的命令名稱...）；或者可能存在某些關鍵條件，例如記憶體不足的情況（如果伺服器使用maxmemory指令做了記憶體限制）。

客戶端會在EXEC呼叫之前偵測第一種錯誤。透過檢查排隊命令的狀態回复（***注意：這裡是指排隊的狀態回复，而不是執行結果***），如果命令使用QUEUED進行響應，則它已正確排隊，否則Redis將返回錯誤。如果排隊命令時發生錯誤，大多數用戶端將中止該交易並清除命令佇列。然而：

在Redis 2.6.5之前，這種情況下，在EXEC指令呼叫後，客戶端會執行指令的子集（成功排隊的指令）而忽略先前的錯誤。從Redis 2.6.5開始，服務端會記住在累積命令期間發生的錯誤，當EXEC命令呼叫時，將拒絕執行事務，並傳回這些錯誤，同時自動清除命令佇列。範例如下：

>MULTI
+OK
>INCR a b c
-ERR wrong number of arguments for 'incr' command

這是由於INCR指令的語法錯誤，將在呼叫EXEC之前被偵測出來，並終止交易（version2.6.5 ）。

在呼叫EXEC指令之後出現錯誤。例如，使用錯誤的值對某個key執行操作（如針對String值呼叫List操作）

EXEC指令執行之後發生的錯誤並不會被特殊對待：即使事務中的某些指令執行失敗，其他命令仍會被正常執行。

範例如下：

>MULTI
+OK
>SET a 3
+QUEUED
>LPOP a
+QUEUED
>EXEC
*2
+OK
-ERR Operation against a key holding the wrong kind of value

EXEC傳回一個包含兩個元素的字串陣列，一個元素是OK，另一個是-ERR…。能否將錯誤合理的回饋給使用者這取決於客戶端library(如：Spring-data-redis.redisTemplate)的自身實作。要注意的是，即使指令失敗，佇列中的所有其他指令也會被處理----Redis不會停止指令的處理。

Redis事務不支援Rollback（重點）

事實上Redis指令在交易執行時可能會失敗，但仍會繼續執行剩餘指令而不是Rollback（交易回滾）。如果你使用過關聯式資料庫，這種情況可能會讓你感到很奇怪。然而針對這種情況具備很好的解釋：

Redis命令可能会执行失败，仅仅是由于错误的语法被调用（命令排队时检测不出来的错误），或者使用错误的数据类型操作某个Key： 这意味着，实际上失败的命令都是编程错误造成的，都是开发中能够被检测出来的，生产环境中不应该存在。（这番话，彻底甩锅，“都是你们自己编程错误，与我们无关”。）由于不必支持Rollback,Redis内部简洁并且更加高效。

“如果错误就是发生了呢？”这是一个反对Redis观点的争论。然而应该指出的是，通常情况下，回滚并不能挽救编程错误。鉴于没有人能够挽救程序员的错误，并且Redis命令失败所需的错误类型不太可能进入生产环境，所以我们选择了不支持错误回滚（Rollback）这种更简单快捷的方法。

清除命令队列

DISCARD被用来中止事务。事务中的所有命令将不会被执行,连接将恢复正常状态。

> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"

相关推荐：redis数据库教程

以上是redis防坑指南－事務的詳細內容。更多資訊請關注PHP中文網其他相關文章！