有這樣乙個情境，執行緒a和執行緒b都共享某個變數x分布式鎖可以基於很多種方式實現，比如zookeeper、redis…。
不管哪種方式，他的基本原理是不變的：用乙個狀態值表示鎖，對鎖的占用和釋放通過狀態值來標識
redis為單程序單執行緒模式，採用佇列模式將併發訪問變成序列訪問，且多客戶端對redis的連線並不存在競爭關係。1）setnx（set if not exists）redis的
setnx命令可以方便的實現分布式鎖。
setnx key value若給定的 key 已經存在，則 setnx 不做任何動作
所以我們使用執行下面的命令setnx可以用作加鎖原語(locking primitive)。
比如說，要對關鍵字(key)foo 加鎖，客戶端可以嘗試以下方式：
setnx lock.foo先獲取key對應的value值。若不存在則返回null，然後將舊的value更新為新的value。
getset key value當 key 存在但不是字串型別時，返回乙個錯誤。
返回值：
返回給定 key 的舊值[之前的值]。
當 key 沒有舊值時，也即是， key 不存在時，返回 nil 。
192.168.77.130:7002> getset lock "lock_2"
"lock_1" -->返回舊的value
192.168.77.130:7002> get lock
"lock_2"
2、釋放鎖：鎖資訊必須是會過期超時的，不能讓乙個執行緒長期占有乙個鎖而導致死鎖；（最簡單的方式就是del， 如果在刪除之前死鎖了。）
返回0時的正確做法：
c3傳送setnx lock.foo 想要獲得鎖，由於c0還持有鎖，所以redis返回給c3乙個0 c3傳送get lock.foo 以檢查鎖是否超時了，如果沒超時，則等待或重試。 反之，如果已超時，c3通過下面的操作來嘗試獲得鎖： getset lock.foo 通過getset，c3拿到的時間戳如果仍然是超時的，那就說明，c3如願以償拿到鎖了。 如果在c3之前，有個叫c4的客戶端比c3快一步執行了上面的操作，那麼c3拿到的時間戳是個未超時的值，這時，c3沒有如期獲得鎖，需要再次等待或重試。
留意一下，儘管c3沒拿到鎖，但它改寫了c4設定的鎖的超時值，不過這一點非常微小的誤差帶來的影響可以忽略
不計。
為了讓分布式鎖的演算法更穩鍵些，持有鎖的客戶端在解鎖之前應該再檢查一次自己的鎖是否已經超時，再去做del操作，因為可能客戶端因為某個耗時的操作而掛起，操作完的時候鎖因為超時已經被別人獲得，這時就不必解鎖了。示例：
public
static
boolean
lock
(string lockname)
else
else
}else
}}
redis分布式鎖
redis分布式鎖 直接上 我寫了四個redis分布式鎖的方法，大家可以提個意見 第一種方法 redis分布式鎖 param timeout public void lock long timeout thread.sleep 100 catch exception e override publi...
Redis分布式鎖
分布式鎖一般有三種實現方式 1.資料庫樂觀鎖 2.基於redis的分布式鎖 3.基於zookeeper的分布式鎖.首先，為了確保分布式鎖可用，我們至少要確保鎖的實現同時滿足以下四個條件 互斥性。在任意時刻，只有乙個客戶端能持有鎖。不會發生死鎖。即使有乙個客戶端在持有鎖的期間崩潰而沒有主動解鎖，也能保...
redis分布式鎖
使用redis的setnx命令實現分布式鎖 redis為單程序單執行緒模式，採用佇列模式將併發訪問變成序列訪問，且多個客戶端對redis的連線並不存在競爭關係。redis的setnx命令可以方便的實現分布式鎖。setnx key value 將key的值設為value，當且僅當key不存在。如給定的...