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

目录

分布式锁定义

使用分布式锁的目的

基于redis分布式锁

基于zookeeper实现的分布式锁

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

建议选择etcd实现分布式锁

---

转载地址：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