Redis事务详解：从基础到进阶的完整指南

一、Redis事务的核心机制

Redis事务通过MULTI、EXEC、DISCARD和WATCH四个命令实现，其核心设计理念是”原子性操作序列”。与关系型数据库ACID事务不同，Redis事务更侧重于批量命令的原子执行而非隔离性。

1.1 事务的基本流程

MULTI          # 开启事务
SET key1 "A"   # 命令入队
INCR key2      # 命令入队
EXEC           # 执行事务

当执行MULTI后，所有后续命令不会立即执行，而是被放入队列。EXEC命令会原子性地执行队列中的所有命令，返回结果数组。

1.2 原子性保证

Redis事务的原子性体现在：要么全部执行，要么全部不执行。但需注意：

• 执行过程中单个命令失败不会回滚（如对非数字值执行INCR）
• 事务执行期间新到达的命令会立即执行，不会被纳入当前事务

二、WATCH机制详解

WATCH命令为Redis提供了乐观锁能力，是解决并发修改问题的关键工具。

2.1 基本用法

WATCH balance  # 监视key
val = GET balance
MULTI
SET balance val-100
EXEC           # 如果balance被修改则返回nil

当EXEC被调用时，Redis会检查所有被WATCH的key是否被修改。若被修改则拒绝执行事务，返回nil。

2.2 实际应用场景

库存扣减示例：

# 线程1
WATCH product:1:stock
current = GET product:1:stock
if current > 0:
    MULTI
    DECR product:1:stock
    EXEC  # 若返回nil表示库存已被其他线程修改
else:
    UNWATCH
    # 处理库存不足

2.3 注意事项

• 每次EXEC后会自动UNWATCH所有key
• 长时间持有WATCH可能导致并发性能下降
• 推荐配合Lua脚本实现更复杂的条件判断

三、错误处理与边界情况

3.1 执行阶段错误

当事务中存在语法错误时（如命令不存在）：

MULTI
SET key "value"
NONEXISTENT_CMD  # 语法错误
EXEC
# 返回错误：(error) ERR unknown command
# 但SET命令仍会被执行

3.2 运行时错误

对非数字值执行INCR等类型错误：

MULTI
SET age "twenty"
INCR age  # 执行时失败
EXEC
# 返回：[OK, (error) ERR value is not an integer...]
# 事务仍会继续执行后续命令

3.3 最佳实践建议

1. 关键操作前先验证数据类型
2. 复杂逻辑建议使用Lua脚本
3. 对一致性要求高的场景，考虑应用层重试机制

四、Redis事务的典型应用场景

4.1 计数器批量更新

MULTI
INCR user:123:score
INCRBY user:123:level 2
EXPIRE user:123:temp 3600
EXEC

4.2 队列消息处理

# 生产者
MULTI
RPUSH queue "task1"
HSET task:1:status "pending"
EXEC
# 消费者
WATCH queue
task = LPOP queue
if task:
    MULTI
    HSET task:1:status "processing"
    EXEC
    # 处理任务...
else:
    UNWATCH

4.3 分布式锁实现

# 获取锁
SET lock:resource "123" NX PX 30000
if reply == "OK":
    # 执行业务逻辑
    MULTI
    # ...操作数据...
    DEL lock:resource
    EXEC

五、进阶技巧与优化

5.1 事务批处理优化

对于大量命令，建议分批处理：

# Python示例
def batch_process(pipe, commands, batch_size=100):
    for i in range(0, len(commands), batch_size):
        batch = commands[i:i+batch_size]
        pipe.multi()
        for cmd, args in batch:
            getattr(pipe, cmd)(*args)
        pipe.execute()

5.2 与Lua脚本对比

特性	事务(MULTI/EXEC)	Lua脚本
原子性	命令序列原子	完整脚本原子
错误处理	部分失败	可自定义
性能	较高	最高
复杂度	低	高

选择建议：简单批量操作使用事务，复杂逻辑使用Lua脚本。

5.3 集群环境下的注意事项

1. 所有key必须位于同一个hash slot（可通过hash tag解决）

   MULTI
   SET {user:123}.name "Alice"
   SET {user:123}.age 30
   EXEC

2. 跨slot事务会导致整个事务失败

六、常见问题解决方案

6.1 事务执行超时处理

try:
    r.execute()
except redis.exceptions.TimeoutError:
    # 检查是否为WATCH导致的失败
    if r.pipeline().watch(...).execute()[0] is None:
        # 处理竞争条件
    else:
        # 网络或服务器问题

6.2 事务与持久化的关系

• AOF持久化会记录完整的事务命令序列
• RDB快照不保证事务的中间状态
• 建议对关键数据同时开启AOF和RDB

6.3 监控事务性能

INFO stats
# 关注：
# - instantaneous_ops_per_sec
# - keyspace_hits/misses
# - rejected_connections (可能因事务过大)

七、总结与建议

1. 适用场景选择：

   • 简单批量操作：MULTI/EXEC
   • 复杂条件逻辑：Lua脚本
   • 高并发修改：WATCH+重试机制

2. 性能优化建议：

   • 避免在事务中执行耗时命令
   • 合理设置批处理大小（通常50-500条命令）
   • 监控exec_abort_errors指标

3. 替代方案考虑：

   • Redis模块（如RediSearch）的原子操作
   • 客户端分片时的分布式事务方案

通过深入理解Redis事务机制，开发者可以更高效地设计高并发场景下的数据一致性方案。在实际应用中，建议结合具体业务场景进行压力测试和优化调整。