本篇文章帶大家詳細了解一下redis中的事務(wù)。有一定的參考價值，有需要的朋友可以參考一下，希望對大家有所幫助。
【相關(guān)推薦：Redis視頻教程】
相關(guān)命令
| 命令 | 格式 | 作用 | 返回結(jié)果 |
|---|---|---|---|
| WATCH | WATCH key [key …] | 將給出的Keys標記為監(jiān)測態(tài)，作為事務(wù)執(zhí)行的條件 | always OK. |
| UNWATCH | UNWATCH | 清除事務(wù)中Keys的 監(jiān)測態(tài)，如果調(diào)用了EXEC or DISCARD，則沒有必要再手動調(diào)用UNWATCH | always OK. |
| MULTI | MULTI | 顯式開啟redis事務(wù)，后續(xù)commands將排隊，等候使用EXEC進行原子執(zhí)行 | always OK. |
| EXEC | EXEC | 執(zhí)行事務(wù)中的commands隊列，恢復(fù)連接狀態(tài)。如果WATCH在之前被調(diào)用，只有監(jiān)測中的Keys沒有被修改，命令才會被執(zhí)行，否則停止執(zhí)行（詳見下文，CAS機制） | 成功： 返回數(shù)組 —— 每個元素對應(yīng)著原子事務(wù)中一個 command的返回結(jié)果; 失敗： 返回NULL（ruby 返回`nil`）; |
| DISCARD | DISCARD | 清除事務(wù)中的commands隊列，恢復(fù)連接狀態(tài)。如果WATCH在之前被調(diào)用，釋放 監(jiān)測中的Keys | always OK. |
注意：——MULTI,EXEC,DISCARD才是顯式開啟并控制事務(wù)的常用命令，可類比關(guān)系型數(shù)據(jù)庫中的 ?BEGAIN,COMMIT,ROLLBACK（事實上，差距很大）；——WATCH命令的使用是為了解決 事務(wù)并發(fā) 產(chǎn)生的不可重復(fù)讀和幻讀的問題（簡單理解為給Key加鎖）；
Redis事務(wù)
MULTI, EXEC, DISCARD and WATCH 是Redis事務(wù)的基礎(chǔ)。用來顯式開啟并控制一個事務(wù)，它們允許在一個步驟中執(zhí)行一組命令。并提供兩個重要的保證：
- 事務(wù)中的所有命令都會被序列化并按順序執(zhí)行。在執(zhí)行Redis事務(wù)的過程中，不會出現(xiàn)由另一個客戶端發(fā)出的請求。這保證 命令隊列 作為一個單獨的原子操作被執(zhí)行。
- 隊列中的命令要么全部被處理，要么全部被忽略。EXEC命令觸發(fā)事務(wù)中所有命令的執(zhí)行，因此，當客戶端在事務(wù)上下文中失去與服務(wù)器的連接，
- 如果發(fā)生在調(diào)用MULTI命令之前，則不執(zhí)行任何commands；
- 如果在此之前EXEC命令被調(diào)用，則所有的commands都被執(zhí)行。
同時，redis使用AOF(Redis視頻教程)，使用一個額外的write操作將事務(wù)寫入磁盤。如果發(fā)生宕機，進程奔潰等情況，可以使用redis-check-aof tool 修復(fù)append-only file，使服務(wù)正常啟動，并恢復(fù)部分操作。
用法
使用MULTI命令顯式開啟Redis事務(wù)。 該命令總是以O(shè)K回應(yīng)。此時用戶可以發(fā)出多個命令，Redis不會執(zhí)行這些命令，而是將它們排隊。EXEC被調(diào)用后，所有的命令都會被執(zhí)行。而調(diào)用DISCARD可以清除事務(wù)中的commands隊列并退出事務(wù)。
- 以下示例以原子方式，遞增鍵foo和bar。
>MULTI OK >INCR?foo QUEUED >INCR?bar QUEUED >EXEC 1）（整數(shù)）1 2）（整數(shù)）1
從上面的命令執(zhí)行中可以看出，EXEC返回一個數(shù)組，其中每個元素都是事務(wù)中單個命令的返回結(jié)果，而且順序與命令的發(fā)出順序相同。 當Redis連接處于MULTI請求的上下文中時，所有命令將以字符串QUEUED（從Redis協(xié)議的角度作為狀態(tài)回復(fù)發(fā)送）作為回復(fù)，并在命令隊列中排隊。只有EXEC被調(diào)用時，排隊的命令才會被執(zhí)行，此時才會有真正的返回結(jié)果。
事務(wù)中的錯誤
事務(wù)期間，可能會遇到兩種命令錯誤：
- 在調(diào)用EXEC命令之前出現(xiàn)錯誤（COMMAND排隊失敗）。
- 例如，命令可能存在語法錯誤（參數(shù)數(shù)量錯誤，錯誤的命令名稱…）；
- 或者可能存在某些關(guān)鍵條件，如內(nèi)存不足的情況（如果服務(wù)器使用maxmemory指令做了內(nèi)存限制）。
客戶端會在EXEC調(diào)用之前檢測第一種錯誤。 通過檢查排隊命令的狀態(tài)回復(fù)（***注意：這里是指排隊的狀態(tài)回復(fù)，而不是執(zhí)行結(jié)果***），如果命令使用QUEUED進行響應(yīng)，則它已正確排隊，否則Redis將返回錯誤。如果排隊命令時發(fā)生錯誤，大多數(shù)客戶端將中止該事務(wù)并清除命令隊列。然而：
- 在Redis 2.6.5之前，這種情況下，在EXEC命令調(diào)用后，客戶端會執(zhí)行命令的子集（成功排隊的命令）而忽略之前的錯誤。
- 從Redis 2.6.5開始，服務(wù)端會記住在累積命令期間發(fā)生的錯誤，當EXEC命令調(diào)用時，將拒絕執(zhí)行事務(wù)，并返回這些錯誤，同時自動清除命令隊列。
- 示例如下：
>MULTI +OK >INCR?a?b?c -ERR?wrong?number?of?arguments?for?'incr'?command
這是由于INCR命令的語法錯誤，將在調(diào)用EXEC之前被檢測出來，并終止事務(wù)（version2.6.5+）。
- 在調(diào)用EXEC命令之后出現(xiàn)錯誤。
- 例如，使用錯誤的值對某個key執(zhí)行操作（如針對String值調(diào)用List操作）
EXEC命令執(zhí)行之后發(fā)生的錯誤并不會被特殊對待：即使事務(wù)中的某些命令執(zhí)行失敗，其他命令仍會被正常執(zhí)行。
- 示例如下：
>MULTI +OK >SET?a?3 +QUEUED >LPOP?a +QUEUED >EXEC *2 +OK -ERR?Operation?against?a?key?holding?the?wrong?kind?of?value
- EXEC返回一個包含兩個元素的字符串數(shù)組，一個元素是OK，另一個是-ERR……。
- 能否將錯誤合理的反饋給用戶這取決于客戶端library(如：spring-data-redis.redisTemplate)的自身實現(xiàn)。
- 需要注意的是，即使命令失敗，隊列中的所有其他命令也會被處理—-Redis不會停止命令的處理。
Redis事務(wù)不支持Rollback（重點）
事實上Redis命令在事務(wù)執(zhí)行時可能會失敗，但仍會繼續(xù)執(zhí)行剩余命令而不是Rollback（事務(wù)回滾）。如果你使用過關(guān)系數(shù)據(jù)庫，這種情況可能會讓你感到很奇怪。然而針對這種情況具備很好的解釋：
- Redis命令可能會執(zhí)行失敗，僅僅是由于錯誤的語法被調(diào)用（命令排隊時檢測不出來的錯誤），或者使用錯誤的數(shù)據(jù)類型操作某個Key： 這意味著，實際上失敗的命令都是編程錯誤造成的，都是開發(fā)中能夠被檢測出來的，生產(chǎn)環(huán)境中不應(yīng)該存在。（這番話，徹底甩鍋，“都是你們自己編程錯誤，與我們無關(guān)”。）
- 由于不必支持Rollback,Redis內(nèi)部簡潔并且更加高效。
“如果錯誤就是發(fā)生了呢？”這是一個反對Redis觀點的爭論。然而應(yīng)該指出的是，通常情況下，回滾并不能挽救編程錯誤。鑒于沒有人能夠挽救程序員的錯誤，并且Redis命令失敗所需的錯誤類型不太可能進入生產(chǎn)環(huán)境，所以我們選擇了不支持錯誤回滾（Rollback）這種更簡單快捷的方法。
清除命令隊列
DISCARD被用來中止事務(wù)。事務(wù)中的所有命令將不會被執(zhí)行,連接將恢復(fù)正常狀態(tài)。
>?SET?foo?1 OK >?MULTI OK >?INCR?foo QUEUED >?DISCARD OK >?GET?foo "1"
更多編程相關(guān)知識，請訪問：Redis視頻教程！！
