Redis的原子性
同一個Redis實例女轿，它只以單個進程運行箭启，并可以確保所有請求都是在同一個序列中執(zhí)行的，因此可以保證Redis執(zhí)行的語句是原子性的蛉迹。 對于使用EVAL傅寡，通過LUA運行的多條語句，也可以保證像數(shù)據(jù)庫事務一樣具有原子性北救。
單實例Redis
一個Go的實現(xiàn)：https://github.com/bsm/redis-lock
單實例Redis只需借助SETNX（2.6.12后續(xù)版本只需SET key value NX也可以做到）即可：
LOCK(lockKey, ownerID):
SET lockKey ownerID NX PX expirationInMilliseconds
Unlock(lockKey, ownerID):
if GET(lockKey) == ownerID:
DEL(lockKey)
為lockKey設置一個獨一無二的值ownerID荐操，這樣在Unlock時，就不會出現(xiàn)lockKey正好被自動Expire刪除后珍策，原擁有者誤將別人的鎖釋放掉的情況托启。
如果一系列操作需要多個Redis操作，那么應當EVAL將多個操作封裝到同一段LUA代碼中攘宙，否則可能導致多次通訊時差中出現(xiàn)意外屯耸。
這種情況僅適用于同一條key存在于同一個Redis實例的情況，例如Redis只有一個蹭劈，或者不使用Master-Slave的Redis集群疗绣，例如無slave的hashring集群（利用類似一致性環(huán)形哈希計算key，最終請求落到特定節(jié)點上）
如果是使用Master-Slave的Redis集群铺韧，同一個key可以存在若干個備份多矮，寫入master的數(shù)據(jù)同步到slave中需要一段時間」颍考慮以下情形：
- Client A在master上獲取了對key的鎖： key:A
- master短暫故障（網(wǎng)絡故障工窍，重啟等），但key:A尚未同步到slave
- Client B向slave請求獲得鎖 key:B成功
- master恢復運行前酿，現(xiàn)在Client A患雏、B都認為自己獲得了鎖
Red-lock分布式鎖算法
一個Go的實現(xiàn)：https://github.com/go-redsync/redsync
在使用master-slave集群時，上述鎖的問題在于同步過程中發(fā)生了沖突罢维，因此一種解決方案是同時在多個節(jié)點上獲取鎖淹仑，當在多數(shù)節(jié)點成功時，就意味著其它client必然只能獲得少數(shù)成功肺孵，該算法來自https://redis.io/topics/distlock匀借，根據(jù)Redis文檔的說法，并未在生產(chǎn)環(huán)境全面驗證平窘，但理論上是行的通的吓肋。算法如下：
假定我們想要鎖定的時間為T，
- 記錄下當前時間start瑰艘，以毫秒（ms）為單位
- 借助多線程/協(xié)程同時向所有Redis實例請求獲得鎖 K:V, px=T是鬼，設置一個請求的超時時間肤舞，例如如果T為10s，那么我們可以設置請求超時為5-50ms均蜜，這樣就可以避免在一個已經(jīng)死掉的client上花費過多時間李剖，但該值不應當?shù)陀诰W(wǎng)絡通訊時間
- 不論成功與否，所有過程結束之后囤耳，計算剩余鎖的時間 t=now-start
- 如果t<T篙顺，或者成功獲得鎖的數(shù)量不超過集群的半數(shù)，則認為失敗
- 如果獲取鎖失敗充择，那么釋放掉所有集群上的鎖（僅限于K:V一致）德玫。為什么不只釋放自己成功獲得鎖的實例呢？考慮到集群中存在Master-Slave的同步機制椎麦，以及我們設置的請求超時宰僧，最終存有我們的鎖的實例將不限于曾經(jīng)成功的那些，因此必須對所有實例釋放我們的鎖铃剔。
