在上節，我們細致講解了分布式鎖的原理，它的使用非常簡單，一條指令就可以完成加鎖操作。不過在集群環境下，這種方式是有缺陷的，它不是絕對安全的。 比如在 Sentinel 集群中，主節點掛掉時，從節點會取而代之，客戶端上卻并沒有明顯感知。原先第一個客戶端在主節點中申請成功了一把鎖，但是這把鎖還沒有來得及同步到從節點，主節點突然掛掉了。然后從節點變成了主節點，這個新的節點內部沒有這個鎖，所以當另一個客戶端過來請求加鎖時，立即就批準了。這樣就會導致系統中同樣一把鎖被兩個客戶端同時持有，不安全性由此產生。  不過這種不安全也僅僅是在主從發生 failover 的情況下才會產生，而且持續時間極短，業務系統多數情況下可以容忍。 ## Redlock 算法 為了解決這個問題，Antirez 發明了 Redlock 算法，它的流程比較復雜，不過已經有了很多開源的 library 做了良好的封裝，用戶可以拿來即用，比如 redlock-py。 ~~~ import redlock addrs = [{ "host": "localhost", "port": 6379, "db": 0 }, { "host": "localhost", "port": 6479, "db": 0 }, { "host": "localhost", "port": 6579, "db": 0 }] dlm = redlock.Redlock(addrs) success = dlm.lock("user-lck-laoqian", 5000) if success: print 'lock success' dlm.unlock('user-lck-laoqian') else: print 'lock failed' ~~~ 為了使用 Redlock，需要提供多個 Redis 實例，這些實例之前相互獨立沒有主從關系。同很多分布式算法一樣，redlock 也使用「大多數機制」。 > 加鎖時，它會向過半節點發送`set(key, value, nx=True, ex=xxx)`指令，只要過半節點`set`成功，那就認為加鎖成功。釋放鎖時，需要向所有節點發送`del`指令。 不過 Redlock 算法還需要考慮出錯重試、時鐘漂移等很多細節問題，同時因為 Redlock 需要向多個節點進行讀寫，意味著相比單實例 Redis 性能會下降一些。 ## Redlock 使用場景 如果你很在乎高可用性，希望掛了一臺 redis 完全不受影響，那就應該考慮 redlock。不過代價也是有的，需要更多的 redis 實例，性能也下降了，代碼上還需要引入額外的 library，運維上也需要特殊對待，這些都是需要考慮的成本，使用前請再三斟酌。 ## 擴展閱讀 #### 1.[你以為 Redlock 算法真的很完美？](https://link.juejin.im/?target=http%3A%2F%2Fmartin.kleppmann.com%2F2016%2F02%2F08%2Fhow-to-do-distributed-locking.html)