既然高并发下面操作I/O的代价很大,那我们就尽量在数据打到DB前操作好,然后再传给数据库,这样就有利于高并发而且还有一个问题,如果像秒杀,可能有多个事务同时查到后端的数据,再执行操作,这样就是不安全的,所以考虑Lua脚本,因为他是单线程,全程原子执行不会被插队还有一个问题,如果我们的数据存在多个服务器上面,若校验逻辑写在 Java 代码里每台服务器代码一旦改漏、写错就会出现漏洞,所以Lua 脚本固定存在 Redis所有服务共用同一套校验扣减逻辑规则统一不会出现各机器判断标准不一样的问题。总结:优惠券秒杀需要查询库存、逻辑判断、扣减库存三步绑定在一起不被打断普通分步查询会并发超卖Lua 脚本在 Redis 服务端原子执行整套逻辑无间隙、少网络开销完美解决优惠券超发问题。对于Lua来说前面修改的数据永久生效不会自动撤销,所以回退是我们自己手动写代码做反向操作恢复数据。但是写反向操作是不方便的所以应该先校验所有条件最后再修改数据不用回退对于如果 Lua 脚本已经执行成功但后续订单消息发送到 Kafka 失败应该怎么处理问题根源Redis Lua 操作和 Kafka 消息发送分属两个中间件无法原子执行Lua 执行成功后消息发送失败会导致库存预扣但无订单数据不一致。核心解决思路不能依赖 Lua 回滚需通过可靠消息机制保证消息一定送达搭配定时补偿兜底。主流实现方案 1基础重试发送失败多次重试仅适用于测试 / 低并发 2本地消息表推荐数据库事务落库订单 消息记录定时任务补发失败消息下游消费实现幂等防重复 3Kafka 生产者事务保证消息要么全部入队要么全部丢弃但需配合消息表处理 Redis 库存不一致问题 4TCC 分布式事务预扣库存消息发送成功确认扣减失败则调用 Lua 脚本回退库存强一致性。兜底机制定时任务核对 Redis 库存与数据库订单对库存多扣、无对应订单的数据执行补偿 Lua 脚本恢复库存彻底解决数据不一致。