如何基于恢复令牌与轮询模型扩展DocumentDB变更流读取能力？

针对你遇到的单Lambda处理瓶颈问题，完全可以通过恢复令牌+分片轮询模型扩展变更流读取能力，同时规避并行Lambda的竞态条件，核心思路是将变更流拆分为独立分片，让每个Lambda实例只负责一个分片的读取与归档，互不干扰。

具体实现方案 #

• 拆分变更流为独立分片
  DocumentDB变更流的恢复令牌包含明确的读取位置信息，你可以将整个变更流的读取范围拆分为N个逻辑分片（比如按时间区间、恢复令牌哈希值，或结合业务数据的分片键划分）。每个分片对应一段独立的变更流区间，确保每条变更记录只会属于一个分片。

• 分片级进度追踪与持久化
  为每个分片维护独立的恢复令牌，将这些信息持久化到DynamoDB中（存储结构包含：分片ID、最新恢复令牌、处理状态、上次处理时间）。Lambda实例启动时，先从DynamoDB获取自己负责分片的最新恢复令牌，以此为起点读取变更流。

• 独立轮询调度
  调整EventBridge的触发策略：不再是10分钟触发单个Lambda，而是为每个分片配置独立的触发规则（比如1分钟触发一次），或者用一个调度Lambda定期扫描所有分片的状态，仅触发存在未处理数据的分片Lambda。这样每个分片可以根据自身处理能力独立轮询，避免资源浪费。

• 原子化进度更新
  Lambda处理完一批数据并归档到S3后，必须通过原子操作更新DynamoDB中的恢复令牌（比如使用DynamoDB的UpdateItem配合条件表达式，确保只有当当前存储的令牌与Lambda本次读取的起始令牌一致时才更新），彻底杜绝多个实例同时处理同一片段的竞态问题。

峰值期动态扩展优化 #

当遇到百万级写入峰值时，可以通过以下方式进一步提升处理能力：

• 动态拆分分片：监测到某个分片处理滞后时（比如DynamoDB中记录的恢复令牌与当前最新令牌差距过大），将该分片拆分为更小的子分片，分配给新的Lambda实例处理，待峰值过后再合并分片。
• 批量读写优化：Lambda读取变更流时设置合理的MaxBatchSize，一次性读取更多记录；归档到S3时采用批量上传（比如将多条记录合并为一个文件），减少IO开销。
• 预置并发加速：对核心分片的Lambda配置预置并发，避免冷启动耗时，提升峰值期的处理速度。

流程示例 #

1. 初始化：创建N个分片，为每个分片设置初始恢复令牌（从变更流起始点或上次停止的位置拆分），存入DynamoDB。
2. 触发：EventBridge按配置频率触发各分片对应的Lambda，或调度Lambda根据分片状态触发需要处理的实例。
3. 处理：Lambda从DynamoDB获取分片的最新恢复令牌，读取对应区间的变更流数据，批量归档到S3。
4. 收尾：原子更新DynamoDB中的分片恢复令牌，记录本次处理的进度。

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