Redis中多条命令的原子及事务属性

Redis中多条命令的原子性与事务特性剖析

1. 代码结构解读

以下展示了在Spring环境下利用RedisTemplate进行事务操作的代码示例：

redisTemplate.execute(new SessionCallback<Object>() {
    @Override
    public <String, Long> Object execute(RedisOperations<String, Long> operations) {
        operations.multi();  // 开启事务
        operations.opsForValue().increment((String) key);  // 操作一：自增
        operations.expire((String) key, 1, TimeUnit.HOURS);  // 操作二：设置过期时间
        operations.exec();  // 提交事务
        return null;
    }
});

2. 原子性保障机制

在Redis事务里：

• ✅ MULTI/EXEC为原子操作：
  Redis会把multi与exec之间的所有命令暂存进队列，随后一次性原子化执行这些命令。

• ✅ 命令顺序保障：
  命令会依照increment→expire的顺序执行，不会被其他操作打断。

3. 高并发下的表现

4. 潜在风险点

graph TD A[客户端发起事务] --> B{Redis接收MULTI} B --> C[缓存命令队列] C --> D{执行EXEC} D
-->|成功| E[所有命令生效] D -->|失败| F[所有命令丢弃]

1. 事务中断风险：

   • Redis宕机或网络断开时事务未提交
   • 内存不足导致命令执行失败

   • 键过期重置问题：

     // 每次自增都会将过期时间重置为1小时
     // 频繁访问时可能让key永不过期

5. 优化方案

(1) 用Lua脚本确保绝对原子性

Lua脚本内容如下：

-- KEYS[1]=key, ARGV[1]=expire_seconds
local count = redis.call('INCR', KEYS[1])
if count == 1 then
    redis.call('EXPIRE', KEYS[1], ARGV[1])
end
return count

在Spring中的实现代码：

String script = 
    "local c = redis.call('INCR', KEYS[1])\n" +
    "if c == 1 then\n" +
    "   redis.call('EXPIRE', KEYS[1], ARGV[1])\n" +
    "end\n" +
    "return c";

RedisScript<Long> redisScript = new DefaultRedisScript<>(script, Long.class);
Long result = redisTemplate.execute(
    redisScript, 
    Collections.singletonList(key), 
    TimeUnit.HOURS.toSeconds(1)  // 转换为秒
);

(2) 用SET + NX优化（首次设置过期时间）

// 原子操作：不存在时初始化并设置过期时间
Boolean setIfAbsent = redisTemplate.opsForValue().setIfAbsent(
    key, "0", 1, TimeUnit.HOURS
);

// 后续只需自增
if (setIfAbsent != null && setIfAbsent) {
    redisTemplate.opsForValue().increment(key);
} else {
    // 已有值时直接自增（不重置过期时间）
    redisTemplate.opsForValue().increment(key);
}

6. 各方案比较

7. 结论

1. 原始代码在正常状态下是原子的：
   在Redis正常运行且无外部故障时，increment和expire会作为一个整体执行。

2. 高并发下可能失效的场景：

   • Redis服务崩溃/重启
   • 客户端与Redis网络断开
   • 内存不足导致命令执行失败
   • 命令语法错误（如key类型错误）

   • 生产环境建议：
     ✅ 优先使用Lua脚本：

   • 绝对原子性保障

   • 避免过期时间被重置
   • 减少单次网络往返延迟

在千万级QPS的生产环境中，Lua脚本方案的性能比事务高30%~50%，且能规避事务中断引发的数据不一致问题。