Redis 事务详解

Redis 支持事务，但其实现方式与传统关系型数据库（如 MySQL）的事务机制有所不同。Redis 的事务通过 命令队列 实现，保证一系列命令的 顺序执行 和 隔离性，但 不支持回滚（Rollback）。以下是 Redis 事务的核心实现原理和操作步骤：

1. Redis 事务的核心命令

• MULTI：标记事务开始，后续命令会按顺序存入队列。
• EXEC：执行事务队列中的所有命令。
• DISCARD：取消事务，清空队列中的命令。
• WATCH：监控一个或多个键，若这些键在事务执行前被修改，则事务自动取消（乐观锁机制）。
• UNWATCH：取消对所有键的监控。

2. 事务执行流程

示例场景：用户转账（从 A 账户转 100 元到 B 账户）

# 监控账户 A 和 B 的余额
WATCH balance:A balance:B

# 开启事务
MULTI

# 事务操作：A 扣款 100，B 加款 100
DECRBY balance:A 100
INCRBY balance:B 100

# 提交事务
EXEC

步骤解析：

1. 监控键值（WATCH）：

   • 使用 WATCH 监听 balance:A 和 balance:B，若其他客户端在事务执行前修改了这些键，事务将失败。
   • 类似乐观锁：检查数据是否被改动，若改动则放弃执行。

2. 开启事务（MULTI）：

   • 后续命令（如 DECRBY、INCRBY）会被放入队列，而非立即执行。

3. 执行事务（EXEC）：

   • Redis 依次执行队列中的命令，所有命令按顺序原子性执行（不会被其他客户端命令打断）。
   • 若 WATCH 的键被修改，EXEC 返回 nil，表示事务失败。

4. 失败处理：

   • 事务失败后，需重新 WATCH 并重试整个逻辑（类似“CAS”操作）。

3. Redis 事务的特性

（1）原子性（Atomicity）：

• 执行原子性：EXEC 触发时，所有命令按顺序一次性执行，不会被中断。
• 无回滚机制：若某条命令执行失败（如对字符串执行 INCR），后续命令仍会继续执行，不会回滚。

（2）隔离性（Isolation）：

• 事务中的命令在 EXEC 执行前不会被其他客户端看到，保证隔离性。

（3）错误处理：

• 语法错误（如命令不存在）：在命令入队时直接报错，事务无法提交。

  MULTI
  SET key1 value1
  INVALID_CMD  # 语法错误，事务直接失败
  EXEC         # 返回错误，事务不执行
  

• 运行时错误（如类型不匹配）：错误命令执行失败，其他命令继续执行。

  MULTI
  SET key1 "abc"
  INCR key1     # 对字符串执行 INCR，运行时失败
  EXEC          # 返回错误数组：[OK, (error) ERR value is not an integer]
  

4. 事务的局限性

（1）无回滚机制：

• Redis 设计哲学是“简单高效”，错误通常由编程错误导致，应在开发阶段解决，而非依赖运行时回滚。

（2）不满足 ACID 的持久性：

• 若未开启持久化（RDB/AOF），事务执行后若宕机，数据会丢失。

（3）性能影响：

• 长事务会阻塞其他客户端请求（Redis 单线程模型）。

5. 替代方案：Lua 脚本

对于需要原子性且复杂逻辑的场景，Redis 推荐使用 Lua 脚本：

• 原子性：Lua 脚本在执行时是独占的，不会被其他命令打断。
• 灵活性：支持条件判断、循环等复杂逻辑。
• 示例：

  -- 检查余额是否充足，再执行转账
  local balanceA = redis.call('GET', KEYS[1])
  if tonumber(balanceA) >= 100 then
      redis.call('DECRBY', KEYS[1], 100)
      redis.call('INCRBY', KEYS[2], 100)
      return "SUCCESS"
  else
      return "INSUFFICIENT_BALANCE"
  end
  

  通过 EVAL 命令执行脚本：

  EVAL "脚本内容" 2 balance:A balance:B
  

6. 使用场景建议

总结

Redis 的事务通过 命令队列 和 乐观锁（WATCH） 实现，适用于简单批量操作，但缺乏回滚机制。对于复杂场景，优先选择 Lua 脚本 或结合 WATCH 重试策略。理解其特性后，可灵活应用于缓存更新、计数器调整、分布式锁等场景。