1. 为什么用 Redis zset 做延时队列不是 RabbitMQ 也不是 Quartz“Redis zset 延时队列简单实现Java”——这行标题我第一次在某技术社区看到时心里其实咯噔了一下。不是因为难而是因为它太“轻”了没有服务注册、不依赖调度中心、不引入新中间件就靠 Redis 自带的有序集合zset几行 Java 代码就能把一个带精确触发时间的任务塞进去、取出来、执行掉。它解决的不是高并发秒杀那种万亿级调度问题而是我们每天都在写的那些“5分钟后发提醒”“30秒后自动关闭订单”“2小时后清理临时缓存”类需求。这类任务量不大单机每秒百级、精度要求不高秒级即可、失败容忍度高重试一次就行、又不想为几行逻辑搭一套完整的定时任务系统。我做过三个不同规模的项目都踩过定时任务的坑最早用 Quartz配置复杂集群模式下 trigger 状态同步经常出错一次数据库连接池耗尽导致所有定时任务集体失联后来切到 XXL-JOB部署运维成本上来了光是调度中心执行器双节点就占掉两台云服务器再后来在一个 IoT 设备心跳管理模块里我们只用 Redis zset Spring Boot 的Scheduled每秒扫一次结果发现90% 的延时任务在 1 秒内完成平均延迟 327msP99 不到 800ms而整套方案零新增依赖、零额外部署、零运维告警。它不是替代专业调度系统的方案而是在“够用”和“过度设计”之间划出的一条清晰分界线。核心关键词“Redis zset”“延时队列”“Java”已经点明了技术栈边界不用 Netty 手写 TCP不碰 Kafka 分区策略不研究 Nacos 配置推送机制。就是利用 zset 的天然特性——成员member唯一、分数score可排序、支持按分数范围查询——把“执行时间”作为 score“任务内容”作为 member让 Redis 帮你记住“谁该什么时候醒”。Java 层只做三件事序列化任务、插入 zset、轮询拉取到期任务并触发回调。没有消息确认、没有死信队列、没有重试策略封装——这些全是你自己根据业务决定要不要加的“可选配件”。适合谁看如果你正在写一个内部工具后台需要给用户发个“操作成功5秒后跳转”的前端提示如果你在开发一个电商后台要实现“下单后 30 分钟未支付自动关单”如果你在做设备管理平台得保证“设备离线 10 分钟后标记为异常”——那你根本不需要打开 RocketMQ 文档直接往下看。但如果你的场景是“每秒 5 万笔订单超时检测且必须严格保序、零丢失”那请合上这篇去读《Kafka 权威指南》第三章。这不是能力高低的问题而是工具和场景的匹配度问题——就像你不会用菜刀去开挖掘机。2. 核心设计思路为什么是 zset而不是 list、hash 或 stream2.1 四种 Redis 数据结构的横向对比很多人第一反应是“延时队列那不就是先进先出嘛用 list 不就行了”——这是最典型的认知偏差。我们来拆解延时队列的本质需求✅按时间排序任务必须按触发时间先后顺序处理不能乱序✅高效范围查询能快速找出所有“当前已到期”的任务score ≤ now✅原子性移除取出任务的同时必须从队列中删除避免重复消费✅成员唯一性同一个任务不能重复加入比如同一订单两次关单指令❌不需要消息持久化保障Redis 本身是内存数据库我们默认接受少量数据丢失可通过 AOFRDB 补救❌不需要消费者组语义通常一个应用实例自己消费自己的任务不跨 JVM 协作。基于这六条我们把 Redis 主流数据结构拉出来对号入座数据结构是否支持按时间排序是否支持范围查询≤now是否支持原子性移除成员是否唯一是否适合本场景原因说明List❌只能头/尾插入❌无索引需遍历✅LPOP/RPOP❌可重复元素❌插入位置无法控制无法保证“早到期的在前面”遍历查到期任务 O(n) 太慢Hash❌无序键值对❌不支持范围查询✅HDEL✅key 唯一❌本质是字典连基本排序能力都没有完全不满足核心需求Stream✅ID 天然递增✅XRANGE支持 ID 范围✅XACKXGROUP✅ID 唯一⚠️可用但过重功能完整但需要维护 consumer group、ack 机制对简单场景属于“杀鸡用牛刀”且 Java 客户端 API 较复杂ZSet✅score 排序✅ZRANGEBYSCORE✅ZREMRANGEBYSCORE✅member 唯一✅最优解四项核心能力全部原生支持API 极简性能极高单命令完成“查删”提示有人会问“为什么不用 Sorted Set 的ZREVRANGEBYSCORE倒序查”——因为我们要的是“已到期”的任务即 score ≤ 当前时间戳正向查更自然倒序查适用于“最近 N 个任务”这种场景与延时逻辑无关。2.2 zset 的 score 设计用毫秒时间戳而不是相对秒数关键细节来了score 存什么常见错误做法是存“30”“60”这种相对秒数然后每次轮询时用System.currentTimeMillis() / 1000 - score 0判断。这会导致两个严重问题精度丢失System.currentTimeMillis()返回毫秒除以 1000 变成秒等于主动丢弃毫秒级精度对于要求“500ms 后触发”的场景直接失效时钟漂移风险如果 JVM 时钟被 NTP 同步回拨比如服务器时间校准相对秒数计算会出现负值或逻辑错乱。正确做法是score 直接存绝对毫秒时间戳如System.currentTimeMillis() 30_000L表示 30 秒后。这样判断逻辑变成score System.currentTimeMillis()纯数值比较无精度损失即使服务器时间回拨只要回拨幅度小于任务最大延时比如你最长只设 24 小时就不会误触发Redis 内部用 double 存储 score毫秒级时间戳约 13 位数字完全在 double 精度范围内可精确表示到 2^53 ≈ 9e15远大于 1e13。我实测过在一台 CPU 3.2GHz 的虚拟机上插入 10 万个 score 为System.currentTimeMillis() rand(1000, 3600000)的 zset 成员ZRANGEBYSCORE key -inf 1717023456789查询耗时稳定在 0.8~1.2msQPS 轻松破万。这个性能足够支撑中小规模业务。2.3 为什么不用 Lua 脚本封装“查删”Java 层自己控制更灵活Redis 官方推荐用 Lua 脚本保证“查询到期任务”和“删除已取任务”两个操作的原子性。但我在三个项目中都选择了分开调用ZRANGEBYSCORE和ZREMRANGEBYSCORE原因很实在Lua 脚本调试成本高Java 里写一段 Lua 字符串出错了只能看 Redis 日志没法断点、没法单元测试业务需要差异化处理有时查到任务后要先检查业务状态比如订单是否已支付再决定删不删有时要记录执行日志后再删Lua 里写这些业务逻辑等于把 Java 代码硬塞进 Redis违背分层原则网络往返开销可控两次命令的 RTT 在局域网内通常 0.5ms而任务执行本身往往要 10ms这点延迟可忽略失败重试更明确如果ZREMRANGEBYSCORE失败比如网络闪断Java 层可以捕获异常记录告警甚至走降级逻辑比如改用内存队列暂存Lua 里一旦出错整个脚本回滚你连“到底哪一步失败了”都不知道。当然如果你的场景是“必须强一致性且任务逻辑极其简单”Lua 是更优解。但对绝大多数 Java 工程师来说用熟悉的语言写熟悉的逻辑比在 Redis 里写“另一种语言”更可靠、更易维护。3. Java 实现详解从零开始搭建可落地的延时队列3.1 任务模型定义轻量、可序列化、带元信息我们不搞复杂的泛型抽象就定义一个极简的DelayTask类import java.io.Serializable; import java.time.Instant; public class DelayTask implements Serializable { private static final long serialVersionUID 1L; // 任务唯一标识用于幂等控制比如订单ID private String taskId; // 任务类型便于路由到不同处理器 private String taskType; // 具体执行参数JSON 字符串避免复杂对象序列化兼容性问题 private String payload; // 创建时间用于监控和排查 private long createTime; // 期望执行时间戳毫秒即 zset 的 score private long executeTime; // 构造方法省略提供 builder 模式 public static DelayTaskBuilder builder() { return new DelayTaskBuilder(); } public static class DelayTaskBuilder { private DelayTask task new DelayTask(); public DelayTaskBuilder taskId(String taskId) { task.taskId taskId; return this; } public DelayTaskBuilder taskType(String taskType) { task.taskType taskType; return this; } public DelayTaskBuilder payload(String payload) { task.payload payload; return this; } public DelayTaskBuilder delaySeconds(long seconds) { task.executeTime System.currentTimeMillis() seconds * 1000; return this; } public DelayTaskBuilder delayMillis(long millis) { task.executeTime System.currentTimeMillis() millis; return this; } public DelayTask build() { task.createTime System.currentTimeMillis(); return task; } } }注意payload字段存 JSON 字符串而非MapString, Object是因为 Jackson 序列化Map时可能包含LinkedHashMap这种非标准类型反序列化时容易报ClassNotFoundException而 JSON 字符串是纯文本任何版本的 Jackson 都能解析。我吃过这个亏——某次升级 Spring Boot 版本后旧任务在新服务里反序列化失败日志里全是Cannot construct instance of java.util.LinkedHashMap。3.2 Redis 操作封装Jedis 还是 Lettuce选后者虽然 Jedis 更轻量但 Lettuce 是 Netty 驱动的异步客户端连接复用率高天然支持 Redis Cluster且StatefulRedisConnection是线程安全的无需像 Jedis 那样手动管理连接池。我们用 Lettuce!-- Maven 依赖 -- dependency groupIdio.lettuce/groupId artifactIdlettuce-core/artifactId version6.3.1.RELEASE/version /dependency初始化连接工厂Spring Boot 场景Configuration public class RedisConfig { Bean public RedisClient redisClient(Value(${redis.host:localhost}) String host, Value(${redis.port:6379}) int port) { RedisURI uri RedisURI.Builder.redis(host, port).build(); return RedisClient.create(uri); } Bean Primary public StatefulRedisConnectionString, String redisConnection(RedisClient redisClient) { return redisClient.connect(); } }核心操作类DelayQueueServiceService public class DelayQueueService { private static final String DELAY_QUEUE_KEY delay:queue; private final StatefulRedisConnectionString, String connection; private final ObjectMapper objectMapper; // 用于 JSON 序列化 public DelayQueueService(StatefulRedisConnectionString, String connection, ObjectMapper objectMapper) { this.connection connection; this.objectMapper objectMapper; } /** * 添加延时任务到队列 * param task 任务对象 * return true 表示添加成功member 唯一若已存在则不更新 score */ public boolean addTask(DelayTask task) { try { String json objectMapper.writeValueAsString(task); // ZADD key NX score memberNX 表示仅当 member 不存在时才添加避免覆盖已有任务 Long result connection.sync().zadd(DELAY_QUEUE_KEY, ZAddArgs.Builder.nx(), task.getExecuteTime(), json); return result ! null result 1L; } catch (Exception e) { log.error(Failed to add delay task: {}, task.getTaskId(), e); return false; } } /** * 拉取并删除所有已到期任务线程安全建议单线程调用 * param batchSize 单次最多拉取数量避免一次处理过多阻塞主线程 * return 到期任务列表 */ public ListDelayTask pollExpiredTasks(int batchSize) { try { long now System.currentTimeMillis(); // ZRANGEBYSCORE key -inf now获取所有 score now 的任务 ListString jsonList connection.sync().zrangebyscore(DELAY_QUEUE_KEY, Range.Bounded.of(Boundary.unbounded(), Boundary.inclusive(now)), Limit.create().count(batchSize)); if (jsonList.isEmpty()) { return Collections.emptyList(); } // 反序列化 ListDelayTask tasks new ArrayList(jsonList.size()); for (String json : jsonList) { tasks.add(objectMapper.readValue(json, DelayTask.class)); } // ZREMRANGEBYSCORE key -inf now原子性删除已拉取的任务 Long removedCount connection.sync().zremrangebyscore(DELAY_QUEUE_KEY, Range.Bounded.of(Boundary.unbounded(), Boundary.inclusive(now))); log.debug(Polled {} expired tasks, removed {} from zset, tasks.size(), removedCount); return tasks; } catch (Exception e) { log.error(Failed to poll expired tasks, e); return Collections.emptyList(); } } }关键点解释ZADD ... NX确保同一个taskId的任务不会重复加入避免“同一订单被关单两次”ZRANGEBYSCORE ... -inf now-inf表示负无穷Boundary.inclusive(now)表示包含now这个时间点保证“刚好到期”的任务不被漏掉ZREMRANGEBYSCORE删除范围与查询范围完全一致保证查到的一定被删不会重复消费batchSize控制单次处理量防止某次拉取 10 万条任务导致线程卡死建议设为 100~1000。3.3 轮询调度器用 Spring 的Scheduled还是自研线程池Scheduled(fixedDelay 1000)最简单但有隐患如果某次任务处理耗时 2 秒下一次调度会在 1 秒后准时触发导致两个调度线程并发执行zset 操作可能冲突。更稳妥的做法是用单线程ScheduledExecutorService确保“上一次执行完才开始下一次”Component public class DelayQueueScheduler { private static final Logger log LoggerFactory.getLogger(DelayQueueScheduler.class); private final DelayQueueService queueService; private final TaskExecutor taskExecutor; // 业务执行线程池非调度线程池 private final ScheduledExecutorService scheduler; public DelayQueueScheduler(DelayQueueService queueService, TaskExecutor taskExecutor) { this.queueService queueService; this.taskExecutor taskExecutor; // 单线程调度器确保串行 this.scheduler Executors.newSingleThreadScheduledExecutor( r - new Thread(r, delay-queue-scheduler)); } PostConstruct public void start() { // 延迟 1 秒启动避免应用初始化未完成时就开始调度 scheduler.scheduleWithFixedDelay(this::doPoll, 1, 1, TimeUnit.SECONDS); log.info(Delay queue scheduler started with 1s interval); } private void doPoll() { try { ListDelayTask tasks queueService.pollExpiredTasks(100); if (tasks.isEmpty()) { return; } log.debug(Found {} expired tasks to process, tasks.size()); for (DelayTask task : tasks) { // 提交到业务线程池异步执行避免阻塞调度线程 taskExecutor.execute(() - executeTask(task)); } } catch (Exception e) { log.error(Error in delay queue polling loop, e); } } private void executeTask(DelayTask task) { try { switch (task.getTaskType()) { case close-order: closeOrder(task); break; case send-notice: sendNotice(task); break; default: log.warn(Unknown task type: {}, task.getTaskType()); } } catch (Exception e) { log.error(Failed to execute task: {}, task.getTaskId(), e); // 此处可加入失败重试逻辑比如重新入队延后 5 秒再试 } } private void closeOrder(DelayTask task) { // 示例调用订单服务关闭订单 String orderId task.getPayload(); // payload 是 JSON这里简化为字符串 log.info(Closing order: {}, orderId); // OrderService.close(orderId); } private void sendNotice(DelayTask task) { // 示例发送站内信 MapString, String params objectMapper.readValue(task.getPayload(), Map.class); log.info(Sending notice to user: {}, params.get(userId)); // NoticeService.send(params); } PreDestroy public void stop() { scheduler.shutdown(); try { if (!scheduler.awaitTermination(5, TimeUnit.SECONDS)) { scheduler.shutdownNow(); } } catch (InterruptedException e) { scheduler.shutdownNow(); Thread.currentThread().interrupt(); } log.info(Delay queue scheduler stopped); } }实操心得我在线上环境把fixedDelay从 1 秒改成 500 毫秒后观察到 Redis CPU 使用率从 3% 升到 12%但任务平均延迟从 420ms 降到 280ms。所以“轮询间隔”不是越小越好要结合业务容忍延迟和 Redis 负载来压测确定。我们最终定为 800ms在延迟和负载间取得平衡。3.4 幂等性与失败重试别让“简单”变成“脆弱”zset 本身保证了任务不重复加入NX参数但任务执行过程可能失败。我们必须设计兜底机制幂等性设计每个任务taskId必须全局唯一如订单ID时间戳业务处理器在执行前先查数据库确认“该订单是否已关闭”已关闭则直接返回失败重试executeTask方法里捕获异常后不要静默吞掉而是重新构造一个DelayTaskdelaySeconds(5)后再次入队最大重试次数在DelayTask类里加int retryCount字段每次重试1超过 3 次写入死信队列可存到另一个 zset 或 MySQL 表人工干预入口提供一个管理后台接口能按taskId查询任务状态、手动触发、或强制删除。这部分代码不贴全但强调一个关键点重试任务的executeTime必须是System.currentTimeMillis() delay而不是沿用原来的executeTime。否则会变成“永远在 5 分钟前那个时间点重试”陷入无限循环。4. 实战避坑指南那些文档里不会写的血泪教训4.1 Redis 内存暴涨zset 没清理干净是主因上线第三天Redis 内存从 2GB 涨到 12GBINFO memory显示used_memory_human:12.10GKEYS delay:*查出 800 万个 key。排查发现pollExpiredTasks方法里ZREMRANGEBYSCORE删除失败了但日志被catch吞掉了导致到期任务堆积。根因是ZREMRANGEBYSCORE命令在 Redis Cluster 模式下如果 key 的 slot 不在当前节点会返回MOVED错误而 Lettuce 默认不自动重定向需要配置ClusterClientOptions。解决方案// 初始化 RedisClient 时启用自动重定向 ClientOptions options ClientOptions.builder() .autoReconnect(true) .pingBeforeActivateConnection(true) .timeoutOptions(TimeoutOptions.builder() .fixedTimeout(Duration.ofSeconds(3)) .build()) .build(); RedisClient client RedisClient.create(RedisURI.create(redis://host:6379)); client.setOptions(options);提示线上务必开启timeoutOptions否则网络抖动时ZREMRANGEBYSCORE可能卡住线程导致调度器假死。我们曾因此出现过连续 2 小时未处理任何任务的情况监控告警都没触发——因为线程没抛异常只是 hang 住了。4.2 时钟不同步导致任务“穿越”用 NTP 监控双保险某次服务器维护后运维手动把时间调快了 5 分钟结果所有executeTime在这 5 分钟内的任务瞬间全部触发订单关单服务被打爆。根源在于executeTime是绝对时间戳依赖本地时钟。应对策略强制 NTP 同步所有应用服务器必须配置systemd-timesyncd或chrony并设置makestep 1.0 -1允许开机时大步长校准增加时钟偏移监控在调度器里每分钟执行System.currentTimeMillis() - System.nanoTime() / 1_000_000如果差值突变 1000ms立即告警并暂停调度业务层兜底在executeTask开头加判断if (task.getExecuteTime() System.currentTimeMillis() - 60_000) { log.warn(Task {} is too old, skip); return; }过滤掉明显异常的“穿越”任务。4.3 为什么不用 Redis 的EXPIRE因为语义不匹配有人提议“Redis key 不是自带过期时间吗给每个任务建个 key设EXPIRE不就行了”——这犯了概念混淆错误。EXPIRE是 key 级别的生命周期管理到期后 key 被自动删除但你无法知道“哪个 key 到期了”。延时队列的核心诉求是“主动拉取到期任务”而不是“被动等待 key 消失”。如果用EXPIRE你得维护一个全局 map 记录所有任务 key再用KEYS delay:*扫描这 O(n) 复杂度在 10 万任务时直接拖垮 Redis。zset 的优势在于ZRANGEBYSCORE是 O(log(N)M) 复杂度N 是总任务数M 是命中数即使有百万任务查 100 个到期任务也只要几毫秒。4.4 生产环境必须做的五件事我把线上踩过的坑总结成五条硬性规范现在所有用这个方案的项目都强制执行Key 命名空间隔离delay:queue:{env}:{service}比如delay:queue:prod:order-service避免测试环境任务误触发生产逻辑zset 设置最大长度用ZCARD定期检查如果ZCARD delay:queue 100000触发告警并自动清理最老的 1000 条ZREMRANGEBYRANK key 0 999防止内存无限增长任务 payload 大小限制单个任务 JSON 不得超过 10KB超限直接拒绝避免大任务拖慢整个轮询周期调度日志必打每次pollExpiredTasks的size()、ZCARD结果、耗时全部打 INFO 日志方便容量规划提供紧急熔断开关通过 Apollo/Nacos 配置delay.queue.enabledtrue运行时可一键关闭调度避免故障扩散。最后分享一个真实案例某次大促前压测我们发现 1000 QPS 下ZREMRANGEBYSCORE平均耗时飙升到 15ms原因是 zset 中有大量已过期但未被清理的“僵尸任务”。加了第 2 条规范后问题消失。这印证了一点再简单的方案不加监控和治理都会在流量高峰时露出獠牙。5. 可扩展方向从“简单实现”到“生产就绪”5.1 支持优先级score 不只是时间戳zset 的 score 是 double我们可以把“时间戳”和“优先级”编码在一起。比如用score executeTime * 1000 priority其中priority是 0~999 的整数0 最高。这样既能按时间排序又能保证同时间任务按优先级处理。解码时executeTime (long) (score / 1000)priority (int) (score % 1000)。我们用这个方案实现了“VIP 用户订单关单优先于普通用户”。5.2 分片处理单 zset 瓶颈拆成多个 key当单个 zset 成员数超 100 万ZRANGEBYSCORE性能会下降。这时可以把一个逻辑队列拆成多个物理 key比如delay:queue:00~delay:queue:07共 8 个任务taskId.hashCode() % 8决定存哪个。轮询时 8 个 key 并行扫描吞吐量翻倍。注意ZREMRANGEBYSCORE仍需逐个 key 执行但整体耗时大幅降低。5.3 与 Spring Event 整合让业务代码更干净定义一个DelayTaskEvent事件DelayQueueScheduler在executeTask后发布事件业务模块监听对应taskType的事件Component public class OrderCloseEventListener { EventListener public void handleOrderCloseEvent(DelayTaskEvent event) { if (close-order.equals(event.getTask().getTaskType())) { // 处理关单逻辑完全解耦 } } }这样业务代码不再感知“延时队列”这个基础设施只关心“我收到了一个事件”。5.4 监控大盘五个核心指标必须可视化我们在 Grafana 上配置了以下看板队列积压量ZCARD delay:queue阈值 10000 告警平均延迟System.currentTimeMillis() - task.getExecuteTime()的 P95阈值 2000ms 告警调度成功率pollExpiredTasks返回非空列表的次数 / 总调度次数低于 95% 告警任务执行失败率executeTask抛异常次数 / 总执行次数高于 1% 告警Redis 命令耗时ZADD/ZRANGEBYSCORE/ZREMRANGEBYSCORE的 P99超过 10ms 告警。这些指标让我们在用户投诉前就发现问题。比如某次ZREMRANGEBYSCOREP99 突然升到 80ms查日志发现是 Redis 主从同步延迟立刻切到从节点读——原来ZRANGEBYSCORE是读命令可以走从节点而ZREMRANGEBYSCORE是写命令必须走主节点我们之前没做读写分离。我个人在实际使用中发现这套方案最大的价值不是技术多炫酷而是把一个原本需要 3 天评估、2 天对接、1 天上线的“定时任务需求”压缩到 2 小时内搞定。它不解决所有问题但精准地解决了“80% 的延时场景”中最痛的那个点快、轻、稳。当你下次再看到“XX 分钟后执行”的需求不妨先打开 Redis CLI敲一行ZADD delay:queue 1717023456789 {taskId:abc}感受一下什么叫“简单但有效”。