高手之路——分布式锁设计与实践

分布式锁设计与实践

分布式锁定义

• 分布式环境下，锁定全局唯一资源
  • 请求处理串行化
  • 实际表现互斥锁

分布式锁目的

• 交易订单锁定
  • 防止重复下单
  • 解决业务层幂等问题
• MQ消息幂等性
  • 发送消息重复
  • 消息消费端去重
  • 比如手机提现
• 在用户对商品下单后，订单状态为待支付，在某一时刻用户正在对该订单做支付操作，商家对该订单进行改价操作
  • 状态的修改行为需要做串行化处理，避免出现数据错乱。

基于redis分布式锁

• 基于redis分布式锁方案
  • 唯一线程串行处理
  • 实现方式
    • Redis Setnx（set if not exists）命令在指定的key不存在时，为key设置指定的值
      • setnx key value expire time
        • 设置成功，返回1，设置失败返回0
    • 存在问题
      • 锁时间不可控
        • 无法续租期
      • 单点问题
        • 单实例存在进程一旦死掉，会彻底阻塞业务流程（无法保证高可用）
        • 主从方式，主从数据异步，会存在锁失效问题
      • 官方建议
        • redis本身建议使用Redlock算法来保证，但是问题是需要至少三个Redis主从实例来完成，维护成本相对较高。Redlock等同于自己实现简单的一致性协议，细节繁琐，且容易出错。

问题本质：分布式锁是CP模型，redis集群是AP模型通过CP模型解决

高可用分布式锁设计目标

• 设计目标
  • 强一致性
  • 服务高可用，系统稳健
  • 锁自动续约及其自动释放
  • 代码高度抽象，业务接入极简
  • 可视化管理后台，监控及管理

高可用分布式锁设计方案对比

存储层产品对比

-	redis	zookeeper	etcd
一致性算法	无	paxos	raft
CAP	AP	CP	CP/AP
高可用	主从	N+1可用	N+1可用
接口类型	客户端	客户端	http/grpc
实现	setNX	createEphemeral	restful API

• 由于redis无法保证数据一致性
• zk对锁实现使用创建临时节点和watch机制。执行效率、扩展性、社区活跃度等低于etcd
• 选择基于etcd实现

分布式锁存储选型

• etcd

  • 简单KV
  • 强一致性
  • 高可用
    • 无单点
  • 数据高可靠
    • 持久化

• 分布式Client+etcd

  • Client TTL模式

使用场景一：申请锁

• 业务方申请资源锁，调用时提供key，ttl
• etcd生成uuid，作为当前锁的唯一凭证，将（key，uuid，ttl）写etcd
• 检查etcd中此key是否存在，如没有，尝试写入key，写入失败，拿锁失败，写入成功拿到锁
• 拿锁后，心跳线程启动，心跳线程维持时间为ttl/3，cas uuid（比较还是不是自己的锁，是的话就更新），从而将key值续租
• 相关etcd API
  • 申请锁
    • curl http://ip:2379/v2/keys/foo -XPUT -d value=bar -d ttl=5 prevExist=false
  • CAS更新锁租约
    • curl http://ip:2379/v2/keys/foo?prevValue=prev_uuid -XPUT -d ttl=5 -d ttl=5 -d refresh=true -d prevExist=true
  • CAS删除锁
    • curl http://ip:2379/v2/keys/foo?prevValue=prev_uuid -XDELETE

使用场景二：申请锁，但锁已被持有

• 业务方申请资源锁，调用时提过key，ttl
• 检查etcd中key的存在，若已存在，拿锁失败

使用场景三：锁的清理

• 如果调用方正常结束，通过cas接口调用delete方法自动清理etcd中的key值
• 如果调用方异常终止，等待原有锁ttl过期后，锁资源释放

业务接入

提供客户端
作业：使用etcd实现分布式锁，提供简易客户端

获取锁平均耗时监控

etcd兼容性测试

• etcd提供了独有的集群管理模式，方便进行极端case下的测试，以三个节点的etcd集群为例
  • 单节点停机，不影响持续写入，不影响读，结果有一致性
  • 当只有一个节点时，读会停机，写入成功
  • 理论上只要不是多节点同时停机，线上服务不会受影响

etcd恢复/版本

• etcd有自有的数据恢方式，如果服务停机后，可以将所有数据转移重启
• etcd的增删节点，节点迁移等部署相关，均有相关操作方式
• etcd版本选择，选择使用etcd3.2.9，但是因为V3 API暂时还不完备，建议用V2方式实现
  • V3提供gRPC接口
  • 天然提供分布式锁功能
    • 只需要申请锁，释放锁
    • 不用关注锁的租期问题

分布式锁特殊场景

• 特殊场景一：分布式锁只是在同一自然时间的互斥锁，本身不解决幂等性问题

  • 接入业务需要完善从获得锁到释放锁中间的数据幂等逻辑

• 特殊场景二：锁没有按照预期续租

  • 心跳续租没成功
  • 马上启动GC,GC时间够长

• 特殊场景三：etcd内部协调发生问题

  • leader节点挂了，选主中
  • Raft日志数据同步发送错误或者不一致问题