用Redis处理那些老是过期的订单，聊聊实际遇到的问题和解决办法

用Redis处理那些老是过期的订单,聊聊实际遇到的问题和解决办法

在实际项目里,尤其是电商、秒杀这些场景，我们经常用Redis的过期键（expire）功能来处理未支付的订单，简单说，就是用户下单后，在Redis里存个订单数据，设个15分钟或30分钟的过期时间，时间一到，键自动删除，就代表订单超时关闭了，想法很美好，但真用起来，坑是一个接一个。

第一个大问题：订单状态同步的坑。 这是最头疼的，Redis里的键过期是自动的，但我们的核心订单数据还在MySQL里，Redis的键一没，只是触发了一个“事件”，并不代表MySQL里的订单状态自动更新了，如果更新MySQL状态的那段代码（比如发个消息通知，或者跑个定时Job）没跟上，或者出错了，就会出现“Redis里订单已经过期消失了，但MySQL里订单还是‘待支付’”的混乱状态，用户可能看到订单还能支付，或者系统库存没被正确释放。《Redis实战》这本书里也提醒过，键过期是一种弱通知，不能当作强一致性的保证。

第二个问题：“订单消失”了，然后呢？ Redis键过期后，我们得知道它过期了，并且去执行关单、还库存这些后续动作，早期我们依赖Redis的“键空间通知”功能（就是配置notify-keyspace-events Ex），但这个功能有个致命缺点：它不是可靠的，如果监听通知的客户端服务当时刚好重启了，或者网络闪断，那条过期通知就彻底丢了，再也没人知道这个订单该被处理了，导致订单“幽灵般”地卡在那里，我们吃过亏，有一次服务部署，短暂重启了消费者，结果第二天运营就报来说有一批订单超时未关闭，库存乱了。

第三个问题：时间不准和集中过期。 如果你把大量订单的过期时间都设成一样的（比如整点30分），就可能遇到Redis那个著名的“集中过期”问题，快到那个时间点时，Redis会集中清理大量过期键，可能导致CPU突然飙升，出现短暂的延迟毛刺，影响其他操作，在Redis集群环境下，过期时间的精度和同步也可能有微小误差，虽然对15分钟的订单来说影响不大，但也是个需要注意的点。

我们后来摸索的解决办法，核心就一条：别把宝全押在Redis的过期事件上，要把它当作一个辅助和优化手段。

1. “双轮驱动”查状态。 这是最根本的，我们依然用Redis过期作为第一道快速防线，但一定会有一个独立的定时任务（比如每分钟跑一次），去扫描MySQL里“待支付”且创建时间超过阈值的订单，这个定时任务才是最终保证，确保哪怕Redis的通知全丢了，订单最终也能被正确关闭，Redis过期是用来减轻这个定时任务压力的，比如先处理掉大部分最近过期的订单。

2. 给通知加个“保险”。 对于键空间通知，我们不再直接处理关键逻辑，而是用它来触发一个更可靠的消息，一收到某个订单ID的过期通知，就立刻把这个ID塞到一个持久化的消息队列（如RocketMQ）或者一个专门的Redis备份列表里，由另一个健壮的服务从队列里消费，执行关单，这样即使通知丢了，还有定时任务兜底；如果处理程序挂了，消息还在队列里，不会丢。

3. 设计上留后路。 关键业务逻辑，比如归还库存，不能只由过期事件触发，关单的代码逻辑必须是幂等的（无论执行多少次效果都一样），并且每次关单前，都要再次去MySQL核对订单的最新状态，这样，即使因为各种原因重复执行了关单操作，也不会多扣一次库存或者多退一次款。

4. 分散过期时间。 在设置Redis键的过期时间时，可以加一个小的随机数（比如30分钟 ± 1分钟），让过期时间稍微分散开，避免集中过期造成的压力。

我们的经验是： Redis的过期特性很好用，能快速释放内存并给出一个“提醒”，但它不是一个可靠的消息系统，处理像订单这样重要的业务数据，一定要在数据库层有基于状态的、周期性的核对机制，用Redis来扛瞬时高并发和快速失效，用定时任务和可靠消息队列来保证最终的业务状态一致，两者结合，才算稳妥，这就像设了个闹钟提醒你该做事了，但你不能完全依赖闹钟，自己还得有个日程表，时不时看一眼，这才是最靠谱的。