1、redis的事務是什麽

可以一次執行多個命令，本質是一組命令的集合，一個事務中的所有命令都會被序列化，按順序地串行化執行而不會被其它命令插入，不許加塞（排隊時後來者插到先到者前面的行為。）

也就是說，在隊列中，一次性、順序性、排他性的執行一系列命令的行為。

看看官方的介紹：

註： redis 的事務是能夠使用 MULTI 命令的行為，這個命令通常會響應為 OK，在這種情況下，使用者可以進行多個命令的操作，redis會安排它們入隊列而不是執行這些命令，這些所有命令在鍵入 EXEC 時才會被調用。

如果調用 DISCARD 命令將會刷新事務隊列，而後退出事務。

2、具體的實際操作

a、 MULTI: 標記一個事務塊的開始

EXEC: 執行所有事務塊內的命令

DISCARD: 取消事務，放棄執行事務塊內的所有命令

註：圖示為正常執行的情況

註：圖示為放棄事務執行的情況

註: 圖示中，鍵入 getset v2 時發生了錯誤，所以在最後執行時所有命令都沒有執行。（類似於Java 的編譯期錯誤。）

註：k1 為字符串，不可以進行數字操作，但是在執行了 EXEC 後才發現，後續的操作一樣執行。（類似於 java 的運行期錯誤。）

b、WATCH: 監視一個（或者多個）key,如果在事務之前這個（或者這些）key被其他的命令所改動，那麽事務將會被打斷

UNWATCH: 取消 WATCH 命令對所有 key 的監視。

註： 先設置 balance、debt 兩個變量，然後再執行watch balance 和 multi 命令，在執行multi

命令之後，使用另一個終端開啟另外一個客戶端並改動 balance 的值後發現，exec 指令命令並不成功。（即redis事務不允許加塞。）

註： 可以看到，unwatch 可以取消對所有 key 的監控，再 watch 一下，獲取最新的 key 的狀態。

3、redis事務機制的三特性：

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

b、沒有隔離級別的概念：隊列中的命令沒有提交之前都不會實際的被執行，因為事務提交之前任何指令都不會被實際執行，也就不存在“事務內的查詢要看到事務裏的更新，事務外的查詢不能夠看到”的問題。

c、不保證原子性: redis同一個事務中如果有一條命令執行失敗，其後的命令仍然會被執行。沒有回滾操作。

附：樂觀鎖和悲觀鎖的理解

悲觀鎖： （Pessimistic Lock）,顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會被阻塞，直到它拿到鎖。傳統的關系型數據庫裏邊就用到了很多這種鎖機制，比如行鎖、表鎖、讀鎖、寫鎖等。都是在操作之前上鎖。

樂觀鎖： （Optimistic Lock），顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制，樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量。（提交版本必須大於記錄當前版本才能夠執行更新。）

本文出自 “12392717” 博客，請務必保留此出處http://12402717.blog.51cto.com/12392717/1925108

Redis的事務機制