Redis事務定義

Redis 事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷。

Redis 事務的主要作用就是串聯多個命令防止別的命令插隊。

Multi、Exec、discard

Redis 事務中有 Multi、Exec 和 discard 三個指令，在 Redis 中，從輸入 Multi 命令開始，輸入的命令都會依次進入命令隊列中，但不會執行，直到輸入 Exec 後，Redis 會將之前的命令隊列中的命令依次執行。而組隊的過程中可以通過 discard 來放棄組隊

案列說明

組隊成功：我們輸入multi進行組隊，將set k1 v1和set k2 v2兩條命令插入到隊列中，然後輸入exec執行命令，最後執行成功。

組隊階段報錯：我們輸入multi進行組隊，將set k1 v1和set k2兩條命令插入到隊列中，由於set k2這條命令報錯了，所以在組隊階段就已經失敗了，所以執行exec也就全部失敗了，註意：set k1 v1這條命令不會被執行

組隊成功，提交有成功有失敗情況：我們輸入multi進行組隊，將set k1 v1和incr k1以及set k2 v2三條命令插入到隊列中，這三條命令本身語法是沒有問題的，但是在輸入exec執行後，第二條命令報錯了，其他命令成功執行，報錯原因是鍵k1的值是一個字元串類型，不是整型，所以不能增量。

事務的錯誤處理

組隊階段中某個命令出現了報告錯誤，執行時整個的所有隊列都會被取消。

執行階段某個命令報出了錯誤，則只有報錯的命令不會被執行，而其他的命令都會執行，不會回滾。

事務衝突的問題

• 一個請求想給金額減 8000；

• 一個請求想給金額減 5000；

• 一個請求想給金額減 1000。

最終我們可以發現，總共金額是 10000，如果請求全部執行，那最後的金額變為 - 4000，很明顯不合理。

方案一：悲觀鎖

悲觀鎖 (Pessimistic Lock)，顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會 block 直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

方案二：樂觀鎖

樂觀鎖 (Optimistic Lock)，顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量。Redis 就是利用這種 check-and-set 機制實現事務的。

WATCH key [key …]

在執行 multi 之前，先執行 watch key1 [key2]，可以監視一個 (或多個) key ，如果在事務執行之前這個 (或這些) key 被其他命令所改動，那麼事務將被打斷。

案例

我們先設置一個金額100，使用watch對balance進行監控，然後開啟事務增加20金額

再啟動另一個視窗，也使用watch對balance進行監控，然後開啟事務減少金額500

這時候我們有2個事務，我們先執行第1個事務，增加金額的事務，可以看到事務執行成功

我們再執行第2個事務，減少金額，由於之前監控了balance，又因為balance被事務1做了改動，所以事務2不會執行成功

 

unwatch

取消 WATCH 命令對所有 key 的監視。如果在執行 WATCH 命令之後，EXEC 命令或 DISCARD 命令先被執行了的話，那麼就不需要再執行 UNWATCH 了。
 

Redis 事務三特性

• 單獨的隔離操作 ：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷。

• 沒有隔離級別的概念 ：隊列中的命令沒有提交之前都不會實際被執行，因為事務提交前任何指令都不會被實際執行。

• 不保證原子性 ：事務中如果有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾 。