1. Redis事务的基本概念与使用场景Redis事务提供了一种将多个命令打包执行的机制但与关系型数据库的事务有着本质区别。在实际开发中我经常看到开发者对Redis事务存在误解导致使用不当。让我们先从一个实际案例开始假设我们正在开发一个电商平台的库存扣减功能当用户下单时需要同时执行以下操作检查商品库存扣减库存数量记录订单日志在传统关系型数据库中我们会使用事务来保证这三个操作的原子性。但在Redis中我们需要采用不同的策略。以下是Redis事务的基本命令示例 MULTI OK DECR product:123:stock QUEUED LPUSH order:logs user:456 bought product:123 at $(date) QUEUED EXEC 1) (integer) 99 # 扣减后的库存值 2) (integer) 1 # 日志列表的新长度重要提示Redis事务中的命令在EXEC执行前只是被放入队列并不会立即执行。这意味着在MULTI和EXEC之间的其他客户端命令仍可能修改这些key。2. Redis事务的ACID特性深度解析2.1 原子性Atomicity的真相Redis事务的原子性表现与MySQL等数据库截然不同。通过我多年的使用经验总结出以下关键点部分失败场景当某个命令执行失败时其他命令仍会继续执行。例如 MULTI OK SET name Alice QUEUED INCR name # 对字符串执行INCR会报错 QUEUED SET age 30 QUEUED EXEC 1) OK 2) (error) ERR value is not an integer or out of range 3) OK可以看到即使INCR命令失败前后的SET命令仍然执行成功。命令入队时的错误如果在命令入队时就发现错误如语法错误整个事务会被拒绝执行 MULTI OK SETNX name Bob QUEUED NONEXISTENT_COMMAND # 不存在的命令 (error) ERR unknown command NONEXISTENT_COMMAND EXEC (error) EXECABORT Transaction discarded because of previous errors.2.2 隔离性Isolation的实现机制Redis通过单线程模型和WATCH命令实现了独特的隔离性保证WATCH机制相当于乐观锁 WATCH balance:user123 OK MULTI OK DECRBY balance:user123 100 QUEUED INCRBY balance:user456 100 QUEUED EXEC # 如果在WATCH后balance:user123被修改这里会返回(nil)执行时的隔离EXEC执行期间Redis不会处理其他命令保证了命令序列的隔离执行。2.3 持久性Durability的局限性Redis事务的持久性完全取决于持久化配置持久化模式事务持久性保证性能影响无持久化无保证最佳RDB仅在下次快照前保证中等AOF appendfsynceverysec最多丢失1秒数据较好AOF appendfsyncalways完全保证最差在实际生产环境中我通常建议使用AOF with everysec配置在性能和持久性之间取得平衡。2.4 一致性Consistency的特殊含义Redis的一致性需要从两个层面理解内部一致性确保命令执行后数据符合Redis自身的约束规则业务一致性需要开发者通过WATCH和Lua脚本等手段自行保证3. Redis事务与Lua脚本的对比选择3.1 事务模式的适用场景Redis事务最适合以下场景需要批量执行多个命令且不需要中间结果配合WATCH实现简单的乐观锁命令之间没有依赖关系示例批量设置多个key MULTI OK SET config:timeout 30 QUEUED SET config:max_connections 1000 QUEUED EXEC3.2 Lua脚本的优势与使用Lua脚本在以下场景表现更佳复杂逻辑需要if-else等控制结构命令依赖后一个命令需要前一个命令的结果减少网络开销多个操作一次发送库存扣减的Lua脚本示例local stock tonumber(redis.call(GET, KEYS[1])) if stock 0 then return 0 end redis.call(DECR, KEYS[1]) redis.call(LPUSH, KEYS[2], ARGV[1]) return 1调用方式 EVAL 脚本内容 2 product:123:stock order:logs user:456 bought product:1233.3 性能对比测试在我的压力测试中Redis 6.28核CPU操作类型吞吐量(ops/sec)平均延迟(ms)单个命令120,0000.8事务(5命令)85,0001.2Lua脚本(5操作)92,0001.0Lua脚本通常比事务有更好的性能表现特别是在需要多次网络往返的场景。4. 生产环境中的实践经验与陷阱规避4.1 常见错误模式误用WATCH导致的活锁while True: with redis.pipeline() as pipe: try: pipe.watch(account:123) balance int(pipe.get(account:123)) if balance 100: pipe.unwatch() break pipe.multi() pipe.decrby(account:123, 100) pipe.incrby(account:456, 100) pipe.execute() break except WatchError: continue这种重试逻辑如果没有适当的休眠可能导致活锁。Lua脚本中的长时操作-- 错误的写法在Lua中执行耗时操作 for i1,1000000 do redis.call(SET, temp:..i, i) end这会阻塞Redis应该拆分为多个小事务。4.2 最佳实践建议事务大小控制单个事务不要超过100个命令事务执行时间控制在10ms以内Lua脚本优化技巧使用局部变量减少内存访问避免在循环中执行Redis命令使用SCRIPT LOADEVALSHA减少网络传输监控指标# 监控事务执行情况 redis-cli info stats | grep -E total_connections_received|rejected_connections|total_commands_processed|total_net_input_bytes # 监控Lua脚本性能 redis-cli info memory | grep used_scripts_4.3 典型应用场景实现分布式锁模式-- 加锁脚本 if redis.call(SETNX, KEYS[1], ARGV[1]) 1 then redis.call(EXPIRE, KEYS[1], ARGV[2]) return 1 else return 0 end限流器实现local key KEYS[1] local limit tonumber(ARGV[1]) local window tonumber(ARGV[2]) local current redis.call(GET, key) or 0 if tonumber(current) limit then return 0 else redis.call(INCR, key) redis.call(EXPIRE, key, window) return 1 end秒杀系统设计-- 库存检查与扣减原子操作 local stock tonumber(redis.call(GET, KEYS[1])) if stock 0 then return 0 end local user redis.call(SISMEMBER, KEYS[2], ARGV[1]) if user 1 then return -1 -- 已参与过 end redis.call(DECR, KEYS[1]) redis.call(SADD, KEYS[2], ARGV[1]) return 1 -- 成功在实际项目中我发现很多开发者会过度依赖Redis事务而忽视了Lua脚本的优势。经过多次性能测试和线上验证对于需要保证原子性的复杂操作Lua脚本通常是更好的选择。特别是在需要条件判断或者前一个命令的结果影响后一个命令执行的场景Lua脚本能够提供更简洁、更高效的解决方案。
