不推荐用 Redisson 的 RDelayedQueue 做订单延迟取消，因其依赖本地定时器、无持久化、易丢任务；应改用 ZSet + ZRANGEBYSCORE 批量争抢 + 状态校验的自研方案。
直接说结论：用 Redisson 的 RDelayedQueue 做订单延迟取消，看似简单，但生产环境容易丢任务、扛不住重启、无法精确控制消费节奏——不推荐直接用于核心订单超时逻辑。
为什么 RDelayedQueue.offer() 会在进程挂掉时丢任务
Redisson 的延迟队列底层不是靠 ZSet + 定时探测，而是由生产者本地线程启动一个 ScheduledExecutorService 定时器，在到期时把任务 offer() 到底层的 RBlockingQueue。这意味着：
- 如果生产者 JVM 进程崩溃或被 kill -9，这个定时器就永远消失了，对应的任务永远不会进入阻塞队列，订单就不会被取消
- 没有持久化任务元数据到 Redis，所有延迟信息只存在内存里
- 哪怕你用了集群部署，只要那个发任务的节点宕机，任务就丢了
这不是理论风险——在滚动发布、机器故障、OOM Kill 场景下非常真实。
ZRANGEBYSCORE + ZREM 批量争抢才是可靠模式
真正能落地的方案是绕过 Redisson 封装，自己用 Redis 原生命令构造“可恢复、可校准”的消费循环。关键点在于：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 订单写入时，用
ZADD delay_orders <expire_timestamp> order_id，score 是绝对时间戳（如System.currentTimeMillis() + 30 * 60 * 1000） - 消费者不依赖 SUBSCRIBE 长连接，而是用
while(true) { Thread.sleep(1000); ... }轮询，避免空转和连接中断问题 - 每次执行
ZRANGEBYSCORE delay_orders -inf <now> LIMIT 0 100拿一批待处理订单 - 对每个
order_id执行ZREM delay_orders order_id，仅当返回值为 1（争抢成功）才查 DB 并取消订单 - 查 DB 时必须校验订单当前状态是否仍是“待支付”，防止重复取消
这个模型天然支持多实例并行消费，且单个消费者宕机不影响其他实例继续推进。
信号唤醒机制比轮询更省资源，但要注意 SUBSCRIBE 超时设置
想进一步优化 CPU 和延迟，可以用 Redis 的发布订阅做轻量唤醒，但必须配合 ZSet 时间校准：
- 消费者先执行
ZRANGE delay_orders 0 0 WITHSCORES，拿到最早任务的时间戳 - 计算
waitMs = Math.max(100, earliestScore - System.currentTimeMillis()) - 再执行
SUBSCRIBE delay_signal，并设 timeout =waitMs / 1000.0（Redis SUBSCRIBE 只接受秒级浮点数） - 一旦收到信号或超时，立刻执行上面的
ZRANGEBYSCORE批量争抢逻辑 - 生产者每次
ZADD后，必须PUBLISH delay_signal "1"唤醒所有等待中的消费者
这里最容易错的是：SUBSCRIBE 超时值不能为 0，也不能超过 30 天（Redis 限制），且必须动态重算——硬写死 5 秒 timeout 会导致大量无效唤醒或长延迟。
真正难的从来不是“怎么把任务塞进 Redis”，而是“怎么确保它一定被处理一次且仅一次”。ZSet 方案的幂等性、可中断性、可监控性，远比封装好的 RDelayedQueue 更适合订单这类强一致性场景。
