Redisson是更稳妥的延迟队列方案，因其封装ZSet+List自动实现任务排序、原子转移、持久化保障与并发安全，避免手写轮询的休眠策略、幂等、丢任务等边界问题。
Redisson 是当前 Spring Boot 项目中最稳妥、开箱即用的延迟队列方案，不用自己拼 ZADD + ZRANGEBYSCORE 轮询逻辑，也不依赖 RabbitMQ 等中间件。
为什么选 Redisson 而不是原生 Redis ZSet 手写轮询？
手写基于 ZSet 的延迟队列看似轻量，但实际要处理一堆边界问题：ZRANGEBYSCORE 返回空时要不要休眠、并发消费时如何加锁、任务被重复拉取怎么幂等、Redis 故障时任务是否丢失、扫描间隔设成多少才不拖垮 Redis。而 Redisson 的 RDelayedQueue 已封装这些细节，底层自动用 ZSet 存时间戳 + List 做任务中转，还支持失败重试和监听回调。
Spring Boot 集成 Redisson 的关键三步
不是光加个依赖就能用，漏掉任意一步都会导致 RDelayedQueue 初始化失败或消费线程不启动：
- 必须引入
redisson-spring-boot-starter（版本建议3.23.0+，低版本如3.15.4在 Spring Boot 3.2+ 上有兼容问题） -
RedissonConfig中不能只配singleServerConfig，集群环境必须用clusterServersConfig，否则RDelayedQueue在节点切换时会静默丢任务 - 消费端必须显式调用
addDelayedQueue并启动监听器——它不会像@Scheduled那样自动触发，不手动 start，队列就只是个空壳
RDelayedQueue 的典型误用场景
很多人把订单 ID 直接塞进 RDelayedQueue，结果发现超时后查不到订单状态。根本原因在于：延迟队列只负责“触发时机”，不负责“业务上下文”。你得在入队时把必要字段序列化进去，比如：
OrderDelayTask task = new OrderDelayTask(orderId, userId, expireAt); delayedQueue.offer(task, 30, TimeUnit.MINUTES);
而不是只传 orderId。否则消费时反序列化出来只有 ID，再去 DB 查可能已被更新或删除，导致状态不一致。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
另一个常见坑是没设 TTL：如果 Redis 挂了 1 小时再恢复，积压的延迟任务会集中爆发。建议搭配 Redisson 的 RScheduledExecutorService 做兜底补偿，或业务层加“任务创建时间 ≤ 当前时间 + 最大容忍延迟”校验。
精度与性能的实际表现
RDelayedQueue 默认精度是秒级（由 pollInterval 控制，默认 1 秒），想提至毫秒需改配置，但代价是 Redis QPS 翻倍。实测 10 万订单/分钟场景下，设为 500ms poll interval 会使 Redis CPU 占用从 15% 升至 35%。真正需要亚秒级的场景，比如支付倒计时弹窗，应该用前端定时器 + 后端兜底，而不是强求队列精度。
另外，RDelayedQueue 的吞吐瓶颈不在 Redis，而在消费端单线程默认模型。如果业务逻辑耗时 > 100ms（比如调三次外部 HTTP），必须手动启用多线程消费，否则任务会越积越多——这不是 bug，是设计使然。
