分布式锁原理与Redis、ZooKeeper实现对比

1. 分布式锁的核心价值与挑战

在微服务架构成为主流的今天，同一个业务系统可能被部署在数十台服务器上运行。上周我就遇到一个典型案例：某电商平台的库存扣减服务，在促销活动时出现了超卖现象。事后排查发现，当多个节点的服务实例同时处理同一个商品的订单时，传统的单机锁完全失效了——这正是分布式锁要解决的核心问题。

分布式锁的本质是建立一个全局可见的互斥机制，确保在分布式环境下对共享资源的访问串行化。与单机环境的synchronized或ReentrantLock不同，它需要解决三个特殊挑战：

1. 网络不可靠性：锁获取和释放的网络请求可能丢失或延迟
2. 时钟不同步：各节点系统时间可能存在偏差
3. 故障容错：持有锁的客户端崩溃后不能造成死锁

2. 主流实现方案对比

2.1 基于数据库的实现

最朴素的方案是利用数据库的唯一约束特性：

sql复制CREATE TABLE distributed_lock (
  lock_name VARCHAR(64) PRIMARY KEY,
  owner VARCHAR(64),
  expire_time TIMESTAMP
);

获取锁时执行INSERT，释放锁时删除记录。某金融系统曾采用此方案，但在高并发场景下出现严重性能瓶颈——每秒只能处理约200次锁操作，且数据库连接很快耗尽。

关键提示：如果必须用数据库方案，建议使用SELECT...FOR UPDATE加上行锁，并设置合理的超时时间。但MySQL的间隙锁可能导致意外阻塞，需要特别注意。

2.2 Redis分布式锁演进史

第一代：SETNX + EXPIRE

redis复制SETNX lock_key unique_value
EXPIRE lock_key 10

这种方案存在原子性问题：如果SETNX成功但EXPIRE失败，将导致死锁。某社交APP曾因此造成线上事故。

第二代：Lua脚本保证原子性

lua复制if redis.call('setnx', KEYS[1], ARGV[1]) == 1 then
    return redis.call('expire', KEYS[1], ARGV[2])
else
    return 0
end

但仍有缺陷——客户端A可能在执行时间超过锁有效期后，误删客户端B的锁。

第三代：Redlock算法

Redis作者提出的多节点算法：

1. 获取当前毫秒级时间戳T1
2. 依次向N个Redis实例请求锁
3. 计算获取锁总耗时T2-T1
4. 当且仅当多数节点获取成功且T2-T1<锁超时时间时才算成功

我们在支付系统中实测发现，当网络延迟波动时仍可能出现多个客户端同时持有锁的情况。

2.3 ZooKeeper的临时顺序节点

创建临时有序节点，每个节点监听前一个节点的删除事件。这种方案强一致但性能较低，适合锁竞争不激烈的配置管理场景。某配置中心压测数据显示，ZK集群在300并发时平均响应时间已达120ms。

3. Redisson最佳实践

3.1 基础配置

xml复制<redisson:client>
    <redisson:single-server 
        address="redis://127.0.0.1:6379"
        connection-pool-size="64"
        idle-connection-timeout="10000"/>
</redisson:client>

3.2 可重入锁实现

java复制RLock lock = redisson.getLock("orderLock");
try {
    // 等待时间 持有时间 时间单位
    boolean res = lock.tryLock(10, 30, TimeUnit.SECONDS);
    if(res) {
        // 处理业务
    }
} finally {
    lock.unlock();
}

3.3 看门狗机制解析

Redisson通过定时续期解决业务执行时间超过锁有效期的问题：

1. 默认锁超时时间30秒
2. 获取锁成功后启动看门狗线程
3. 每10秒检查业务是否完成并刷新过期时间
4. 业务完成或客户端宕机时自动停止续期

重要经验：不要在使用看门狗时设置leaseTime参数，否则会覆盖自动续期逻辑。某物流系统曾因错误配置导致锁提前释放。

4. 典型问题排查指南

4.1 锁等待超时(ORA-02049)

在Oracle分布式事务中出现的经典错误，本质是跨节点事务等待锁超时。解决方案：

1. 调整_distributed_lock_timeout参数
2. 优化事务粒度，避免长事务
3. 考虑改用最终一致性方案

4.2 Redis锁误释放

通过打印线程栈定位问题线程：

java复制Thread.getAllStackTraces().keySet().forEach(t -> {
    System.out.println(t.getName());
    Arrays.stream(t.getStackTrace()).forEach(System.out::println);
});

4.3 锁竞争热点优化

某秒杀系统采用分段锁方案：

java复制// 原始热点key
String lockKey = "product_123"; 

// 优化为分段key
int segment = ThreadLocalRandom.current().nextInt(16);
String lockKey = "product_123_" + segment;

将QPS从500提升到8000+

5. 分布式锁的黄金法则

1. 失效安全：宁可拒绝请求也不要错误放行
2. 避免死锁：必须有超时机制，最好有自动释放保障
3. 性能平衡：根据场景选择CP或AP实现
4. 可观测性：记录锁等待时间、持有时间等关键指标

在消息队列消费者场景中，我们最终采用了Redis+ZooKeeper的混合方案：Redis处理高频短时锁，ZK管理关键配置的长时锁。这套方案支撑了日均10亿级的消息处理，平均锁等待时间控制在5ms以内。