RabbitMQ原生不支持可靠长延迟消息，delayed-message-exchange插件在15天级延迟下误差达数分钟；唯一稳定方案是死信+分段TTL，用消费者动态减delay_remaining并重发，误差可控且可监控。
延迟超过 1 秒的 RabbitMQ 原生能力根本不可靠
RabbitMQ 本身不支持真正意义上的长延迟消息，delayed-message-exchange 插件虽能支持毫秒到分钟级延迟（最大约 49 天），但实际在 15 天这种量级下会因内部定时器精度、内存压力和 Erlang 调度机制导致严重漂移——实测延迟误差常达数分钟甚至更久。这不是配置问题，是插件底层用 erlang:send_after/3 实现的固有限制。
关键点在于：插件把所有延迟消息都塞进一个全局定时器队列，超长延迟消息会长期占用调度资源，还可能被 GC 或节点重启清空。
用死信 + TTL 是唯一稳定方案，但必须绕过插件
不要用 delayed-message-exchange，改用原生死信机制组合多级 TTL 队列。核心思路是“分段延迟”：把 15 天（1296000 秒）拆成若干个可管理的 TTL 段，每段控制在 1 小时以内（如 3600 秒），避免单次 TTL 过大导致消息被 RabbitMQ 主动丢弃或延迟失控。
- 创建一个专用的
delay_queue_1h，设置x-message-ttl=3600000（1 小时），绑定到delay_exchange - 该队列的
x-dead-letter-exchange指向自身，x-dead-letter-routing-key保持不变，形成循环 - 消息首次入队时，携带一个自定义 header：
delay_remaining，初始值为1296000（15 天秒数） - 消费者不消费此队列，只由死信机制驱动：每次消息过期后，TTL 减去 3600，若 > 0 则重新发回本队列；否则转发至业务目标队列
注意：RabbitMQ 不允许在死信重发时动态修改 TTL，所以必须靠消费者（或独立的 delay-router 进程）来接管“减 TTL + 重发”逻辑——即启用一个轻量消费者监听 delay_queue_1h，收到死信后检查 delay_remaining，决定继续投递还是路由到最终队列。
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
Java 客户端必须手动处理死信头与重投逻辑
Spring AMQP 默认会剥离死信相关 header，比如 x-death 和原始 message properties。要拿到 delay_remaining 并做判断，必须禁用自动 ack 并显式读取 MessageProperties：
@RabbitListener(queues = "delay_queue_1h")
public void onDelayedMessage(Message message, Channel channel, @Header Map<String, Object> headers) throws IOException {
MessageProperties props = message.getMessageProperties();
Integer remaining = (Integer) props.getHeaders().get("delay_remaining");
if (remaining == null || remaining <= 0) {
// 投递到业务队列
rabbitTemplate.send("business_exchange", "routing.key", message);
return;
}
int newRemaining = remaining - 3600;
props.getHeaders().put("delay_remaining", newRemaining);
// 手动重发，不走 auto-ack
channel.basicPublish("", "delay_queue_1h", props, message.getBody());
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
}这里容易踩的坑：basicPublish 的 exchange 必须为空字符串（表示默认 direct exchange），因为目标是直接投递到队列，而非通过 exchange 路由；否则消息会丢失。
15 天延迟的实际误差主要来自消费者处理延迟，不是 RabbitMQ
整个链路中，RabbitMQ 只负责“最多 1 小时”的精确 TTL，真正的长周期控制权交给了你的 Java 消费者。这意味着：
- 如果消费者宕机或积压，某一批消息会在队列里卡住，直到它恢复 —— 这是可控的“业务暂停”，比插件随机漂移更可预期
- 务必给
delay_queue_1h设置x-max-length和x-overflow=reject-publish，防止突发流量撑爆内存 - 监控点应放在消费者处理耗时、队列堆积深度、以及
delay_remaining的最小值，而不是 RabbitMQ 自身的延迟指标
真正难的不是实现，而是让团队接受：长延迟的本质是状态机 + 定期检查，不是“设个 TTL 就完事”。任何想靠单一中间件原生能力扛住 15 天精准延迟的方案，都会在压测第三天开始掉链子。
