詳談：Redis事務和消息訂閱

1、Redis事務

一、概念

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

事務能作的事: 一個隊列中，一次性、順序性、排他性的執行一系列命令d

經常使用命令:

• DISCARD: 取消事務，放棄執行事務塊內的全部命令；
• EXEC : 執行全部事務塊內的命令；
• MULTI : 標記一個事務塊的開始；
• WATCH key([key ....]) : 監視一個（或多個） key，若是在事務執行以前這個(或這些)key被其餘命令所改動，那麼事務將被打斷；
• UNWATCH : 取消WATCH命令對全部key的監控；

二、正常執行和放棄事務

• 正常執行；
• 放棄事務；

三、全體連坐和冤頭債主

下面的演示說明: Redis是部分支持事務的。不保證原子性。

• 全體連坐 (錯誤的命令，至關於編譯錯誤，而後致使全部命令都掛了)；
• 冤頭債主(不支持的參數，或者類型問題，至關於運行時錯誤，不會致使全部命令都掛，只掛有問題的)；

四、WATCH監控(重要)

首先介紹了樂觀鎖和悲觀鎖:

• 悲觀鎖(Pessimistic Lock): 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，因此每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型數據庫裏邊就用到了不少這種鎖機制，好比行鎖，表鎖等，讀鎖，寫鎖等，都是在作操做以前先上鎖。
• 樂觀鎖(Optimistic Lock) : 顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可使用版本號(version)等機制。樂觀鎖適用於多讀的應用類型，這樣能夠提升吞吐量。 樂觀鎖策略:提交版本必須大於記錄當前版本才能執行更新。

WATCH監控案例: （餘額和消費），例如餘額爲100，消費爲0，餘額爲80，消費爲20.....

①先看一波正常執行的:

②第二波，有另外一個客戶端修改了咱們WATCH的key。

③第三波，使用UNWATCH。

總結:

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

五、事務的階段和特性

三個階段:

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

三個特性:

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

2、Redis消息訂閱發佈

概念:

• 進程間的一種消息通訊模式：發送者(pub)發送消息，訂閱者(sub)接收消息；

左邊窗口開始訂閱c一、c二、c3三個頻道。右邊尚未操做。

而後右邊開始發佈消息。

總結:

先訂閱後發佈後才能收到消息，

• 能夠一次性訂閱多個，SUBSCRIBE c1 c2 c3。
• 消息發佈，PUBLISH c2 hello-redis。
• 訂閱多個，通配符*，PSUBSCRIBE new*。
• 收取消息， PUBLISH new1 redis2015。