1. 引言：当会议室预约变成代码世界

想象一下这样的场景：公司唯一的会议室被五个团队同时预约，结果大家面面相觑的尴尬场景。在分布式系统中，这样的"抢资源"问题每天都在发生，而Redis分布式锁就是解决这类问题的"电子预约系统"。但现实往往比理想骨感，我们经常遇到锁突然失效、重复预约等意外情况。本文将带你揭开这些问题的神秘面纱，并给出工业级的解决方案。

2. 分布式锁的典型翻车现场

2.1 锁超时引发的"幽灵锁"问题

// 错误示例：Spring Boot + Jedis技术栈
public void processWithLock() {
    String lockKey = "order_lock_123";
    // 获取锁（设置10秒过期）
    boolean locked = jedis.setnx(lockKey, "1") == 1;
    if(locked) {
        try {
            // 复杂业务逻辑耗时15秒
            processOrder(); 
        } finally {
            jedis.del(lockKey); // 锁已自动过期，此时可能删除其他请求的锁
        }
    }
}

这种实现存在两个致命缺陷：

  1. 业务执行超过锁有效期时，锁自动失效导致资源裸露
  2. 删除锁时未验证持有者身份，可能误删后续请求的锁

2.2 网络延迟造成的"双重锁定"

当Redis主从切换时，可能出现这样的时序问题：

  1. 客户端A在主节点获取锁
  2. 主节点宕机未同步到从节点
  3. 客户端B在从节点晋升的新主节点再次获取锁 此时两个客户端同时持有锁，造成数据不一致。

3. 高可靠分布式锁实现方案

3.1 Redisson的看门狗机制

// 正确示例：Spring Boot + Redisson技术栈
public void safeProcessWithLock() {
    RLock lock = redissonClient.getLock("order_lock_123");
    try {
        // 自动续期机制（默认30秒锁，每10秒续期）
        if(lock.tryLock(5, 300, TimeUnit.SECONDS)) { 
            processOrder(); // 长时间业务处理
        }
    } finally {
        if(lock.isLocked() && lock.isHeldByCurrentThread()) {
            lock.unlock(); // 安全释放锁
        }
    }
}

技术亮点：

  • 后台线程自动续期防止业务超时
  • 内置锁重入计数支持
  • 解锁前验证线程持有关系

3.2 Lua脚本实现的原子操作

-- Redis Lua脚本实现原子获取锁
local key = KEYS[1]
local value = ARGV[1]
local ttl = ARGV[2]

if redis.call('setnx', key, value) == 1 then
    redis.call('expire', key, ttl)
    return true
else
    if redis.call('get', key) == value then
        redis.call('expire', key, ttl)
        return true
    end
    return false
end

这个脚本实现了：

  1. 原子性的锁获取与过期设置
  2. 对同客户端请求的锁续期
  3. 避免非原子操作导致的状态不一致

4. 典型应用场景剖析

4.1 电商秒杀库存扣减

在小米新品抢购场景中，需要确保：

  • 同一用户不能重复提交订单
  • 库存扣减严格按顺序执行
  • 突发流量下系统保持稳定

4.2 分布式定时任务调度

当使用ElasticJob进行任务分片时：

  • 确保同一分片不会被多个执行器处理
  • 故障转移时需要及时释放锁
  • 任务执行时间超过锁定时长时的自动续约

5. 技术方案优缺点对比

方案类型 优点 缺点
原生Redis命令 实现简单、无需额外依赖 缺乏自动续期、存在原子性问题
Redisson客户端 功能完备、生产级可靠性 需要引入额外客户端依赖
Lua脚本实现 原子性有保障 维护成本高、缺乏自动续期机制

6. 避坑指南与最佳实践

  1. 锁命名规范：采用业务域:资源类型:资源ID格式，如payment:order_lock:202308001
  2. 设置合理的锁超时时间：建议业务最大执行时间的2-3倍
  3. 必须实现的三个基本特性：
    • 互斥性（基础要求）
    • 可重入性（避免死锁）
    • 容错性（客户端宕机自动释放）
  4. 监控告警配置： 
    # Redis监控命令示例
redis-cli info stats | grep instantaneous_ops_per_sec
redis-cli slowlog get 5

7. 总结与展望

经过多个项目的实践验证，我们得出这样的结论：使用Redisson客户端配合合理的超时配置，可以解决90%的分布式锁问题。但要注意，分布式锁不是银弹——对于需要严格顺序执行的场景，建议结合消息队列实现；在超高并发场景下，可以考虑分段锁优化。

随着Redis 7.0新特性的发布，基于多线程IO和函数计算的新一代锁方案正在涌现。但万变不离其宗，理解底层原理才是应对技术迭代的最佳武器。