咨询Azure队列原最大TTL设为7天的原因及版本变更情况

嘿，作为同样常用NServiceBus、依赖事件驱动流程的开发者，我完全理解你对Azure队列7天TTL的困惑——毕竟我们的业务事件大多是需要长期留存、确保最终被处理的。来聊聊这个问题的来龙去脉：

微软当初设定这个限制，主要是基于几个核心考量：

• 存储资源优化：早期云存储的成本和容量规划更保守，7天的TTL可以自动清理那些因系统故障、逻辑错误导致的“死消息”，避免无效数据长期占用队列存储资源。
• 故障恢复预期：从大多数业务场景来看，如果一个消息7天都无法被处理，基本意味着存在严重的系统故障（比如依赖服务永久下线、业务逻辑存在无法修复的bug），而不是暂时的波动——这种情况下，消息留存更久也没有实际意义。
• 早期架构设计约束：Azure队列的底层存储架构在初期有一些设计限制，7天是当时能兼顾性能和可靠性的一个平衡值。

微软后来根据社区大量的反馈（包括类似你这种事件驱动架构的需求），在WindowsAzure.Storage 9.0版本调整了这个限制，新旧版本的行为差异非常明确：

// WindowsAzure.Storage 8.7 及更早版本
queue.AddMessage(message); // 默认TTL为7天
queue.AddMessage(message, TimeSpan.MaxValue); // 抛出异常：The argument 'timeToLive' is larger than maximum of '7.00:00:00'

// WindowsAzure.Storage 9.0 及更新版本
queue.AddMessage(message); // 默认TTL仍保持7天（兼容旧逻辑）
queue.AddMessage(message, TimeSpan.MaxValue); // 消息过期时间改为9999年12月31日，相当于无限期留存

如果你的项目还无法升级到9.0+版本，你提到的用队列触发器将消息转存到其他持久化存储（比如Azure Blob、Table Storage或者专门的事件存储）是非常实用的方案：当队列消息即将过期时，先把它备份到持久化存储，等系统恢复正常后，再从备份存储中重新投递消息，确保业务事件不会丢失。

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