redis中事務(wù)機制及樂觀鎖的實現(xiàn)
Redis事務(wù)機制
在MySQL等其他數(shù)據(jù)庫中,事務(wù)表示的是一組動作,這組動作要么全部執(zhí)行,要么全部不執(zhí)行?!?/p>
Redis目前對事物的支持相對簡單。Redis只能保證一個client發(fā)起的事務(wù)中的命令可以連續(xù)的執(zhí)行,而中間不會插入其他的client命令。當(dāng)一個client在一個鏈接中發(fā)出multi命令時,這個鏈接會進(jìn)入一個事務(wù)上下文,該連接后續(xù)的命令不會立即執(zhí)行,而是先放到一個隊列中,當(dāng)執(zhí)行exec命令時,redis會順序的執(zhí)行隊列中的所有命令。
Multi 開啟事務(wù): 127.0.0.1:6379[1]> multi #開啟事務(wù) OK 127.0.0.1:6379[1]> set age 15 #數(shù)據(jù)操作命令 QUEUED 127.0.0.1:6379[1]> set age 20 #數(shù)據(jù)操作命令 QUEUED 127.0.0.1:6379[1]> exec #執(zhí)行事務(wù) 1) OK 2) OK 127.0.0.1:6379[1]> get age "20" Discard:取消事務(wù),該命令實際是清空事務(wù)隊列中的命令并退出事務(wù)上下文,也就是事務(wù)回滾。 127.0.0.1:6379[1]> get age "20" 127.0.0.1:6379[1]> multi OK 127.0.0.1:6379[1]> set age 25 QUEUED 127.0.0.1:6379[1]> set age 30 QUEUED 127.0.0.1:6379[1]> discard #清空事務(wù)隊列 OK 127.0.0.1:6379[1]> get age "20"
注意redis事務(wù)問題:通常事務(wù)隊列中如果有一個事務(wù)失敗則整個事務(wù)都會回滾,但在redis中其他事務(wù)命令不會回滾。
樂觀鎖:redis大多數(shù)是基于數(shù)據(jù)版本(version)的記錄機制實現(xiàn)的。即為數(shù)據(jù)增加一個版本標(biāo)識,在基于數(shù)據(jù)庫表的版本解決方案中,一般是通過為數(shù)據(jù)庫表添加一個version字段來實現(xiàn)。在讀取數(shù)據(jù)時,將此版本號一同讀出,之后更新時對此版本號加1。此時,將提交數(shù)據(jù)的版本號與數(shù)據(jù)庫表對應(yīng)記錄的當(dāng)前版本號進(jìn)行對比,如果提交的數(shù)據(jù)版本號大于數(shù)據(jù)庫當(dāng)前版本號,則予以更新,否則認(rèn)為是過期數(shù)據(jù)。
watch監(jiān)控:watch命令會監(jiān)控給定的key,當(dāng)exec時如果監(jiān)視的key從調(diào)用watch后發(fā)生過變化,則整個事務(wù)會失敗。也可以調(diào)用watch多次監(jiān)視多個key,這樣就對指定事務(wù)key加樂觀鎖了。注意watch的key是對整個鏈接有效的,事務(wù)也一樣。如果鏈接斷開,監(jiān)視和事務(wù)都會被自動清除。當(dāng)然exex、discard、unwatch命令都會自動清除鏈接中的所有監(jiān)視。
在redis中對樂觀鎖的實現(xiàn):
假設(shè)有一個age的key,我們開啟兩個session來對age進(jìn)行賦值操作。
session1:
127.0.0.1:6379> get age "10" 127.0.0.1:6379> watch age #打開對age鍵的監(jiān)控(監(jiān)控其他操作是否對age鍵有修改操作) OK 127.0.0.1:6379> multi #開啟事務(wù)上下文 OK
session2:
127.0.0.1:6379> set age 20 OK 127.0.0.1:6379> get age "20"
在session2中直接操作age
再看session1:
127.0.0.1:6379> set age 30 #在session2中操作age后,我們在session1中繼續(xù)操作age QUEUED 127.0.0.1:6379> exec #執(zhí)行事務(wù) 返回nil 事務(wù)執(zhí)行不成功。 (nil) 127.0.0.1:6379> get age "20"
在這里我們發(fā)現(xiàn)事務(wù)不能執(zhí)行成功,這就是因為session1中的數(shù)據(jù)版本已經(jīng)小于數(shù)據(jù)庫中的數(shù)據(jù)版本。這就是redis中的樂觀鎖。
行百里者半九十。
總結(jié)
以上就是本文關(guān)于redis中事務(wù)機制及樂觀鎖的實現(xiàn)的全部內(nèi)容,希望對大家有所幫助,感興趣的朋友可以繼續(xù)參閱本站:sqlserver:查詢鎖住sql以及解鎖方法、幾個比較重要的MySQL變量、MySQL主庫binlog(master-log)與從庫relay-log關(guān)系代碼詳解等,如有不足之處,歡迎留言指出,小編會及時回復(fù)大家并進(jìn)行改正,感謝朋友們對本站的支持!
相關(guān)文章
Redis利用原子操作(INCR,DECR)實現(xiàn)分布式計數(shù)器
在分布式系統(tǒng)中,由于多個服務(wù)實例需要共享和修改同一個計數(shù)值,實現(xiàn)一個準(zhǔn)確、高效的分布式計數(shù)器至關(guān)重要,下面我們就來看看具體實現(xiàn)方法吧2025-07-07
redis 解決庫存并發(fā)問題實現(xiàn)數(shù)量控制
本文主要介紹了redis 解決庫存并發(fā)問題實現(xiàn)數(shù)量控制,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2022-04-04
Redis緩沖區(qū)溢出是指Redis緩沖區(qū)被寫入的數(shù)據(jù)超過了它的容量,導(dǎo)致數(shù)據(jù)無法存儲或被覆蓋。造成緩沖區(qū)溢出的原因可能是快速寫入大量數(shù)據(jù)、緩沖區(qū)未及時刷新或Redis服務(wù)器配置不當(dāng)?shù)取?/div> 2023-04-04最新評論

