1. 程式人生 > >Redis——樂觀鎖控制事務

Redis——樂觀鎖控制事務

      redis對事務的支援比較簡單。redis只能保證一個客戶端發起的事務命令可以執行,中間不會插入其他事務。因為redis是單執行緒的,所以做到上面這點很容易。一般redis接受到客戶端的命令後會立即執行,但是如果客戶端發起multi命令,redis不會立即執行,而是讓當前連線進入事務上下文,把命令放到佇列中,接受到exec命令後,redis會順序執行佇列中的命令。並把執行結果打包到一起返回客戶端,之後就結束了事務上下文。

一、簡單的事務控制

  

   這個例子可以看到:兩個set命令發出後並沒有立即執行而是放到佇列中,redis接受到exec命令才開始執行。

   如果有兩個執行緒同時修改了一個變數的值,如何控制事務回滾?下面看樂觀鎖怎麼控制的?

二、樂觀鎖控制事務

   1.什麼是樂觀鎖?

       大多是基於資料版本的記錄機制。什麼是資料版本?就是為資料增加一個版本標識,即為資料庫表新增一個version欄位,當讀取資料時,把資料庫版本一同讀出,當做了修改後,將資料庫版本+1,同修改一起提交。如果提交資料的版本號 >資料庫當前版本號,提交成功。如圖:

   

  2.樂觀鎖例項

     假設資料庫中賬戶資訊表中有一個version欄位,當前值為1,賬戶餘額為$500

    

     這樣避免了操作員B用舊資料修改表中記錄的的可能。

  3.在redis中怎麼體現的?

         redis中用watch監視key,如果key在提交前被修改,則提交不成功。如下:

        

         當session1還沒來得及對age進行修改,session2已經將age的值設為30,session1再執行的時候失敗,因為session1對age加了樂觀鎖的緣故。

        watch命令會監視key,當exec時如果監視的key從呼叫watch後發生過變化,則整個事務會失敗。也可以呼叫watch多次監視多個key。

三、redis事務存在的問題

        redis保證事務中的命令連續執行,但是如果其中一條命令執行失敗,事務並不回滾。

       

       

    為age +1的命令成功,因為anme是string型別的,所以不能做加操作,命令有一個失敗也不會回滾,age的值已經被修改了。

相關推薦

Redis樂觀控制事務

redis對事務的支援比較簡單。redis只能保證一個客戶端發起的事務命令可以執行,中間不會插入其他事務。但redis叢集不支援事務。因為redis是單執行緒的,所以做到上面這點很容易。一般redis接受到客戶端的命令後會立即執行,但是如果客戶端發起multi命令,redi

Redis——樂觀控制事務

      redis對事務的支援比較簡單。redis只能保證一個客戶端發起的事務命令可以執行,中間不會插入其他事務。因為redis是單執行緒的,所以做到上面這點很容易。一般redis接受到客戶端的命

redis樂觀(適用於秒殺系統)

修改 導致 代碼 -a 通知 解決 redis服務器 font 變化 redis事務中的WATCH命令和基於CAS的樂觀鎖 在Redis的事務中,WATCH命令可用於提供CAS(check-and-set)功能。假設我們通過WATCH命令在事務執行之前監控了多個Keys,

redis樂觀

進程模型 包括 避免 隊列 讀取數據 回滾 enc 監視 高效 樂觀鎖(又名樂觀並發控制,Optimistic Concurrency Control,縮寫“OCC”),是一種並發控制的方法。它假設多用戶並發的事務在處理時不會彼此互相影響,各事務能夠在不產生鎖的情況下處理各

悲觀樂觀解決事務丟失跟新問題

事務丟失更新:A,B兩個事務通過id獲取資料,name:lisi,money:1000 首先,A事務修改name,把lisi變為zhangsan,然後提交事務。此時,B事務中不受A事務的影響,即B事務中的name還是lisi,此時如果B事務改變money為2000,然後提交事務。最後資料庫的資料

悲觀樂觀以及事務的隔離級別

悲觀鎖(Pessimistic Lock), 顧名思義,就是很悲觀,每次去拿資料的時候都認為別人會修改,所以每次在拿資料的時候都會上鎖,這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖。 樂觀鎖(Optimi

Redis深入操作(redis事務控制樂觀,密碼配置,效能監控)

一、redis事務控制1.1redis本身支援事務處理,但是這種支援的事務處理本身是存在有設計缺陷的,而且與傳統資料庫的事務控制不同,首先來看一下redis中事務支援命令:                        .開啟事務:multi                 

Redis:多線程修改同一個Key使用watch+事務(mutil)實現樂觀

width uno ... ack spool 場景 .html 高並發 遇到的問題 本篇文章是通過watch(監控)+mutil(事務)實現應用於在分布式高並發處理等相關場景。下邊先通過redis-cli.exe來測試多個線程修改時,遇到問題及解決問題。 高並發下修改同

redis專項練習三redis事務樂觀

一、redis的事務   Redis目前對事務的支援相對簡單。Redis只能保證一個client發起的事務中的命令可以連續的執行,而中間不會插入其他的client命令。當一個client在一個連結中發出multi命令時,這個連結會進入一個事務上下文,該連線後續的命令不會立即執

StackExchange.Redis學習筆記(四) 事務控制和Batch批量操作

成了 pan arp 展示 關於 public 連續 因此 用戶 Redis事物 Redis命令實現事務 Redis的事物包含在multi和exec(執行)或者discard(回滾)命令中 和sql事務不同的是,Redis調用Exec只是將所有的命令變成一個單元一起執行,期

[數據庫事務]詳解七: 深入理解樂觀與悲觀

ood insert 影響 hiberna memcach begin 策略 goods 其它 註明: 本文轉載自http://www.hollischuang.com/archives/934在數據庫的鎖機制中介紹過,數據庫管理系統(DBMS)中的並發控制的任務是確保在

25.partial update內置樂觀並發控制

sans 沖突 amp 數據返回 update gpo tro 知識點 把他 主要知識點 (1)partial update內置樂觀鎖並發控制 (2)retry_on_conflict post /index/type/id/_update?ret

基於external version進行樂觀並發控制

行修改 樂觀鎖 nal div type 基於 gpo 區別 並發 ?version=1?version=1&version_type=external它們的唯一區別在於,_version,只有當你提供的version與es中的_version一模一樣的時候,才可以

ES:partial update 原理、 基於groovy使用、 內建樂觀併發控制

1、partial update基本語法 POST /index/type/id/_update { "doc" : { "要修改的少數幾個field即可,不需要全量的資料" } } 每次就傳遞少數幾個發生修改的field即可,不需要將全量的docu

ES:基於_version進行樂觀併發控制

圖示的衝突過程,其實就是es的併發衝突問題,會導致資料不準確 當併發操作es的執行緒越多,或者讀取一份資料,供使用者查詢和操作的時間越長,在這段時間裡,如果資料被其他使用者修改,那麼我們拿到的就是舊資料,基於舊資料去操作,就會導致錯誤的結果 1、悲觀鎖與樂觀鎖兩種併發

ElasticSearch最佳入門實踐(二十四)partial update樂觀併發控制原理以及相關操作

(1)partial update內建樂觀鎖併發控制 partial update內部是自動執行之前所說的樂觀鎖的併發控制方案 兩個執行緒 都拿到了document資料和_version 使用傳過來的field更新document 執行緒B也在做partial update

elasticsearch 筆記七: es樂觀的併發控制

1.併發控制 es 的併發控制是通過多version來實現的(不清楚樂觀鎖的自己提升去) 2.例項 //建立索引 PUT /test_index/test_type/7 { "test_field": "test test" } //返回建立結果 GET test_index

redis 實現樂觀

轉載務必說明出處:https://blog.csdn.net/LiaoHongHB/article/details/83410650 1、redis通過事務機制中watch命令可以實現Java樂觀鎖機制 public void watch() { try {

事務 悲觀 樂觀 概念 應用場景 使用方式 小記

【部落格園cnblogs筆者m-yb原創(部分引用, 在文末有註明),轉載請加本文部落格連結,筆者github: https://github.com/mayangbo666,公眾號aandb7,QQ群927113708】  https://www.cnblogs.com/m-yb/p/99749

JPA事務併發(樂觀實現隔離機制)

事務(4個特性ACID) 原子性(atomic),事務必須是原子工作單元;對於其資料修改,要麼全都執行,要麼全都不執行 一致性(consistent),事務在完成時,必須使所有的資料都保持一致狀態。 隔離性(insulation),由事務併發所作的修改必須與任何其它併發事務所作的修改