redis事務有什么用

這篇文章主要介紹了redis事務有什么用，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

是什么

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

能干嘛

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

怎么玩

一個redis事務的開啟使用了MULTI命令，這個命令總是會回復OK,（不知道能不能成功），此時用戶可以一次性執行多個命令而不是一個一個的執行。redis將它們入隊，所有命令將會被EXEC命令調用
DISCARD放棄批處理操作。

推薦（免費）：redis教程

常用命令

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事務有什么用”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!