|
WATCH |
WATCH key [key ...] |
將給予的Keys標記為監控狀態，作為事務執行的條件 |
always OK. |
| UNWATCH |
##UNWATCH
| 清除交易中Keys的監測態，如果呼叫了EXEC or DISCARD，則沒有必要再手動呼叫UNWATCH
| always OK. |
| MULTI
|
MULTI
|
明確開啟redis事務，後續commands將排隊，等候使用EXEC進行原子執行
| always OK. |
| EXEC
|
EXEC
| 執行交易中的commands佇列，恢復連線狀態。如果WATCH在先前被調用，只有監控中的Keys沒有被修改，指令才會被執行，否則停止執行（詳見下文，CAS機制）
|
成功： 傳回陣列－ 每個元素對應原子事務中一個command的回傳結果;
失敗： 回傳NULL（Ruby 回傳`nil`）;
|
##DISCARD | DISCARD
清除交易中的 | commands佇列，恢復連線狀態。如果WATCH在先前被調用，釋放 監控中的Keys |
|
注意：
------MULTI,EXEC,DISCARD才是明確開啟並控制交易的常用指令，可類比關係型資料庫中的 BEGAIN,COMMIT,ROLLBACK（事實上，差距很大）；
------WATCH指令的使用是為了解決交易並發 產生的不可重複讀取和幻讀的問題（簡單理解為給Key加上鎖定）；
- # #Redis交易
-
MULTI, EXEC, DISCARD and WATCH 是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
指令的語法錯誤，將在呼叫- 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"
更多编程相关知识，请访问：编程视频！！
