# 事務（transaction） ### 原理 先將屬于一個事務的命令發送給redis進行緩存，最后再讓redis依次執行這些命令。 ### 命令 DISCARD 取消事務，放棄執行事務塊內的所有命令。 EXEC 執行所有事務塊內的命令。 MULTI 標記一個事務塊的開始。 UNWATCH 取消 WATCH 命令對所有 key 的監視。 WATCH key [key ...] 監視一個(或多個) key ，如果在事務執行之前這個(或這些) key 被其他命令所改動，那么事務將被打斷。 #### 使用事務時可能會遇上以下兩種錯誤 1.事務在執行EXEC 之前，入隊的命令可能會出錯。比如說，命令可能會產生語法錯誤（參數數量錯誤，參數名錯誤，等等），或者其他更嚴重的錯誤，比如內存不足 （如果服務器使用 maxmemory 設置了最大內存限制的話）。 2.命令可能在EXEC 調用之后失敗。舉個例子，事務中的命令可能處理了錯誤類型的鍵，比如將列表命令用在了字符串鍵上面，諸如此類。 ##### 第一種錯誤的情況 服務器端 在 Redis 2.6.5 以前，Redis 只執行事務中那些入隊成功的命令，而忽略那些入隊失敗的命令。 不過，從 Redis 2.6.5 開始，服務器會對命令入隊失敗的情況進行記錄，并在客戶端調用EXEC 命令時，拒絕執行并自動放棄這個事務。 客戶端 客戶端以前的做法是檢查命令入隊所得的返回值：如果命令入隊時返回 QUEUED ，那么入隊成功；否則，就是入隊失敗。如果有命令在入隊時失敗， 那么大部分客戶端都會停止并取消這個事務。 ##### 第二種錯誤的情況 至于那些在EXEC 命令執行之后所產生的錯誤，并沒有對它們進行特別處理：即使事務中有某個/某些命令在執行時產生了錯誤，事務中的其他命令仍然會繼續執行。 這種做法可能會讓你覺得有點奇怪，以下是這種做法的優點: 1.Redis 命令只會因為錯誤的語法而失敗（并且這些問題不能在入隊時發現），或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來說， 失敗的命令是由編程錯誤造成的，而這些錯誤應該在開發的過程中被發現，而不應該出現在生產環境中。 2.因為不需要對回滾進行支持，所以 Redis 的內部可以保持簡單且快速。 鑒于沒有任何機制能避免程序員自己造成的錯誤，并且這類錯誤通常不會在生產環境中出現，所以 Redis 選擇了更簡單、更快速的無回滾方式來處理事務。 3.DISCARD 命令時，事務會被放棄，事務隊列會被清空，并且客戶端會從事務狀態中退出。 4.WATCH 命令可以為 Redis 事務提供 check-and-set （CAS）行為 被WATCH 的鍵會被監視，并會發覺這些鍵是否被改動過了。如果有至少一個被監視的鍵在EXEC 執行之前被修改了，那么整個事務都會被取消。 如果在WATCH 執行之后，EXEC 執行之前，有其他客戶端修改了 mykey 的值，那么當前客戶端的事務就會失敗。程序需要做的，就是不斷重試這個操作，直到沒有發生碰撞為止。 這種形式的鎖被稱作樂觀鎖，它是一種非常強大的鎖機制。并且因為大多數情況下，不同的客戶端會訪問不同的鍵，碰撞的情況一般都很少，所以通常并不需要進行重試。