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

ZooKeeper vs Redis：分布式锁的实现与选型指南

ops 2025/9/6 13:07:06

一、Redis 分布式锁：追求极致的性能

Redis 分布式锁基于内存操作，其核心思想是在内存中设置一个唯一的键值对来表示锁的持有。

1. 基础实现（SETNX + Lua）

最简单的实现是使用 SETNX（SET if Not eXists）命令：
加锁：设置一个键，值为随机值，并设置过期时间（防止死锁）
SET lock_resource_name my_random_value NX PX 30000

#解锁：使用Lua脚本保证原子性（检查值再删除）
if redis.call(“get”, KEYS[1]) == ARGV[1] then
return redis.call(“del”, KEYS[1])
else
return 0
end

2. 生产环境推荐（Redisson框架）

在实际生产中，强烈推荐使用 Java 的 Redisson 库，它解决了基础实现的诸多痛点：

• 看门狗机制（Watchdog）：异步续期线程，在业务执行期间自动为锁续期，避免业务未完成而锁自动过期的问题。

• 可重入锁：支持同一线程多次加锁。

• Lua脚本原子性：所有操作都使用Lua脚本，保证原子性。
// Redisson 示例
RLock lock = redissonClient.getLock(“myLock”);
try {
lock.lock();
// … 执行业务逻辑
} finally {
lock.unlock();
}

3. Redis锁的优势与劣势

• 优势：

性能极高：基于内存操作，吞吐量大，延迟低，适用于高并发场景（如秒杀）。
实现简单：API 直观易懂，部署方便。
功能丰富：通过 Redisson 支持多种锁类型（可重入、公平、读写锁）。

• 劣势：

一致性依赖：在 Redis 主从异步复制架构下，如果主节点宕机且锁信息未同步到从节点，可能导致锁失效，出现多个客户端同时持有锁的情况（尽管 Redlock 算法试图解决此问题，但仍有争议）。
非强一致性：本质上是 AP 系统，优先保证可用性，在网络分区时可能牺牲一致性。

二、ZooKeeper 分布式锁：追求绝对的可靠

ZooKeeper 是一个分布式协调服务，其分布式锁基于临时顺序节点和 Watch 机制，实现了强一致性。

1. 核心实现（临时顺序节点 + Watch）

• 加锁：所有客户端在同一个锁目录（如 /locks/mylock）下创建临时顺序节点。

• 排队：客户端获取目录下所有子节点，判断自己创建的节点是否为序号最小的。

• 监听：如果不是最小的，客户端只需监听（Watch）比自己序号小的前一个节点的删除事件，而无需监听所有节点。

• 解锁：当前一个节点被删除（即锁被释放）时，ZooKeeper 会精准通知下一个客户端，使其获得锁。

2. 生产环境推荐（Curator框架）

Apache Curator 库封装了 ZooKeeper 的复杂逻辑，提供了开箱即用的分布式锁。
// Curator 示例
InterProcessMutex lock = new InterProcessMutex(client, “/locks/mylock”);
try {
if (lock.acquire(10, TimeUnit.SECONDS)) {
// … 执行业务逻辑
}
} finally {
lock.release();
}