[后端进阶] 详解分布式锁的三种实现方式：MySQL vs Redis vs ZooKeeper

在微服务架构或分布式系统中，Java 内置的锁（如 synchronized 或 ReentrantLock）只能限制当前 JVM 内部的线程互斥。当我们需要跨多个服务节点、跨进程地去抢占同一个资源（如“扣减库存”、“抢单”）时，就需要引入分布式锁。

本文将深入对比业界常见的三种分布式锁实现方案：MySQL、Redis 和 ZooKeeper，解析其原理、代码实现及优缺点。

一、基于 MySQL 实现分布式锁

MySQL 实现分布式锁主要利用了数据库的唯一性约束或排他锁（X锁）特性。

1. 方案 A：基于唯一索引 (Unique Index)

这是最直观的方法。我们创建一个锁表，并对 lock_key 字段加上唯一索引。

• 加锁：执行 INSERT INTO lock_table (lock_key) VALUES ('order_101');。如果插入成功，则获取锁；如果报 Duplicate Key Error，则获取失败。
• 解锁：执行 DELETE FROM lock_table WHERE lock_key = 'order_101';。

2. 方案 B：基于排他锁 (SELECT ... FOR UPDATE)

利用 MySQL 的事务机制，通过 FOR UPDATE 对某一行数据加排他锁。

START TRANSACTION;
-- 阻塞式等待获取锁
SELECT * FROM distributed_lock WHERE lock_key = 'order_101' FOR UPDATE;
-- 执行业务逻辑...
COMMIT; -- 提交事务即释放锁

⚠️ 致命注意点：必须加索引！

在使用 FOR UPDATE 时，WHERE 后面的字段（如 lock_key）必须有索引。

• 有索引：MySQL 使用行锁（Row Lock），只锁住这一行，并发互不影响。
• 无索引：MySQL 无法定位行，会进行全表扫描，进而导致锁表。这会让系统的并发能力瞬间降为 1，甚至导致数据库连接池爆满导致服务崩溃。

优缺点分析

• 优点：理解简单，不需要引入额外的中间件（利用现有数据库）。
• 缺点：
  • 性能差：依赖磁盘 I/O，并发支持有限。
  • 死锁风险：基于 INSERT 的方案如果服务宕机，锁无法自动释放（需额外开发定时清理任务）。
  • 连接资源宝贵：基于 FOR UPDATE 的方案会长时间占用数据库连接。

二、基于 Redis 实现分布式锁（推荐）

这是目前互联网企业最常用的方案，核心优势是高性能。

1. 核心原理

早期我们使用 SETNX (Set if Not Exists) 指令，但在生产环境中，推荐使用 Redisson 框架，它封装了复杂的底层逻辑。

• 互斥：利用 Redis 的原子操作，同一时刻只有一个客户端能设置成功。
• 防死锁：设置过期时间（TTL）。
• 自动续期（看门狗 Watchdog）：这是 Redisson 的黑科技。如果业务逻辑执行时间超过了锁的过期时间，看门狗会起一个后台线程，每隔一段时间自动给锁“续命”，防止业务没跑完锁就过期了。

2. Java 代码示例 (Redisson)

@Autowired
private RedissonClient redisson;

public void doBusiness() {
    RLock lock = redisson.getLock("my-lock");
    try {
        // 尝试加锁，支持自动续期
        lock.lock(); 
        
        // 执行业务...
        System.out.println("Processing...");
        
    } finally {
        // 释放锁前判断是否是当前线程持有
        if (lock.isLocked() && lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
}

优缺点分析

• 优点：性能极高（纯内存操作），实现简单（Redisson 封装极其完善），支持可重入。
• 缺点：AP 模型（弱一致性）。在 Redis 哨兵或集群模式下，如果主节点还没来得及把锁同步给从节点就挂了，从节点升级为主节点后，锁会丢失，可能导致两个线程同时持锁。

三、基于 ZooKeeper 实现分布式锁

ZooKeeper (ZK) 保证 CP（强一致性），适用于对可靠性要求极高的场景（如金融核心系统）。通常配合 Curator 客户端使用。

1. 核心原理

利用 ZK 的临时顺序节点 (Ephemeral Sequential Node)。

1. 抢锁：所有客户端在 /lock 目录下创建一个临时顺序节点。
2. 判断：获取所有子节点，判断自己的序号是不是最小的。如果是，获得锁。
3. 等待：如果不是最小，监听（Watch）比自己小 1 号的那个节点。
4. 释放：前一个节点删除（释放锁或宕机），当前节点收到通知，获得锁。

优缺点分析

• 优点：
  • 强一致性：不存在 Redis 的丢锁问题。
  • 安全性高：因为是临时节点，客户端宕机后节点自动消失，天然杜绝死锁。
• 缺点：性能不如 Redis，频繁创建和删除节点对 ZK 集群压力较大。

四、总结与选型建议

选型建议：

1. 绝大多数互联网业务（90%）：首选 Redis (Redisson)。即使极端情况下偶尔丢锁，通过业务层的幂等性校验也能兜底，性能收益巨大。
2. 金融级/对一致性极其敏感的场景：首选 ZooKeeper。宁可慢一点，也不能出差错。
3. 极小规模/不想引入新组件：可以使用 MySQL，但务必记得给锁字段加唯一索引，防止锁全表导致系统崩溃。

作者提示：技术选型没有绝对的“最好”，只有“最适合”。在面试中回答此问题时，建议先说出 Redis 的方案，再对比 ZK 的强一致性优势，最后提一下 MySQL 的实现原理及坑点，展现你的知识广度。