在 Spring Boot 中实现基于 Redis 的分布式任务队列，推荐优先采用 Redisson 的 RDelayedQueue 或 RScheduledExecutorService，而不是使用 @Scheduled + 分布式锁的组合方案。原因在于，前者由 Redis 统一完成任务调度，能够从根源上避免重复触发；而后者最多只能防止并发执行，无法真正解决重复调度问题。此外，还需要使用 redisson-spring-boot-starter 3.20.0 及以上版本，并正确设置线程相关参数，才能保证任务调度稳定运行。
建议直接使用 Redisson 提供的 RQueue 或 RDelayedQueue 来搭建 Redis 分布式消息队列或延迟任务队列，不要再基于 List/ZSet 自行封装实现——它具备成熟稳定的封装、线程安全机制、自动重连能力、集群支持，而且无需额外引入其他中间件。
为什么不能只靠 Spring @Scheduled + Redis 分布式锁？
很多人在做 Spring Boot 分布式定时任务时，会想到用 @Scheduled 配合 Redis 分布式锁来避免重复执行，但这种方案并不能真正解决调度一致性问题。根本原因在于，@Scheduled 的触发机制是每个应用节点各自独立计算和执行。即使加了锁，也只能防止“同一时刻并发执行”，却无法避免“多个节点重复调度”。
举个典型场景：两个节点都判断任务应在“3:00”执行，其中一个节点先抢到锁并执行成功，另一个节点在锁释放后，可能会在 3:00:01 再次执行同一个任务。特别是在服务器时钟漂移、网络抖动或 JVM GC 暂停的情况下，这类重复触发问题会更加明显。因为 @Scheduled 并不会感知其他节点的任务计划，它只依据当前节点自身的系统时钟进行调度。
因此，分布式任务调度真正要解决的核心问题，不是“谁来执行任务”，而是“到底由谁来统一决定任务什么时候触发”。Redisson 的优势就在于，它把调度时间的决策统一交给 Redis 来管理。所有节点都从同一个有序集合（ZSET）读取任务时间，自然可以实现时间点对齐，避免多节点重复触发。
必须用 redisson-spring-boot-starter 3.20.0+ 版本
如果你打算在 Spring Boot 项目中使用 Redisson 实现 Redis 延迟队列或分布式定时任务，那么 Redisson 版本选择非常关键。较低版本（例如 3.16.x）存在明显缺陷：RScheduledExecutorService 在节点宕机后无法迁移待执行任务；同时，CronSchedule.of() 对 */5 这类 cron 表达式的解析也不完整，可能导致“每 5 分钟执行一次”被错误解析成“仅在整点 :00 执行”。
redisson-spring-boot-starter版本必须 ≥ 3.20.0，若使用 Spring Boot 3.x，通常更推荐选择 3.24.x 这类较新的稳定版本- 在 YAML 配置中必须显式启用 executor 相关能力：在
redisson.config下配置threads: 16和nettyThreads: 32，如果错误地设置为 0，可能会导致schedule()调用静默失败，任务看似提交成功却不会实际执行 - 不要混用
spring-boot-starter-data-redis与原生 Redisson 客户端——因为 starter 已经包含完整集成方案，重复引入反而容易造成RedisConnection冲突，影响 Redis 任务队列和调度服务的正常运行
延迟队列必须用 RDelayedQueue，不是 RQueue + 定时轮询
在基于 Redis 实现延迟消息队列时，正确做法是直接使用 Redisson 的 RDelayedQueue，而不是通过 RQueue 配合定时轮询来手动实现。因为 RDelayedQueue 底层本身就是基于 Redis 的 ZSET，通过时间戳作为 score 存储任务到期时间，Redisson 会自动完成监听与投递，整个过程不需要应用层频繁轮询。
相比之下，如果自己手写轮询逻辑，例如每秒执行一次 ZRANGEBYSCORE 来扫描到期任务，不仅会持续占用 Redis 连接、增加 Redis 服务压力，还可能导致触发时间不够精确，在高并发场景下问题会更加突出。因此，从稳定性、性能和维护成本来看，使用 RDelayedQueue 才是更适合生产环境的 Redis 延迟队列方案。
示例代码片段：
public void addDelayTask(String payload, long delaySeconds) {
RDelayedQueue delayed = redissonClient.getDelayedQueue("order_timeout");
// 注意：offer 第二个参数是 delay，不是绝对时间戳
delayed.offer(payload, delaySeconds, TimeUnit.SECONDS);
}
- 任务对象必须能够被序列化，不能直接传 Lambda 表达式或匿名内部类，否则跨节点消费时会出现反序列化问题
- delay 的含义是“从当前时刻开始延迟多久”，而不是指定某个 cron 表达式或绝对执行时间
- 如果业务需要 cron 调度，例如“每天早上 9 点执行”，那么必须使用
RScheduledExecutorService.schedule()，不能把RDelayedQueue当作定时任务调度器来使用
RScheduledExecutorService 提交任务时容易忽略的三件事
很多开发者在使用 RScheduledExecutorService 时，会下意识把它当成 Java 本地的 ScheduledExecutorService 来理解，但两者在分布式场景下的行为差异其实非常大。实际使用中，最容易踩坑的地方主要集中在以下三点：
Runnable必须实现Serializable，并且内部引用的闭包变量也必须可序列化——因为任务会在不同节点之间传递，本地 JVM 类加载器无法跨机器恢复 Lambda 上下文- 不要依赖
System.currentTimeMillis()进行关键业务判断，不同服务器节点的系统时间可能存在数百毫秒甚至更大的偏差；更稳妥的做法是以 Redis 服务端时间（redissonClient.getServerTime()）为统一基准 - 任务执行异常默认不会自动重试：失败后通常就会被丢弃，因此如果业务要求失败补偿，应该手动封装为
Callable，在捕获异常后再调用reschedule()进行重新调度
从实践经验来看，分布式任务系统真正复杂的地方，从来都不是“如何把任务放进 Redis 队列”，而是“任务失败后状态如何回滚、重试次数和边界如何控制、超时标准如何定义”。这些问题都需要结合具体业务的幂等性设计，以及 Redis 中保存的任务元数据来统一规划，单纯依赖框架本身并不能自动帮你解决。
