誰說Redis不支持事務？

1、概述：

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

Redis部分支持事務，不支持的是：強一致性

能幹嗎： 一個隊列中，一次性、順序性、排他性的執行一系列命令

經常使用命令：

• MULTI：開啓一個事務，MULTI 執行以後，客戶端能夠繼續向服務器發送任意多條命令，這些命令不會當即被執行，而是被放到一個隊列中。
• EXEC：執行隊列中全部的命令
• DISCARD：清空事務隊列,並放棄執行事務
• UNWATCH：取消 WATCH 命令對全部 key 的監視
• WATCH key1 key2 ... ：監視一個(或多個) key ，若是在事務執行以前這個(或這些) key 被其餘命令所改動，那麼事務將被打斷。

2、使用：

正常執行：

放棄事務：

全體連坐：

一個指令語法錯誤，注意：我說的是語法錯誤！，EXEC執行報錯。

冤頭債主（部分支持事務）：

冤有頭，債有主，對的放行，誰錯找誰。這也就說明：Redis部分支持事務，對的放行，錯的報錯。

WATCH監控：先監控，後開啓事務

緩存的數據，誰均可以拿，能夠改，因此必須打標記來監控行爲。這裏涉及到鎖的問題：悲觀鎖/樂觀鎖/CAS(Check And Set)

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

案例演示：信用卡和欠額

正常狀況：無加塞篡改

有加塞篡改的狀況：

在 WATCH 監控後，有人修改了balance，會致使事務會被打斷，必須更新最新值，才能成功執行事務，相似於樂觀鎖的版本號機制。

事務三階段：

一、開啓：以MULTI開始一個事務

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

三、執行：由EXEC命令觸發事務

事務三特性：

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

二、沒有隔離級別的概念：隊列中的命令沒有提交以前都不會實際的被執行，由於事務提交前任何指令都不會被實際執行，也就不存在」事務內的查詢要看到事務裏的更新，在事務外查詢不能看到」這個讓人萬分頭痛的問題

三、（重點）不保證原子性：redis同一個事務中若是有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾，這也就是：Redis部分支持事務。

小結：

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