Redis事务与锁机制深度解析

一、Redis事务机制

1. 基本命令与工作流程

Redis事务通过三个核心命令实现：

MULTI      # 开启事务
...命令队列... # 将多个命令放入队列
EXEC       # 执行事务
DISCARD    # 取消事务

示例场景：银行转账操作

MULTI
DECRBY account:A 100
INCRBY account:B 100
EXEC

2. 事务特性说明

• 不支持回滚：与关系型数据库不同，Redis事务中某条命令失败不会影响其他命令执行
• 原子性保证：EXEC命令执行时，所有命令要么全部执行，要么全部不执行
• 隔离级别：串行化隔离，事务执行期间不会被其他客户端命令打断

实践建议：

1. 事务不宜过大，避免长时间阻塞其他客户端
2. 对于需要回滚的场景，需在应用层实现补偿机制

3. WATCH实现乐观锁

典型应用场景：库存扣减

// Java伪代码示例
while(true) {
    jedis.watch("inventory");
    int current = Integer.parseInt(jedis.get("inventory"));
    if(current < amount) {
        jedis.unwatch();
        return false;
    }
    Transaction tx = jedis.multi();
    tx.decrBy("inventory", amount);
    List<Object> results = tx.exec();
    if(results != null) { // 执行成功
        break;
    }
    // 被其他客户端修改，重试
}

二、分布式锁实现方案

1. SETNX基础实现

# 加锁
SET lock:order123 UUID NX PX 30000
# 解锁（Lua脚本保证原子性）
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

关键参数说明：

• NX：仅当key不存在时设置
• PX：设置过期时间（毫秒）
• UUID：唯一标识，避免误删其他客户端的锁

2. RedLock算法

算法要点：

1. 部署5个独立的Redis主节点（官方建议）
2. 客户端依次尝试在每个实例上获取锁
3. 当在多数节点（≥3）上获取成功，且总耗时小于锁有效期时，认为加锁成功

实践建议：

1. 生产环境建议使用成熟的客户端库（如Redisson）
2. 锁的有效时间应大于业务执行时间+时钟漂移补偿

3. 锁续期问题解决方案

典型问题场景：

• 业务执行时间超过锁有效期
• 锁被提前释放导致多个客户端同时进入临界区

解决方案对比：

Redisson实现示例：

RLock lock = redisson.getLock("orderLock");
try {
    // 尝试加锁，最多等待100秒，上锁后30秒自动解锁
    boolean res = lock.tryLock(100, 30, TimeUnit.SECONDS);
    if (res) {
        // 业务逻辑
    }
} finally {
    lock.unlock();
}

三、最佳实践总结

1. 事务使用建议：

   • 优先使用Pipeline替代事务提升性能
   • 复杂逻辑考虑使用Lua脚本保证原子性

2. 分布式锁建议：

   • 简单场景使用SETNX+过期时间
   • 高可用场景采用RedLock算法
   • 使用成熟的客户端库而非自行实现

3. 性能优化：

   • 锁粒度尽可能小（按业务ID而非全局锁）
   • 设置合理的锁超时时间
   • 避免锁嵌套导致的死锁问题

4. 异常处理：

   • 实现锁释放的重试机制
   • 记录锁竞争日志用于性能分析
   • 添加熔断机制防止锁服务不可用影响主业务

通过合理运用Redis的事务和锁机制，可以有效地解决分布式环境下的数据一致性问题，但需要根据具体业务场景选择最适合的实现方案。