hashedwheeltimer 不能用于分布式订单超时处理，因其是单机内存结构、无持久化、无跨节点协同，重启或扩缩容即丢失任务，无法保障状态机跃迁的可靠性。
HashedWheelTimer 不能用于分布式系统中的订单支付超时与状态轮询——它连“分布式”三个字的边都沾不上。
HashedWheelTimer 是单机内存结构，重启即丢任务
所有任务都存在 JVM 堆里，靠一个环形数组 + 单线程指针轮询推进。一旦服务重启、扩容缩容或节点宕机，HashedWheelTimer 中未触发的任务就彻底消失。订单超时不是“提醒一下就算了”，而是必须执行的状态机跃迁（WAIT_PAY → CANCELLED），丢一次就是库存锁死、优惠券误发、风控漏判。
- 你往 A 节点的
HashedWheelTimer里加了一个 30 分钟后取消订单的任务，B 节点完全不知道这个订单的存在 - 哪怕只部署两个实例，超时取消成功率直接腰斩；上 Kubernetes 自动扩缩容？任务丢失成常态
- 没有持久化、没有重试、没有幂等校验入口，
cancel()回调里连事务边界都划不清
它唯一能用的场景是单机轻量级超时控制
比如网关层对单次 HTTP 请求设置 5 秒超时，或本地缓存项 10 分钟后自动失效。这类逻辑不要求强一致性、不跨服务、失败可接受。
- 用
HashedWheelTimer.newTimeout()启动一个倒计时，到期后发个异步HTTP GET /order/{id}/status检查是否已支付 - 这只是用户体验优化（如前端提示“即将超时”），绝不能替代服务端真正的取消流程
- 别在回调里直接调
orderService.cancel()—— 必须走完整 RPC 或消息链路，确保日志、事务、补偿可追溯
真正支撑百万级订单超时的方案只有两个主流选择
生产环境跑得最稳的是：Redis ZSet + 多消费者定时扫描，或者 RocketMQ/Kafka 的延迟消息能力。前者运维简单、精度可控、天然高可用；后者经亿级验证但需中间件依赖。
-
ZSet方案：写入用zadd("order:delay", expireTime, orderId)，每秒用zrangebyscore拉取已到期的orderId，再做幂等校验与状态更新 - 扫描频率设为 1 秒，配合
(status, create_time)复合索引和分表策略，可把数据库压力压到最低 - 如果硬要用时间轮思想，应选嵌入式分层时间轮（如 RocketMQ 的
ScheduledMessage），而非 Netty 的HashedWheelTimer
最容易被忽略的一点：订单超时不是“到了时间就删数据”，而是要同步释放库存、作废优惠券、通知风控、记录审计日志。这些动作天然跨服务、跨存储、需事务保障——而 HashedWheelTimer 连最基础的失败重试都没有。
