Redis的事務（Redis部分支持事務）

　　a）是什麽

　　可以一次執行多個命令，本質是一組命令的集合。一個事務中的所有命令都會序列化，按順序地串行化執行而不會被其它命令插入，不許加塞

　　b）能幹嗎

　　一個（隊列）中，一次性、順序性、排他性的執行一系列命令　

　　c）怎麽用

　　MULTI　　開始事務

　　EXEC　　執行事務

　　DISCARD　　取消事務

　　WATCH　　監聽一個（或多個）key，如果在事務執行之前 key 被其他命令所改動，那麽事務將被打斷

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

　　CASE1：正常執行

　　　　MULTI　　

　　　　命令1；命令2；命令3

　　　　EXEC

　　CASE2：放棄事務　　DISCARD　　

　　CASE3：全體連坐

　　　　當事務出現：如 命令出現語法錯誤時，命令不能正常添加到Queue中，此時事務中的所有命令都不會執行

　　CASE4：冤頭債主

　　　　當事務出現：如 不是一些編譯型的錯誤，是要在執行之後才能發現的錯誤，（如對string類型的數據進行incr）

　　那麽只有這條出錯語句不會執行，事務中的其他語句不受影響，正常執行

　　CASE5：watch監控（樂觀鎖的一種（檢測監控））

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

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

　　　　樂觀鎖策略:提交版本必須大於記錄當前版本才能執行更新

　　1）watch一個 key 或 多個 key，即事務開啟之前，watch的 key被修改，後面開啟事務對該key進行操作是會失敗的

事務開啟之後，watch的key被修改，這個已經開啟的事務後面的命令是可以正常執行的

　　關鍵看 multi 命令 是在修改前還是修改後執行的

　　2）一旦執行了exec之前加的監控鎖都會被取消掉了

　　3）Watch指令，類似樂觀鎖，事務提交時，如果Key的值已被別的客戶端改變，比如某個list已被別的客戶端push/pop過了，整個事務隊列都不會被執行

　　4）通過WATCH命令在事務執行之前監控了多個Keys，倘若在WATCH之後有任何Key的值發生了變化，EXEC命令執行的事務都將被放棄，同時返回Nullmulti-bulk應答以通知調用者事務執行失敗

　　d）事務執行的三階段　

　　　　1.開啟：以MULTI開始一個事務

　　　　2.入隊：將多個命令入隊到事務中，接到這些命令並不會立即執行，而是放到等待執行的事務隊列裏面

　　　　3.執行：由EXEC命令觸發事務　

　　e）事務執行三特性

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

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

也就不存在”事務內的查詢要看到事務裏的更新，在事務外查詢不能看到”這個讓人萬分頭痛的問題

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

6.Redis的事務