分布式锁选型指南：Redis、etcd、Zookeeper与数据库的实战对比

在现代分布式系统中，“锁”已经不再是简单的多线程互斥，而是跨机器、跨节点、跨服务的全局协调机制。“锁”用不好，轻则业务重复执行，重则库存超卖、资金错乱、系统雪崩。

本文将深入剖析以Redis、etcd、Zookeeper和数据库DB为代表的四种主流分布式锁实现方案，解析其原理、优劣与最佳适用场景。

01 为什么需要分布式锁？

在工程实践中，我们经常会遇到需要对共享资源进行互斥操作的场景，否则整个系统的数据一致性就会出现问题。典型场景如商品库存操作、Kubernetes调度器为Pod分配运行的Node。

要实现对共享资源的互斥操作，“锁”就是一个通用的解决方案。在单机应用中，多线程竞争同一资源，使用本地互斥锁即可。

然而，单节点存在单点故障，为保证服务高可用，就需要多节点部署。在多节点部署的分布式架构中，就必须使用分布式锁来解决资源的互斥操作问题。简而言之，分布式锁是能跨进程、跨节点、跨服务都有效的锁。

02 分布式锁要解决哪些问题？

一把好的“分布式锁”，应当具备以下核心能力：

能力	能力内容
互斥性	同一时间只有一个客户端能持有锁。
避免死锁	锁必须有超时机制，防止持有锁的服务异常崩溃导致锁永不释放。
高可用	即使提供锁服务的部分节点宕机，也不能影响锁状态的一致性。
性能	加锁、解锁操作不能成为系统整体吞吐量的瓶颈。
安全释放	必须确保只有锁的持有者才能释放锁，防止“误删他人锁”的灾难性后果。

03 分布式锁的“四大天王”实现详解

分布式锁的实现本质是依赖一个所有客户端都能访问的第三方共享存储系统，利用该系统的互斥或协调机制来充当“锁”的角色。

1. Redis分布式锁：性能王者

Redis 是分布式锁使用最广泛的方案，核心原因在于：性能快，且部署维护相对简单。

实现方式 核心原理是利用Redis的原子性SET命令，并配合过期时间实现加锁与防死锁。

（1）Redis 加锁

SET lock_key unique_id NX EX 30

• lock_key：锁的键名。
• unique_id：唯一随机值，用于标识请求客户端，确保只有加锁者才能解锁（防止误解锁）。
• NX：Not Exist，仅当 lock_key 不存在时才能设置成功，保证互斥性。
• EX 30：设置 30 秒过期时间，防止客户端宕机导致死锁。

（2）Redis 解锁 必须使用Lua脚本保证解锁操作的原子性：先判断unique_id是否匹配，再执行删除。

if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0
end

优点

• 性能极高：基于内存，加解锁速度快。
• 实现简单：通过Redisson等客户端框架可便捷使用。
• TTL自动防死锁：通过过期时间自动释放锁。

缺点

• 可靠性挑战：在主从异步复制模式下，主节点宕机且锁未同步到从节点时，可能导致新主节点上被重复加锁（锁丢失）。
• 需解决锁续期：需要Watch Dog等机制防止业务执行时间超过锁过期时间。

Redis基于主备异步复制，在主备切换时可能导致锁丢失，这是其相比etcd和ZK的主要安全隐患。

2. etcd分布式锁：云原生新贵

etcd 是专为云原生应用设计的高可用键值存储，基于Raft协议，是Kubernetes的核心组件。

实现方式 etcd利用其内置的Lease（租约）机制和Revision（版本号）来实现分布式锁。

（1）etcd 加锁

1. 客户端向etcd申请一个带TTL的Lease。
2. 使用Txn（事务）尝试创建一个key（锁），并将其绑定到该Lease上。事务条件（If）可判断key的create_revision是否为0（即不存在）来保证互斥性。

   txn := client.Txn(ctx).If(v3.Compare(v3.CreateRevision(k), "=", 0))
   txn = txn.Then(v3.OpPut(k, val, v3.WithLease(s.Lease())))
   txn = txn.Else(v3.OpGet(k))
   resp, err := txn.Commit()
   if err != nil {
   return err
   }

（2）etcd 解锁

• 获取锁失败的客户端通过Watch机制监听该key的变化。
• 客户端通过删除key来主动释放锁。
• 一旦Lease到期，etcd会自动删除关联的key，实现自动防死锁。

  var wr v3.WatchResponse
  wch := client.Watch(cctx, key, v3.WithRev(rev))
  for wr = range wch {
  for _, ev := range wr.Events {
    if ev.Type == mvccpb.DELETE {
       return nil
    }
  }
  }

优点

• 强一致性：基于Raft协议，可靠性极高。
• 云原生友好：天然与K8s生态集成，适合容器化环境。
• Lease机制：内置租约，使锁续期和防死锁的实现更简洁。

etcd实现的分布式锁安全性极高，不会出现Redis主从切换时可能发生的多个客户端同时持有锁的情况。

缺点

• 生态较新：相关客户端库和框架的成熟度与社区规模略逊于Redis和ZK。
• 性能中等：优于ZK，但逊于基于内存的Redis。

3. ZK分布式锁：一致性之王

ZooKeeper基于ZAB协议，天生具备强一致性和高可靠性，是分布式协调服务的经典选择。

实现方式 核心原理是利用ZK的临时有序节点和Watcher监听机制。

（1）ZooKeeper 加锁

1. 所有客户端在同一个持久化父节点（如 /locks）下创建临时有序子节点（如 /locks/lock-00000001）。
2. 客户端检查自己创建的节点是否是其所有兄弟节点中序号最小的。
3. 如果是最小节点，则成功获取锁。

（2）ZooKeeper 解锁

1. 若非最小节点（如B），则通过Watcher监听比自己序号小1的那个节点（如B监听A的节点）。
2. 持有锁的客户端完成业务后，删除自己创建的节点。
3. ZK通过Watcher机制通知下一个被监听的客户端（B）。
4. 被唤醒的客户端（B）重新检查，确认自己已成为最小节点后成功获取锁。

优点

• 高可靠性/强一致性：基于ZAB协议，锁状态不会丢失。
• 公平锁：基于有序节点，天然支持先到先得的公平锁。
• 防死锁：利用临时节点特性，客户端会话结束则锁自动释放。

缺点

• 性能相对较差：加解锁涉及ZK集群的写入和Watch通知，性能低于内存型中间件。
• 系统复杂度高：需要独立部署和维护ZooKeeper集群。

4. 数据库分布式锁：最简方案

实现方式 利用数据库的唯一约束或行级锁实现互斥，这是最原始、最易理解的方案。

方案一：唯一索引

1. 创建锁表，resource字段设为唯一索引。
2. 加锁：执行INSERT，成功则获取锁。

   INSERT INTO lock_table(resource, owner, expire_time)
   VALUES('product_A_stock', 'client_id_A', NOW() + INTERVAL 30 SECOND);

3. 解锁：删除对应记录。

方案二：行级锁 (SELECT FOR UPDATE) 在事务中，通过SELECT FOR UPDATE锁定特定行。

BEGIN;
SELECT * FROM lock_table WHERE resource = 'product_A_stock' FOR UPDATE;
-- 执行至此，说明成功获取锁
-- ... 执行业务逻辑
COMMIT; -- 事务结束，锁释放

优点

• 简单易懂：利用现有数据库，无需引入新组件。
• 可靠性高：依赖于数据库成熟的事务与持久化机制。

缺点

• 性能最差：数据库连接和事务成为高并发下的主要瓶颈。
• 死锁与清理：客户端宕机可能导致锁记录残留，需要额外的定时任务进行扫描和清理。

04 四大方案对比与选型指南

锁方案	性能 (并发能力)	可靠性	实现复杂度	推荐场景
Redis	极高	较高（主从异步复制有风险）	低（使用框架）	绝大多数高并发业务场景，如库存、订单、幂等控制
etcd	中高	极高（强一致）	中（云原生环境友好）	云原生系统或Kubernetes生态下的服务，对一致性要求高
Zookeeper	中低	极高（强一致）	高（需维护ZK集群）	对一致性要求极高的场景（如金融核心），或涉及选举、调度等
数据库	最低	较高（依赖DB自身）	低（无需新组件）	并发量极低或不允许引入新中间件的简单遗留系统

选型总结：

• 追求极致性能：首选 Redis，需注意主从架构下的锁可靠性问题，可考虑RedLock或集群模式。
• 要求强一致性：在 etcd 与 Zookeeper 中抉择。etcd更贴合云原生体系，ZK在传统分布式系统中经验更丰富。
• 力求简单、少依赖：在并发极低的场景下，可考虑 数据库 方案。

分布式锁没有银弹，Redis并非万能，ZooKeeper也未过时，etcd也不仅是K8s专用。只有明确业务在一致性、性能、复杂度上的真实需求，才能做出合理的选型，有效规避生产环境中的各种“坑”。