hashedwheeltimer仅适用于单机高频低延迟可丢失的轻量调度，订单超时等强一致性场景必须依赖redis+zset延迟队列与分布式协调机制。
HashedWheelTimer 不能直接用于分布式场景
它只是单机内存级的高性能定时器，底层靠一个环形数组 + 多个工作线程轮询推进指针，所有任务都存在 JVM 堆里。一旦服务重启、扩容缩容或节点宕机，未触发的任务就彻底丢失——这对订单超时这种强一致性要求的逻辑是不可接受的。
所以，HashedWheelTimer 只适合用在「单机内高频、低延迟、可丢失」的轻量调度，比如连接空闲检测、本地缓存刷新、RPC 调用重试计时。订单支付超时必须依赖外部持久化存储 + 分布式协调机制。
真正该用的方案：Redis + 延迟队列 + 定时扫描
主流做法是把超时判定和取消动作解耦：下单时写入一条带过期时间的 Redis 记录（如 order:12345:timeout），同时投递一个延迟消息到 Kafka/RocketMQ（延迟 15 分钟），或利用 Redis 的 ZSET 存储订单 ID 和超时时间戳。后端起一个常驻消费者/定时任务，每秒拉取已到期但未处理的订单做幂等校验与取消操作。
- 用
ZSET时，score 设为订单超时时间戳（单位秒），member 为订单 ID；通过ZRANGEBYSCORE key -inf now拉取待处理列表 - 消费端必须加分布式锁（如
SET lock:timeout:scan NX PX 5000）避免多个实例重复处理同一批订单 - 查库确认订单状态是否仍为「待支付」再执行取消，防止用户中途已付款却误取消
- 取消成功后，删掉
ZSET中对应项，并发删除DEL order:12345:timeout
如果硬要用 HashedWheelTimer，只能作为兜底或辅助手段
比如在网关层用 HashedWheelTimer 启动一个本地倒计时，15 分钟后触发一次「检查订单是否已支付」的异步 HTTP 请求。但这只是优化用户体验的提示性逻辑，绝不能替代服务端真正的超时取消流程。
- 定时任务回调里必须做幂等判断：
if (order.getStatus() == "WAIT_PAY") { cancelOrder(orderId); } - 不能在回调里直接改数据库，要走完整业务服务调用链，确保事务和日志可追溯
- 注意
HashedWheelTimer的tickDuration设置太小（如 1ms）会浪费 CPU，太大（如 1s）会导致超时误差明显，建议设为 100ms 左右
容易被忽略的关键点
订单取消不是删数据，而是状态机跃迁：从 WAIT_PAY → CANCELLED，并需同步更新库存、释放优惠券、通知风控系统。整个链路中任意一环失败，都要有补偿任务或死信告警。而 HashedWheelTimer 连最基础的失败重试都没有，更别说跨服务事务了。
别被“高性能定时器”这个词带偏——性能再高，不落地、不持久、不跨节点，就只是玩具。
