rabbitmq ttl机制支持为单条消息或整队列设置过期时间，超时后消息进入dlx或被丢弃；消息级ttl优先级高于队列级，两者共存时取较小值；队列级ttl通过x-message-ttl声明时设定，仅对新入队消息生效；消息级ttl通过expiration字符串字段设置，单位毫秒。
RabbitMQ 中的 TTL（Time To Live）机制，可以为单条消息或整个队列设置过期时间，超时后消息会被自动移入 Dead Letter Exchange（DLX），或直接丢弃（取决于配置）。关键在于：消息级 TTL 优先级高于队列级 TTL，且两者生效逻辑不同。
为整个队列设置 TTL（队列级别）
队列级别的 TTL 是指该队列中所有未被消费的消息，从入队起最多存活指定毫秒数。一旦超过该时间，消息会变成“就绪态”但无法被消费，最终被 RabbitMQ 清理（若配置了 DLX，则进入死信队列）。
创建队列时通过 arguments 参数设置：x-message-ttl（单位：毫秒）：
- 仅对新入队的消息生效，已存在的消息不受影响
- 必须在声明队列时设定，运行时无法修改（需删除重建）
- 适用于统一控制消息生命周期的场景，例如缓存同步任务最多保留 5 分钟
示例（Spring AMQP）：
@Bean
public Queue ttlQueue() {
return QueueBuilder.durable("order.ttl.queue")
.withArgument("x-message-ttl", 300_000) // 5 分钟
.withArgument("x-dead-letter-exchange", "dlx.exchange")
.withArgument("x-dead-letter-routing-key", "dlq.routing.key")
.build();
}
为单条消息设置 TTL（消息级别）
消息级 TTL 在发送消息时通过 MessageProperties 设置 expiration 字段（字符串格式，单位毫秒），优先级高于队列 TTL。注意：这个值是字符串，如 "60000"，不是数字。
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 只对当前消息生效，灵活适配不同业务时效要求（如支付消息 2 分钟，通知消息 1 小时）
- 若同时设了队列 TTL 和消息 TTL，取更小的那个值
- 消息在内存或磁盘中等待投递期间开始计时；若一直未入队（如路由失败），TTL 不启动
示例（Spring AMQP 发送端）：
MessageProperties props = new MessageProperties();
props.setExpiration("120000"); // 2 分钟
Message message = new Message("pay-order-123".getBytes(), props);
rabbitTemplate.send("exchange.name", "routing.key", message);
TTL 生效的前提与常见误区
TTL 不是“定时器”，它依赖 RabbitMQ 的惰性检查机制：只有当消息处于“就绪”状态（Ready）且到达过期时间时，才会被移除或转为死信。以下情况会影响实际效果：
- 消息处于 Unacked 状态（消费者已取走但未确认）时，TTL 暂停计时
- 队列为空或消息长期无人消费，RabbitMQ 不会主动扫描过期，需有新消息入队或队列被访问才触发清理
- 未配置 DLX 时，过期消息会被静默丢弃，日志中可能只显示 “Discarding expired message”
- 使用延迟插件（rabbitmq_delayed_message_exchange）是更可靠的延时方案，TTL 不适合精确延时
验证 TTL 是否生效
可通过 RabbitMQ 管理界面查看队列中消息的 Age 列，或使用命令行工具观察：
rabbitmqctl list_queues name messages_ready messages_unacknowledged
配合监控插件（如 Prometheus + rabbitmq_exporter）可跟踪 queue_messages_expired_total 指标。若发现消息长时间未过期，先确认是否设置了 DLX 并绑定正确死信队列，再检查消息是否卡在 Unacked 状态。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
