redis學習之：介紹redis事務

是什麼

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

能幹嘛

一個佇列中，一次、順序性、排他性的執行一系列指令。

怎麼玩

一個redis交易的開啟使用了MULTI指令，這個指令總是會回覆OK,（不知道能不能成功），此時使用者可以一次執行多個指令而不是一個一個的執行。 redis將它們入隊，所有指令將會被EXEC指令呼叫
DISCARD放棄批次操作。

推薦（免費）：redis教學

#常用指令

指令	說明
DISCARD	取消事務，放棄執行交易區塊內的所有指令。
EXEC	執行所有交易區塊內的指令。
MULTI	標記一個交易區塊的開始。
UNWATCH	取消 WATCH 指令對所有 key 的監視。
WATCH key [key …]	監視一個(或多個) key ，如果在交易執行之前這個(或這些) key 被其他指令所改動，那麼事務將被打斷。

Case

正常執行

放棄交易

全體連坐

一個錯誤，全體連坐，都不執行

冤頭債主

對於這個問題，redis對事務的支持如何理解
redis對事務是部分支持，這一部分時，對的執行，錯的不執行

case:watch監視器

悲觀鎖定/樂觀鎖定/CAS(Check and set)

悲觀鎖定(Pessimistic Lock) , 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，例如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
表格鎖定：整張表加鎖。但是這張表可能很多條很多條數據，這個時候一個行程要進行大範圍的改動，會導致排隊的執行緒越來越多。
行鎖：對每一筆記錄加鎖
樂觀鎖
樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用於多讀取的應用類型，這樣可以提高吞吐量。
樂觀鎖策略:提交版本必須大於記錄當前版本才能執行更新
樂觀鎖也並不是盲目的樂觀，比如張三改微信號，李四該qq號，同時進行，開始的時候版本號碼都是1，然後張三改完了微訊號就去提交，此時版本號碼從1到2，李四改完了也去提交，此時從1卻變成3，就會報異常，重新修改。
工作中一般用樂觀鎖定

初始化信用卡可用餘額和欠額

無加塞竄改，先監控再開啟multi， 保證兩筆金額變動在同一個事務內

# 在監聽的時候，發現另外一個事務修改了共享數據，導致事務執行失敗

在修改資料之前，需要先加鎖watch，否則會導致出錯。如果有人修改了我的數據，我就會報異常。

有加塞竄改

監控了key，如果key被修改了，後面一個交易的執行失效

##unwatch

取消watch指令對所有key的監視

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

小結

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

透過WATCH指令在交易執行之前監控了多個Keys，倘若在WATCH之後有任何Key的值發生了變化， EXEC指令執行的事務都將被放棄，同時傳回Nullmulti-bulk應答以通知呼叫者交易執行失敗

3階段

• 開啟：以MULTI開始一個事務

• 入隊：將多個命令入隊到事務中，接到這些命令並不會立即執行，而是放到等待執行的事務佇列裡面
• 執行：由EXEC指令觸發交易

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

沒有隔離層級的概念：佇列中的指令沒有提交之前都不會實際的被執行，因為事務提交前任何指令都不會被實際執行， 也就不存在」事務內的查詢要看到事務裡的更新，在事務外查詢不能看到」這個讓人萬分頭痛的問題

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

以上是redis學習之：介紹redis事務的詳細內容。更多資訊請關注PHP中文網其他相關文章！