Redis事務定義
Redis 事務是一個單獨的隔離操作:事務中的所有命令都會序列化、按順序地執行,事務在執行的程序中,不會被其他客戶端發送來的命令請求所打斷,
Redis 事務的主要作用就是串聯多個命令防止別的命令插隊,
Multi、Exec、discard
Redis 事務中有 Multi、Exec 和 discard 三個指令,在 Redis 中,從輸入 Multi 命令開始,輸入的命令都會依次進入命令佇列中,但不會執行,直到輸入 Exec 后,Redis 會將之前的命令佇列中的命令依次執行,而組隊的程序中可以通過 discard 來放棄組隊

案列說明
組隊成功:我們輸入multi進行組隊,將set k1 v1和set k2 v2兩條命令插入到佇列中,然后輸入exec執行命令,最后執行成功,
組隊階段報錯:我們輸入multi進行組隊,將set k1 v1和set k2兩條命令插入到佇列中,由于set k2這條命令報錯了,所以在組隊階段就已經失敗了,所以執行exec也就全部失敗了,注意:set k1 v1這條命令不會被執行
組隊成功,提交有成功有失敗情況:我們輸入multi進行組隊,將set k1 v1和incr k1以及set k2 v2三條命令插入到佇列中,這三條命令本身語法是沒有問題的,但是在輸入exec執行后,第二條命令報錯了,其他命令成功執行,報錯原因是鍵k1的值是一個字串型別,不是整型,所以不能增量,
事務的錯誤處理
組隊階段中某個命令出現了報告錯誤,執行時整個的所有佇列都會被取消,
執行階段某個命令報出了錯誤,則只有報錯的命令不會被執行,而其他的命令都會執行,不會回滾,
事務沖突的問題
-
一個請求想給金額減 8000;
-
一個請求想給金額減 5000;
-
一個請求想給金額減 1000,
最終我們可以發現,總共金額是 10000,如果請求全部執行,那最后的金額變為 - 4000,很明顯不合理,
方案一:悲觀鎖
悲觀鎖 (Pessimistic Lock),顧名思義,就是很悲觀,每次去拿資料的時候都認為別人會修改,所以每次在拿資料的時候都會上鎖,這樣別人想拿這個資料就會 block 直到它拿到鎖,傳統的關系型資料庫里邊就用到了很多這種鎖機制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖,
方案二:樂觀鎖
樂觀鎖 (Optimistic Lock),顧名思義,就是很樂觀,每次去拿資料的時候都認為別人不會修改,所以不會上鎖,但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料,可以使用版本號等機制,樂觀鎖適用于多讀的應用型別,這樣可以提高吞吐量,Redis 就是利用這種 check-and-set 機制實作事務的,
WATCH key [key …]
在執行 multi 之前,先執行 watch key1 [key2],可以監視一個 (或多個) key ,如果在事務執行之前這個 (或這些) key 被其他命令所改動,那么事務將被打斷,
案例
我們先設定一個金額100,使用watch對balance進行監控,然后開啟事務增加20金額

再啟動另一個視窗,也使用watch對balance進行監控,然后開啟事務減少金額500

這時候我們有2個事務,我們先執行第1個事務,增加金額的事務,可以看到事務執行成功

我們再執行第2個事務,減少金額,由于之前監控了balance,又因為balance被事務1做了改動,所以事務2不會執行成功

unwatch
取消 WATCH 命令對所有 key 的監視,如果在執行 WATCH 命令之后,EXEC 命令或 DISCARD 命令先被執行了的話,那么就不需要再執行 UNWATCH 了,
Redis 事務三特性
-
單獨的隔離操作 :事務中的所有命令都會序列化、按順序地執行,事務在執行的程序中,不會被其他客戶端發送來的命令請求所打斷,
-
沒有隔離級別的概念 :佇列中的命令沒有提交之前都不會實際被執行,因為事務提交前任何指令都不會被實際執行,
-
不保證原子性 :事務中如果有一條命令執行失敗,其后的命令仍然會被執行,沒有回滾 ,
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/545157.html
標籤:NoSQL
上一篇:IDEA連接MySQL
下一篇:redis(10)事務和鎖機制
