1. Redis事务的本质与特性
Redis事务与传统关系型数据库事务有着本质区别。它更像是一个命令打包执行的机制，通过MULTI/EXEC指令将多个操作组合在一起顺序执行。我在实际项目中常用它来处理需要原子性执行的批量操作场景。
Redis事务的核心特性是：
- 顺序性：所有命令按入队顺序执行
- 隔离性：执行过程中不会被其他客户端命令打断
- 非原子性：某个命令失败不会导致前面已执行命令回滚
- 无隔离级别：没有传统数据库的读已提交、可重复读等概念
重要提示：Redis事务不能保证所有命令都成功执行，这与MySQL等关系型数据库的事务行为有本质区别。如果业务需要严格的原子性，需要配合Lua脚本实现。
2. Redis事务的工作机制详解
2.1 事务执行三阶段
- 开启阶段：客户端发送MULTI命令，服务器返回OK表示进入事务模式
- 命令入队：后续命令不会立即执行，而是存入队列，返回QUEUED响应
- 执行阶段：客户端发送EXEC命令，服务器顺序执行队列中的所有命令
bash复制127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 "value1"
QUEUED
127.0.0.1:6379> INCR key2
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (integer) 1
2.2 事务中的错误处理
Redis事务可能遇到两种错误：
- 入队错误：命令语法错误，整个事务会被拒绝执行
- 执行错误：运行时错误（如对字符串执行INCR），只有错误命令失败，其他命令正常执行
bash复制# 入队错误示例
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 "value1"
QUEUED
127.0.0.1:6379> INCR key1 # 语法错误
(error) ERR wrong number of arguments for 'incr' command
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
# 执行错误示例
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 "value1"
QUEUED
127.0.0.1:6379> INCR key1 # 运行时类型错误
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (error) ERR value is not an integer or out of range
3. 高级事务控制技巧
3.1 WATCH命令实现乐观锁
WATCH机制允许客户端监视一个或多个key，如果在EXEC执行前这些key被其他客户端修改，则当前客户端的事务会被放弃。
bash复制127.0.0.1:6379> WATCH balance
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECRBY balance 100
QUEUED
127.0.0.1:6379> INCRBY debt 100
QUEUED
127.0.0.1:6379> EXEC # 如果balance在WATCH后发生变化，这里会返回nil
实战经验：WATCH需要配合重试机制使用。我在电商系统中处理库存扣减时，通常会设置最多3次重试，超过次数则返回"请求过于频繁"提示。
3.2 DISCARD命令的使用场景
DISCARD用于取消事务，清空命令队列并退出事务状态。典型使用场景包括：
- 业务逻辑校验失败需要中止事务
- 监控到被WATCH的key已发生变化
- 客户端需要主动放弃当前事务
bash复制127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 "value1"
QUEUED
127.0.0.1:6379> DISCARD
OK
4. 事务性能优化实践
4.1 管道化(pipeline)事务
通过管道将MULTI和多个命令一次性发送，减少网络往返时间(RTT)：
python复制import redis
r = redis.Redis()
pipe = r.pipeline()
pipe.multi()
pipe.set('key1', 'value1')
pipe.incr('key2')
pipe.execute()
4.2 事务大小控制
根据Redis官方建议：
- 单个事务不宜包含过多命令（建议不超过100个）
- 大事务会阻塞其他客户端请求
- 可以考虑拆分为多个小事务执行
5. 事务与Lua脚本的对比选择
| 特性 | 事务 | Lua脚本 |
|---|---|---|
| 原子性 | 不保证 | 保证 |
| 复杂度 | 简单 | 需要编写脚本 |
| 性能影响 | 中等 | 较低（单次执行） |
| 错误处理 | 部分失败 | 全部成功或失败 |
| 适用场景 | 简单批量操作 | 复杂业务逻辑 |
实际项目中的选择建议：
- 简单数据操作：使用事务
- 需要严格原子性：使用Lua脚本
- 复杂业务逻辑：优先考虑Lua脚本
- 高并发场景：Lua脚本性能更好
6. 典型业务场景实现
6.1 库存扣减方案
lua复制-- 使用Lua脚本实现原子性库存扣减
local stock = tonumber(redis.call('GET', KEYS[1]))
if stock >= tonumber(ARGV[1]) then
return redis.call('DECRBY', KEYS[1], ARGV[1])
else
return -1
end
6.2 秒杀系统实现要点
- 使用WATCH监控库存key
- 校验库存是否充足
- 创建用户购买记录
- 扣减库存
- 处理失败重试逻辑
避坑指南：在秒杀场景下，单纯使用Redis事务可能导致超卖。建议配合Lua脚本或分布式锁实现。
7. 生产环境注意事项
-
监控指标：
- 事务执行耗时
- 事务失败率
- WATCH冲突率
-
常见问题排查：
- 事务执行返回nil：检查是否WATCH的key被修改
- 部分命令失败：检查命令语法和参数类型
- 性能下降：检查是否包含大事务或复杂命令
-
配置建议：
redis复制# 限制单个客户端输出缓冲区大小（防止大事务占用过多内存） client-output-buffer-limit normal 256mb 64mb 60
8. 事务最佳实践总结
经过多个项目的实践验证，我总结出以下经验：
- 明确业务是否需要真正的原子性，不需要时优先使用事务
- 涉及多个key的关联操作使用WATCH+MULTI
- 高并发修改场景考虑Lua脚本替代
- 事务中避免执行耗时命令（如KEYS、大集合操作）
- 监控事务执行时间和失败率，设置合理告警阈值
在最近的一个支付系统中，我们最终采用Lua脚本处理资金转账，而用事务处理日志记录等非核心业务，取得了很好的平衡效果。