共計 2892 個字符，預計需要花費 8 分鐘才能閱讀完成。
自動寫代碼機器人，免費開通
這篇文章主要介紹 Redis 中事務是什么，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
相關命令命令格式作用返回結果 WATCHWATCH key [key …] 將給出的 Keys 標記為監測態，作為事務執行的條件 always OK.UNWATCHUNWATCH 清除事務中 Keys 的 監測態，如果調用了 EXEC or DISCARD，則沒有必要再手動調用 UNWATCHalways OK.MULTIMULTI 顯式開啟 redis 事務，后續 commands 將排隊，等候使用 EXEC 進行原子執行 always OK.EXECEXEC 執行事務中的 commands 隊列，恢復連接狀態。如果 WATCH 在之前被調用，只有監測中的 Keys 沒有被修改，命令才會被執行，否則停止執行（詳見下文，CAS 機制）成功：返回數組 —— 每個元素對應著原子事務中一個 command 的返回結果;
失敗：返回 NULL（Ruby 返回 `nil`）;DISCARDDISCARD 清除事務中的 commands 隊列，恢復連接狀態。如果 WATCH 在之前被調用，釋放 監測中的 Keysalways OK.
注意：
——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
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
INCR a b c
-ERR wrong number of arguments for incr command這是由于 INCR 命令的語法錯誤，將在調用 EXEC 之前被檢測出來，并終止事務（version2.6.5+）。
在調用 EXEC 命令之后出現錯誤。
例如，使用錯誤的值對某個 key 執行操作（如針對 String 值調用 List 操作）
EXEC 命令執行之后發生的錯誤并不會被特殊對待：即使事務中的某些命令執行失敗，其他命令仍會被正常執行。
示例如下：
MULTI
SET a 3
+QUEUED
LPOP a
+QUEUED
EXEC
-ERR Operation against a key holding the wrong kind of valueEXEC 返回一個包含兩個元素的字符串數組，一個元素是 OK，另一個是 -ERR……。
能否將錯誤合理的反饋給用戶這取決于客戶端 library(如：Spring-data-redis.redisTemplate) 的自身實現。
需要注意的是，即使命令失敗，隊列中的所有其他命令也會被處理 —-Redis 不會停止命令的處理。
Redis 事務不支持 Rollback（重點）
事實上 Redis 命令在事務執行時可能會失敗，但仍會繼續執行剩余命令而不是 Rollback（事務回滾）。如果你使用過關系數據庫，這種情況可能會讓你感到很奇怪。然而針對這種情況具備很好的解釋：
Redis 命令可能會執行失敗，僅僅是由于錯誤的語法被調用（命令排隊時檢測不出來的錯誤），或者使用錯誤的數據類型操作某個 Key：這意味著，實際上失敗的命令都是編程錯誤造成的，都是開發中能夠被檢測出來的，生產環境中不應該存在。（這番話，徹底甩鍋，“都是你們自己編程錯誤，與我們無關”。）
由于不必支持 Rollback,Redis 內部簡潔并且更加高效。
“如果錯誤就是發生了呢？”這是一個反對 Redis 觀點的爭論。然而應該指出的是，通常情況下，回滾并不能挽救編程錯誤。鑒于沒有人能夠挽救程序員的錯誤，并且 Redis 命令失敗所需的錯誤類型不太可能進入生產環境，所以我們選擇了不支持錯誤回滾（Rollback）這種更簡單快捷的方法。
清除命令隊列
DISCARD 被用來中止事務。事務中的所有命令將不會被執行, 連接將恢復正常狀態。
SET foo 1
MULTI
INCR foo
QUEUED
DISCARD
GET foo
1以上是“Redis 中事務是什么”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！
向 AI 問一下細節
