分布式锁Redis、zookeeper、etcd(推荐)怎样抉择？

骑猪看日落 2022-10-16 04:53 36阅读 0赞

**目录**

分布式锁定义

使用分布式锁的目的

基于redis分布式锁

基于zookeeper实现的分布式锁

redis、zookeeper、etcd实现分布式锁的比较

建议选择etcd实现分布式锁

--------------------

转载地址：[https://blog.csdn.net/A\_art\_xiang/article/details/107362718][https_blog.csdn.net_A_art_xiang_article_details_107362718]

# 分布式锁定义 #

分布式环境下，锁定全局唯一资源。

请求处理**串行化**、实际表现为互斥锁。

# 使用分布式锁的目的 #

交易订单锁定：防止重复下单、解决业务层幂等问题。

MQ消息消费幂等性：发送消息重复、消息消费端去重、比如手机提现。

在用户对商品下单后，订单状态为待支付，在某一时刻用户正在对该订单做支付操作，商家对该订单进行改价操作：状态的修改行为需要做串行化处理，避免出现数据错乱。

# 基于redis分布式锁 #

redis单进程、单线程，唯一线程串行化处理。

实现方式：

redis setnx命令在指定的key不存在时，为key设置指定的值。

setnx keyname value expire time ：设置成功，返回1，设置失败，返回0。

存在问题：

锁时间不可控，无法续租期。

单点问题：单实例存在进程一旦死掉，会彻底阻塞业务流程；主从方式，主从数据异步，会存在锁失效问题。（极端情况下，高可用无法保证，所以在交易场景这种锁是不ok的，但是在一些社交场景也ok）

官方建议：

redis本身建议使用redlock（相当于RAFT）算法来保证，但是问题是需要至少三个redis主从实例来完成，维护成本相对较高。rediock等同于自己实现简单的一致性协议，细节繁琐，且容易出错。

# 基于zookeeper实现的分布式锁 #

zookeeper对锁实现使用创建临时节点和watch机制，执行效率、扩展能力、社区活跃度等方面低于etcd。

# redis、zookeeper、etcd实现分布式锁的比较 #

![eb07dfc69cfa8d3f4ba6a63c257abb0a.png][]

# 建议选择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接口，天然提供分布式锁功能：只需申请锁、释放锁，不用关注锁的租期问题。

本文链接：[https://blog.csdn.net/A\_art\_xiang/article/details/107362718][https_blog.csdn.net_A_art_xiang_article_details_107362718]

[https_blog.csdn.net_A_art_xiang_article_details_107362718]: https://blog.csdn.net/A_art_xiang/article/details/107362718
[eb07dfc69cfa8d3f4ba6a63c257abb0a.png]: /images/20221014/dacff0194fd44f6a9a8eb03644f87ca7.png
[CC 4.0 BY-SA]: https://creativecommons.org/licenses/by-sa/4.0/