Brighter项目DynamoDB Outbox性能优化解析

背景与问题分析

在分布式系统架构中，消息中间件扮演着关键角色。Brighter作为一个流行的.NET消息总线库，提供了Outbox模式实现，其中DynamoDB作为持久化存储选项之一。然而，在实际使用中发现，当采用DynamoDB作为Outbox存储时，消息扫描器（sweeper）存在严重的性能问题和成本隐患。

核心问题在于DynamoDB的查询机制：当扫描器运行时，它会查询Outstanding索引，使用创建时间作为过滤条件，并附加一个服务端过滤表达式来排除已分发的消息。这种设计导致了"全表扫描"效应——即使大多数消息已被处理，系统仍需为这些无效读取支付费用。

技术细节剖析

以一个典型生产环境为例：

• 每分钟2000条消息
• 扫描器每5秒运行一次
• 归档器处理1小时前的消息

这种情况下，每次扫描操作都会读取约12万条消息，导致极高的DynamoDB读取成本，使得该方案在实际生产环境中几乎不可用。

优化方案设计

解决方案的核心在于利用DynamoDB的稀疏索引特性。传统实现中，索引包含所有消息记录，而优化后的设计将确保索引仅包含真正待处理的消息。具体技术实现包括：

1. 新增OutstandingCreatedTime数值属性，仅当消息待分发时设置该值
2. 将此属性作为Outstanding索引的排序键
3. 消息处理流程重构：
   • 发布时设置CreatedTime和OutstandingCreatedTime
   • 扫描器查询时仅获取有OutstandingCreatedTime的记录
   • 分发成功后移除OutstandingCreatedTime属性，自动将其移出索引

版本兼容性处理

考虑到这是破坏性变更，Brighter团队采取了灵活的版本策略：

• v10版本：直接采用新设计，要求用户创建新表
• v9版本：通过SparseOutstandingIndex配置项提供渐进式升级路径，默认保持旧行为，允许用户主动启用优化

架构影响与最佳实践

这一优化不仅降低了成本，还带来了显著的性能提升。对于架构师而言，需要注意：

1. 新表设计无法通过GSI修改实现，必须新建
2. 迁移策略应考虑消息的连续性要求
3. 生产环境应先验证新设计的查询性能

该优化体现了Brighter团队对云原生成本控制的重视，为大规模消息处理场景提供了更经济的解决方案。