不推荐用 redis pub/sub 实现订单超时取消，因其无延时能力、无消息持久化、无法保证可靠性与原子性，且不能联动数据库状态校验。
不推荐用 Redis Pub/Sub 实现订单超时取消，因为它根本做不到“超时取消”——PUBLISH 是即时广播，没有延迟能力，也不保存消息，更无法感知订单状态是否真的被处理。
Pub/Sub 无法延迟投递，一发就丢
订单超时取消本质是“在指定时间点触发动作”，但 PUBSUB 没有时间维度：调用 PUBLISH 的瞬间，消息就推给所有在线订阅者；如果此时没人监听，或者消费者刚断连，消息直接蒸发。你不能往消息体里塞个 {"delay": 1800000} 就指望它等 30 分钟再发——Redis 不解析、不等待、不存储。
- 常见错误：用客户端定时器模拟延时，比如收到消息后
Thread.sleep(1800000)，但 JVM 重启或 GC 暂停会导致 sleep 中断，订单永远不被取消 - 硬编码延时值（如固定 sleep 30 秒）会导致多实例竞争时重复取消，或因网络抖动漏触发
-
PSUBSCRIBE通配符订阅也一样只收实时流，不缓存、不回溯
消息零持久化，断连即丢，无任何补救机制
订单超时是强业务语义，要求“只要没支付，就必须关单”。但 PUBSUB 连最基本的可靠性保障都没有：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 订阅者进程崩溃、网络抖动、Redis 主从切换期间，所有
PUBLISH全部丢失，且重连后不会补推 -
PUBLISH返回值是当前在线订阅者数量（如(integer) 0），不是投递成功标志——返回 0 可能只是订阅命令还没抵达服务端，不代表消息失败；返回 3 也不代表三个消费者都成功处理了订单取消逻辑 - 集群环境下，同一频道的消息可能被路由到不同节点，甚至出现状态乱序（如先收到
"status":"closed"，后收不到"status":"created"）
无法与订单状态联动，缺乏原子性校验
真正的订单取消必须查库确认“此刻是否仍为待支付”，否则会重复关单或误关已支付订单。但 PUBSUB 是纯通道，不提供任何上下文：
- 消息里只能传
order_id，后续查 DB、更新状态、释放库存全靠业务代码，而这些操作失败时，PUBSUB不会重试、不记录失败、不进死信队列 -
PUBLISH和 DB 更新无法构成原子操作：你不能用MULTI/EXEC把扣库存和发通知包在一起，因为PUBLISH不支持事务 - 没有消费位点（offset）或消息 ID，无法判断某条取消指令是否已被执行，也无法做幂等去重
真正难的不是怎么写 onMessage()，而是意识到：只要订单取消这件事不能丢、不能乱序、不能重复、不能脱离 DB 状态独立成立，你就已经越过了 PUBSUB 的能力边界。这时候该立刻切到 ZSET + ZRANGEBYSCORE 轮询争抢，或者上 RocketMQ 延时消息——而不是给 PUBSUB 加各种 try-catch 和重连兜底。
