Redis分布式锁实战：从setIfAbsent与expire到高并发保单处理

1. 为什么需要Redis分布式锁？

最近在做一个保险业务系统时遇到了一个典型的高并发问题：多个客服同时操作同一份保单，导致数据错乱。比如客服A正在修改保单信息，客服B同时也在修改，最后保存的数据就乱套了。这种场景在电商秒杀、金融交易等系统中也很常见。

传统单机锁（如synchronized）在分布式环境下完全失效，因为多个服务实例运行在不同机器上。这时候就需要分布式锁来保证同一时刻只有一个实例能操作共享资源。Redis凭借其高性能和原子性操作，成为实现分布式锁的首选方案。

我刚开始用Redis锁时踩过不少坑。有一次忘记设置过期时间，结果系统崩溃后锁永远无法释放，导致整个系统瘫痪。还有一次设置的过期时间太短，业务还没执行完锁就自动释放了，引发数据不一致。这些问题都源于对setIfAbsent和expire两个关键命令的理解不够深入。

2. Redis分布式锁的核心机制

2.1 setIfAbsent的原子性魔法

setIfAbsent是Redis实现分布式锁的核心命令，它的作用是只有当key不存在时才设置值。用Java代码表示是这样的：

java复制Boolean result = redisTemplate.opsForValue()
    .setIfAbsent("policy_lock_123", "request_456", 30, TimeUnit.SECONDS);

这个操作是原子性的，意味着判断key是否存在和设置值这两个动作不会被其他命令打断。如果多个线程同时执行这个命令，Redis会确保只有一个能成功返回true。

我在实际项目中发现，value应该设置为唯一标识（如UUID），这样在释放锁时可以验证是否是自己加的锁，避免误删别人的锁。曾经有个线上事故就是因为value设置成固定值，导致锁被错误释放。

2.2 expire防止死锁的关键

expire命令用于设置key的过期时间，这是避免死锁的关键保障。即使持有锁的客户端崩溃，锁也会在过期后自动释放。但要注意两个细节：

1. 过期时间不能太短，要覆盖业务操作的最长时间。比如保单处理通常需要3-5秒，那么锁至少要设置10秒以上
2. 过期时间也不能太长，否则系统故障时恢复时间会变长

在Spring Data Redis中，可以直接在setIfAbsent时设置过期时间，这是最推荐的做法：

java复制// 推荐：原子性设置值和过期时间
redisTemplate.opsForValue()
    .setIfAbsent(lockKey, lockValue, 30, TimeUnit.SECONDS);

// 不推荐：分两步操作可能产生竞态条件
if(redisTemplate.opsForValue().setIfAbsent(lockKey, lockValue)) {
    redisTemplate.expire(lockKey, 30, TimeUnit.SECONDS);
}

3. 高并发保单处理实战

3.1 完整分布式锁实现

下面是一个经过生产验证的保单处理锁实现：

java复制public class PolicyLockService {
    @Autowired
    private StringRedisTemplate redisTemplate;
    
    private static final String LOCK_PREFIX = "policy_lock_";
    private static final int LOCK_EXPIRE = 30; // 秒
    
    public boolean processPolicy(String policyId, PolicyProcessor processor) {
        String lockKey = LOCK_PREFIX + policyId;
        String lockValue = UUID.randomUUID().toString();
        
        try {
            // 尝试获取锁
            Boolean acquired = redisTemplate.opsForValue()
                .setIfAbsent(lockKey, lockValue, LOCK_EXPIRE, TimeUnit.SECONDS);
            
            if(Boolean.TRUE.equals(acquired)) {
                // 执行业务逻辑
                return processor.process();
            } else {
                throw new BusyException("保单正在被其他客服处理");
            }
        } finally {
            // 释放锁
            String script = 
                "if redis.call('get',KEYS[1]) == ARGV[1] then " +
                "   return redis.call('del',KEYS[1]) " +
                "else " +
                "   return 0 " +
                "end";
            
            redisTemplate.execute(
                new DefaultRedisScript<>(script, Long.class),
                Collections.singletonList(lockKey),
                lockValue);
        }
    }
    
    public interface PolicyProcessor {
        boolean process();
    }
}

这个实现有几个关键点：

1. 使用policyId作为锁key的一部分，实现细粒度锁
2. 设置随机value并在释放时校验，防止误删
3. 使用Lua脚本保证原子性释放
4. 通过接口抽象业务逻辑处理

3.2 处理锁冲突的优化策略

在高并发场景下，直接返回"系统繁忙"并不友好。我们可以采用以下策略优化用户体验：

1. 有限重试机制：设置最大重试次数和间隔

java复制int retry = 0;
while(retry++ < 3) {
    if(tryLock(policyId)) {
        try {
            return processPolicy();
        } finally {
            unlock(policyId);
        }
    }
    Thread.sleep(100 * retry); // 指数退避
}
throw new BusyException("当前操作人数过多，请稍后再试");

2. 异步排队处理：将请求放入消息队列顺序处理
3. 乐观锁机制：使用版本号控制并发修改

4. 生产环境中的注意事项

4.1 Redis集群的特殊考量

在Redis集群环境下，需要考虑跨节点锁一致性问题。官方推荐的Redlock算法需要至少5个主节点才能保证可靠性，对大多数中小系统来说成本太高。实际项目中，如果业务可以接受偶尔的锁失效，单Redis节点+合理过期时间通常就够了。

我曾经遇到一个案例：某金融系统使用3节点Redis集群，由于网络分区导致多个客户端同时获取锁。后来我们通过以下措施降低风险：

1. 将锁过期时间从30秒缩短到10秒
2. 增加客户端心跳续约机制
3. 关键操作增加数据库乐观锁兜底

4.2 监控与报警配置

分布式锁的异常必须及时发现。建议监控以下指标：

1. 锁等待时间：如果平均等待时间超过1秒，可能需要扩容
2. 锁冲突次数：突增可能预示热点问题
3. 锁未释放次数：可能代码存在bug

在Grafana中可以这样配置报警规则：

sql复制# 锁等待时间报警
avg(redis_lock_wait_seconds{application="$application"}) by (lock_type) > 1

# 锁冲突报警
increase(redis_lock_conflict_total{application="$application"}[1m]) > 50

4.3 性能优化技巧

1. 锁粒度控制：不要用全局锁，根据业务ID分段
2. 锁超时时间：根据压测结果设置合理值
3. 本地缓存：对非实时性要求高的数据，可以结合本地缓存减少锁竞争
4. 读写分离：读多写少场景可以使用读写锁

在保单处理场景中，我们最终将平均处理时间从800ms优化到300ms，关键就是细化了锁粒度：

• 旧方案：整个保单对象加锁
• 新方案：按保单的不同模块（基本信息、受益人、险种）分别加锁