什么是分布式锁？redis、zookeeper、etcd实现分布式锁有什么不同之处？
目錄
分布式鎖定義
目的
基于redis分布式鎖
基于zookeeper實現的分布式鎖
edis、zookeeper、etcd實現分布式鎖的比較
建議選擇etcd實現分布式鎖
分布式鎖定義
分布式環境下，鎖定全局唯一資源。
請求處理串行化、實際表現為互斥鎖。
目的
? ? 交易訂單鎖定：防止重復下單、解決業務層冪等問題。
? ? MQ消息消費冪等性：發送消息重復、消息消費端去重、比如手機提現。
? ? 在用戶對商品下單后，訂單狀態為待支付，在某一時刻用戶正在對該訂單做支付操作，商家對該訂單進行改價操作：狀態的修改行為需要做串行化處理，避免出現數據錯亂。
基于redis分布式鎖
? ? redis單進程、單線程，唯一線程串行化處理。
實現方式：
? ? redis?setnx命令在指定的key不存在時，為key設置指定的值。
? ? setnx keyname?value?expire?time ：設置成功，返回1，設置失敗，返回0。
存在問題：
? ? 鎖時間不可控，無法續租期。
? ? 單點問題：單實例存在進程一旦死掉，會徹底阻塞業務流程；主從方式，主從數據異步，會存在鎖失效問題。（極端情況下，高可用無法保證，所以在交易場景這種鎖是不ok的，但是在一些社交場景也ok）
官方建議：
? ? redis本身建議使用rediock（相當于RAFT）算法來保證，但是問題是需要至少三個redis主從實例來完成，維護成本相對較高。rediock等同于自己實現簡單的一致性協議，細節繁瑣，且容易出錯。
基于zookeeper實現的分布式鎖
zookeeper對鎖實現使用創建臨時節點和watch機制，執行效率、擴展能力、社區活躍度等方面低于etcd。
edis、zookeeper、etcd實現分布式鎖的比較
建議選擇etcd實現分布式鎖
分布式鎖存儲選型（etcd）：
? ? 簡單KV、強一致、高可用（無單點）、數據高可靠（持久化）
獲取鎖平均耗時：
? ? 獲取鎖的平均耗時大概是在2.1ms左右。
? ? 由于etcd的強一致性，根據raft算法，消耗時間稍微長一點。
?
etcd兼容性測試：
? ? etcd提供了獨有的集群管理模式，方便進行極端case下的測試，以三個節點的etcd集群為例：
?? ?? ? 1.單節點停機，不影響持續寫入，不影響讀，結果有一致性。
?? ?? ? 2.當只有一個節點時，讀會停機，寫入正常。
?? ?? ? 3.理論上只要不是多節點同時停機，線上服務不會受影響。
?
etcd恢復/版本：
? ? etcd有自有的數據恢復方式，如果服務停機后，可以將所有數據轉移重啟。
? ? etcd的增刪節點，節點遷移等部署相關，均有相關操作方式。
? ? etcd版本選擇，選擇用etcd3.2.9，因為V3?API暫時還不夠完備，建議用V2方式實現：
?? ??? ?V3提供gRPC接口，天然提供分布式鎖功能：只需申請鎖、釋放鎖，不用關注鎖的租期問題。
總結
以上是生活随笔為你收集整理的什么是分布式锁？redis、zookeeper、etcd实现分布式锁有什么不同之处？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 什么是服务的幂等？为什么要实现幂等？
- 下一篇： java的socket读取一行就结束运行