您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關zk和redis分布式鎖有哪些區別的內容。小編覺得挺實用的,因此分享給大家做個參考。一起跟隨小編過來看看吧。
Redis實現分布式鎖
根據lockKey區進行setnx(set not exist,如果key值為空,則正常設置,返回1,否則不會進行設置并返回0)操作,如果設置成功,表示已經獲得鎖,否則并沒有獲取鎖。
2.如果沒有獲得鎖,去Redis上拿到該key對應的值,在該key上我們存儲一個時間戳(用毫秒表示,t1),為了避免死鎖以及其他客戶端占用該鎖超過一定時間(5秒),使用該客戶端當前時間戳,與存儲的時間戳作比較。
3.如果沒有超過該key的使用時限,返回false,表示其他人正在占用該key,不能強制使用;如果已經超過時限,那我們就可以進行解鎖,使用我們的時間戳來代替該字段的值。
4.但是如果在setnx失敗后,get該值卻無法拿到該字段時,說明操作之前該鎖已經被釋放,這個時候,最好的辦法就是重新執行一遍setnx方法來獲取其值以獲得該鎖。
釋放鎖:刪除redis中key
Zookeeper實現分布式鎖
基于臨時順序節點:
1.客戶端調用create()方法創建名為“locknode/guid-lock-”的節點,需要注意的是,這里節點的創建類型需要設置為EPHEMERAL_SEQUENTIAL。
2.客戶端調用getChildren(“locknode”)方法來獲取所有已經創建的子節點。
3.客戶端獲取到所有子節點path之后,如果發現自己在步驟1中創建的節點是所有節點中序號最小的,那么就認為這個客戶端獲得了鎖。
4.如果創建的節點不是所有節點中序號最小的,那么則監視比自己創建節點的序列號小的最大的節點,進入等待。直到下次監視的子節點變更的時候,再進行子節點的獲取,判斷是否獲取鎖。
釋放鎖的過程相對比較簡單,就是刪除自己創建的那個子節點即可。
區別:
redis分布式鎖,其實需要自己不斷去嘗試獲取鎖,比較消耗性能
zk分布式鎖,獲取不到鎖,注冊個監聽器即可,不需要不斷主動嘗試獲取鎖,性能開銷較小
另外一點就是,如果是redis獲取鎖的那個客戶端bug了或者掛了,那么只能等待超時時間之后才能釋放鎖;而zk的話,因為創建的是臨時znode,只要客戶端掛了,znode就沒了,此時就自動釋放鎖
感謝各位的閱讀!關于zk和redis分布式鎖有哪些區別就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。