目錄

分布式鎖定義

目的

基于redis分布式鎖

基于zookeeper實現(xiàn)的分布式鎖

edis、zookeeper、etcd實現(xiàn)分布式鎖的比較

建議選擇etcd實現(xiàn)分布式鎖

---

分布式鎖定義

分布式環(huán)境下，鎖定全局唯一資源。

請求處理串行化、實際表現(xiàn)為互斥鎖。

目的

? ? 交易訂單鎖定：防止重復下單、解決業(yè)務層冪等問題。

? ? MQ消息消費冪等性：發(fā)送消息重復、消息消費端去重、比如手機提現(xiàn)。

? ? 在用戶對商品下單后，訂單狀態(tài)為待支付，在某一時刻用戶正在對該訂單做支付操作，商家對該訂單進行改價操作：狀態(tài)的修改行為需要做串行化處理，避免出現(xiàn)數(shù)據(jù)錯亂。

基于redis分布式鎖

? ? redis單進程、單線程，唯一線程串行化處理。

實現(xiàn)方式：

? ? redis?setnx命令在指定的key不存在時，為key設置指定的值。

? ? setnx keyname?value?expire?time ：設置成功，返回1，設置失敗，返回0。

存在問題：

? ? 鎖時間不可控，無法續(xù)租期。

? ? 單點問題：單實例存在進程一旦死掉，會徹底阻塞業(yè)務流程；主從方式，主從數(shù)據(jù)異步，會存在鎖失效問題。（極端情況下，高可用無法保證，所以在交易場景這種鎖是不ok的，但是在一些社交場景也ok）

官方建議：

? ? redis本身建議使用rediock（相當于RAFT）算法來保證，但是問題是需要至少三個redis主從實例來完成，維護成本相對較高。rediock等同于自己實現(xiàn)簡單的一致性協(xié)議，細節(jié)繁瑣，且容易出錯。

基于zookeeper實現(xiàn)的分布式鎖

zookeeper對鎖實現(xiàn)使用創(chuàng)建臨時節(jié)點和watch機制，執(zhí)行效率、擴展能力、社區(qū)活躍度等方面低于etcd。

edis、zookeeper、etcd實現(xiàn)分布式鎖的比較

建議選擇etcd實現(xiàn)分布式鎖

分布式鎖存儲選型（etcd）：

? ? 簡單KV、強一致、高可用（無單點）、數(shù)據(jù)高可靠（持久化）

獲取鎖平均耗時：

? ? 獲取鎖的平均耗時大概是在2.1ms左右。

? ? 由于etcd的強一致性，根據(jù)raft算法，消耗時間稍微長一點。

?

etcd兼容性測試：

? ? etcd提供了獨有的集群管理模式，方便進行極端case下的測試，以三個節(jié)點的etcd集群為例：

?? ?? ? 1.單節(jié)點停機，不影響持續(xù)寫入，不影響讀，結果有一致性。

?? ?? ? 2.當只有一個節(jié)點時，讀會停機，寫入正常。

?? ?? ? 3.理論上只要不是多節(jié)點同時停機，線上服務不會受影響。

?

etcd恢復/版本：

? ? etcd有自有的數(shù)據(jù)恢復方式，如果服務停機后，可以將所有數(shù)據(jù)轉移重啟。

? ? etcd的增刪節(jié)點，節(jié)點遷移等部署相關，均有相關操作方式。

? ? etcd版本選擇，選擇用etcd3.2.9，因為V3?API暫時還不夠完備，建議用V2方式實現(xiàn)：

?? ??? ?V3提供gRPC接口，天然提供分布式鎖功能：只需申請鎖、釋放鎖，不用關注鎖的租期問題。

總結

以上是生活随笔為你收集整理的什么是分布式锁？redis、zookeeper、etcd实现分布式锁有什么不同之处？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。