Redis之事務

一.是什麼

能夠一次執行多個命令，本質是一組命令的集合。一個事務中的全部命令都會序列化，按順序地串行化執行而不會被其它命令插入，不準加塞
二.能幹嗎

一個隊列中，一次性、順序性、排他性的執行一系列命令
三.怎麼玩

經常使用命令

 

1：正常執行

 

2：放棄事務

 

3：全體連坐

 

 

Case4：冤頭債主

 

Case5：watch監控

(1)悲觀鎖/樂觀鎖/CAS(Check And Set)
(2)Watch指令，相似樂觀鎖，事務提交時，若是Key的值已被別的客戶端改變，好比某個list已被別的客戶端push/pop過了，整個事務隊列都不會被執行
(3)經過WATCH命令在事務執行以前監控了多個Keys，假若在WATCH以後有任何Key的值發生了變化，EXEC命令執行的事務都將被放棄，同時返回Nullmulti-bulk應答以通知調用者事務執行失敗

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

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

3階段:

1.開啓：以MULTI開始一個事務
2.入隊：將多個命令入隊到事務中，接到這些命令並不會當即執行，而是放到等待執行的事務隊列裏面
3.執行：由EXEC命令觸發事務

3特性:

1.單獨的隔離操做：事務中的全部命令都會序列化、按順序地執行。事務在執行的過程當中，不會被其餘客戶端發送來的命令請求所打斷。 2.沒有隔離級別的概念：隊列中的命令沒有提交以前都不會實際的被執行，由於事務提交前任何指令都不會被實際執行，也就不存在」事務內的查詢要看到事務裏的更新，在事務外查詢不能看到」這個讓人萬分頭痛的問題 3.不保證原子性：redis同一個事務中若是有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾