分布式锁Rediszookeeperetcd(推荐)怎样抉择？
Posted boonya
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分布式锁Rediszookeeperetcd(推荐)怎样抉择？相关的知识，希望对你有一定的参考价值。
目录
转载地址：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实现分布式锁的比较
建议选择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接口，天然提供分布式锁功能：只需申请锁、释放锁，不用关注锁的租期问题。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/A_art_xiang/article/details/107362718
以上是关于分布式锁Rediszookeeperetcd(推荐)怎样抉择？的主要内容，如果未能解决你的问题，请参考以下文章