分布式锁定义

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

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

目的

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

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

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

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

实现方式：

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

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

存在问题：

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

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

官方建议：

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

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

什么是分布式锁？redis、zookeeper、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接口，天然提供分布式锁功能：只需申请锁、释放锁，不用关注锁的租期问题。