您的位置: 首页  >  文章  >  高手之路——分布式锁设计与实践

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

分类: 文章 • 2023-11-22 21:31:46

分布式锁设计与实践

分布式锁定义

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

分布式锁目的

  • 交易订单锁定
    • 防止重复下单
    • 解决业务层幂等问题
  • 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日志数据同步发送错误或者不一致问题

相关推荐