詳細了解Redis中的事務

這篇文章帶大家詳細了解Redis中的事務。有一定的參考價值，有需要的朋友可以參考一下，希望對大家有幫助。

【相關推薦：Redis影片教學】

相關指令

清除交易中always OK.always OK.執行交易中的##DISCARD DISCARDcommands

注意：

------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"

更多编程相关知识，请访问：编程视频！！

命令	格式	作用	返回結果
WATCH	WATCH key [key ...]	將給予的Keys標記為監控狀態，作為事務執行的條件	always OK.
UNWATCH	##UNWATCH	Keys的監測態，如果呼叫了EXEC or DISCARD，則沒有必要再手動呼叫UNWATCH
MULTI	MULTI	明確開啟redis事務，後續commands將排隊，等候使用EXEC進行原子執行
EXEC	EXEC	commands佇列，恢復連線狀態。如果WATCH在先前被調用，只有監控中的Keys沒有被修改，指令才會被執行，否則停止執行（詳見下文，CAS機制）	成功： 傳回陣列－ 每個元素對應原子事務中一個command的回傳結果; 失敗： 回傳NULL（Ruby 回傳`nil`）;
	清除交易中的	佇列，恢復連線狀態。如果WATCH在先前被調用，釋放 監控中的Keysalways OK.

以上是詳細了解Redis中的事務的詳細內容。更多資訊請關注PHP中文網其他相關文章！