当前位置：首页 > news >正文

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

news 2026/6/28 20:47:24

在微服务架构或分布式系统中，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)。

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

优缺点分析

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

四、总结与选型建议

维度	MySQL	Redis (Redisson)	ZooKeeper
底层机制	唯一索引 / 行锁	SETNX / Lua 脚本	临时顺序节点
性能	低 (磁盘I/O)	极高 (内存)	中 (网络/磁盘)
一致性	强 (依赖事务)	弱 (主从切换可能丢锁)	强 (CP模型)
死锁风险	高 (需兜底策略)	低 (看门狗机制)	无 (断开即释放)
复杂度	手动实现麻烦	框架封装好	框架封装好