RabbitMQ消息最大TTL值确认及超期处理方案咨询

一、确切的最大TTL值 #

RabbitMQ的消息TTL上限并非固定数值，而是动态计算的结果，核心源于它内部存储过期时间的机制：

• RabbitMQ会将你设置的TTL（毫秒）转换为微秒，加上当前时间的微秒数（从1970-01-01 UTC起算），得到消息的绝对过期时间。
• 这个绝对过期时间用64位有符号整数存储，最大值为2^63 - 1微秒，对应UTC时间2262-04-11。
• 因此，最大TTL的计算公式为：(2^63 - 1 - 当前时间微秒数) / 1000（转换为毫秒）。

你测试得到的约288094644805毫秒（对应到2031年底）完全符合这个逻辑——随着时间推移，当前时间微秒数不断增加，最大TTL会逐年减小。

补充背景：早期RabbitMQ版本确实用32位整数存储TTL（上限为2^32-1毫秒，约49天），但后续版本改为基于绝对过期时间的64位存储，官方文档未明确说明这个转换细节，才出现了“取消限制但实际仍有上限”的认知差。

二、超过上限时不设置Expiration的方案可行性 #

完全可行，且是适配需求的最优方案：

• 在RabbitMQ中，不设置Expiration属性的消息默认永不过期，正好匹配你框架中“永不过期”的设计目标（原本设置9999-12-31的过期时间戳完全没必要，反而触发了数值超限报错）。
• 处理逻辑可调整为：计算TTL后，若结果超过动态上限（或直接判断ExpiryTimestampUtc对应的TTL是否超出合理超大值），则跳过Expiration字段的设置；否则正常赋值TTL字符串。

调整后的示例代码参考：

var timeSpan = message.ExpiryTimestampUtc - _clock.UtcNow;
if (timeSpan.TotalMilliseconds > 0 && timeSpan.TotalMilliseconds <= (long.MaxValue / 1000 * 1000))
{
    properties.Expiration = ((long)timeSpan.TotalMilliseconds).ToString();
}
// 否则不设置Expiration，消息默认永不过期

内容的提问来源于stack exchange，提问作者GrahamB