在修改產品的時候，針對同乙個產品多次進行修改的時候，出現了修改不符合預期的情況，後來發現是因為針對同乙個產品在同一時刻同時呼叫幾次修改的介面，會導致出現異常的情況。為了防止這種情況出現，首先想到了同步，但是修改任務是在多台伺服器上部署，並且分片只是按照id分片。因此如果只是單純的加鎖也還是會出現在不同的機器上修改同乙個產品id的，那麼想到了用redis分布式鎖。
下面我們還是先貼**然後講述**裡面涉及的模組的作用，以及了解redis分布式鎖的大體用法
// 修改 -如果修改 判斷redis快取裡面是否存在對應itemid的分布鎖
if(map.
getstring
(wishconstant.main_image_key)
!= null)
// 獲取到鎖執行
executerequest
(req)
; systemjedisclient.
releasedistributedlock
(revise.
getitemid()
, uuidstr);}
else
/**
* 嘗試獲取分布式鎖
* * @param jedis
* redis客戶端
* @param lockkey
* 鎖
* @param requestid
* 請求標識
* @param expiretime
* 超期時間
* @return 是否獲取成功
*/@override
public
boolean
trygetdistributedlock
(string lockkey, string requestid, long expiretime)
/**
* 釋放分布式鎖
* * @param jedis
* redis客戶端
* @param lockkey
* 鎖
* @param requestid
* 請求標識
* @return 是否釋放成功
*/@override
public
boolean
releasedistributedlock
(string lockkey, string requestid)
第乙個為key，我們使用key來當鎖，因為key是唯一的。
第二個為value，我們傳的是requestid，很多童鞋可能不明白，有key作為鎖不就夠了嗎，為什麼還要用到value？原因就是我們在上面講到可靠性時，分布式鎖要滿足第四個條件解鈴還須繫鈴人，通過給value賦值為requestid，我們就知道這把鎖是哪個請求加的了，在解鎖的時候就可以有依據。requestid可以使用uuid.randomuuid().tostring()方法生成。
第三個為n***，這個引數我們填的是nx，意思是set if not exist，即當key不存在時，我們進行set操作；若key已經存在，則不做任何操作；
第四個為expx，這個引數我們傳的是px，意思是我們要給這個key加乙個過期的設定，具體時間由第五個引數決定。
第五個為time，與第四個引數相呼應，代表key的過期時間。
最近開發用到的分布式鎖
最近開發的場景有分布式任務，任務是建立某些資源，只有建立成功了，某些資源才可使用。此時要考慮用分布式鎖，有以下幾種思路 1.通過資料庫，其實是建立一張表，字段類似於，id，key，values，status 和values欄位二選一 createtime。要鎖定某個物件時，以其唯一性的字段 例如id...
Redis分布式鎖，開發實戰
背景 專案的定時任務，出現重複執行的情況。由於解決時間非常緊急。打算用redis自帶的分布式鎖 setnx key value設定鍵的值，僅當鍵不存在時 redis官方文件setnx key value 將 key 的值設為 value 當且僅當 key 不存在。若給定的 key 已經存在，則set...
redis分布式鎖
redis分布式鎖 直接上 我寫了四個redis分布式鎖的方法，大家可以提個意見 第一種方法 redis分布式鎖 param timeout public void lock long timeout thread.sleep 100 catch exception e override publi...