使用 Amazon DocumentDB 的 Change Streams 构建事件驱动架构
介绍利用 DocumentDB 的变更数据捕获与 Lambda 触发器联动，构建实时数据同步的事件驱动架构的方法。
Change Streams 的机制
DocumentDB 的 Change Streams 是实时捕获对集合的变更（插入、更新、删除、替换）的功能。它与 MongoDB 的 Change Streams API 兼容，可以直接使用现有 MongoDB 应用程序的代码。Change Streams 以集群的变更日志（oplog）为基础，按照变更发生的顺序进行投递。每个事件包含 operationType（insert、update、delete）、documentKey（被变更文档的 ID）和 fullDocument（变更后的整个文档）。
与 Lambda 触发器的集成
将 DocumentDB 的 Change Streams 设置为 Lambda 的事件源映射后，变更事件会自动投递到 Lambda 函数。在 Lambda 函数内根据事件的类型执行相应的处理。典型的用例有 OpenSearch 的索引更新（将文档的变更立即反映到搜索索引）、ElastiCache 的缓存失效（删除被变更文档的缓存）。此外还有向 DynamoDB 的数据同步（维护针对读取优化的视图）、SNS 通知（通知符合特定条件的变更）。通过设置批处理大小和批处理窗口，将多个事件合并处理，可以提高吞吐量。
- 1. 变更记录到 oplog对集合的插入 / 更新 / 删除 / 替换会写入集群的变更日志（oplog）。Change Streams 以这个 oplog 为基础，按照变更发生的顺序进行投递。
- 2. 组装变更事件每个事件包含 operationType（insert、update、delete）、documentKey（被变更文档的 ID）和 fullDocument（变更后的整个文档）。由于与 MongoDB 的 Change Streams API 兼容，可以直接使用现有应用程序的代码。
- 3. 投递到 Lambda 的事件源映射预先设置为事件源映射后，变更事件会自动传给 Lambda 函数。用批处理大小和批处理窗口将多个事件合并，可以提高吞吐量。
- 4. 反映到下游，并用 resume token 保存重新开始的位置执行 OpenSearch 的索引更新、ElastiCache 的缓存失效、向 DynamoDB 的同步、SNS 通知等。只要保存好每个事件中包含的 resume token，在故障恢复时就可以从最后处理的事件的下一个开始重新读取（在事件源映射中是自动的）。
故障恢复与运维注意事项
Change Streams 的每个事件都包含 resume token，通过保存这个 token，可以在故障恢复时从最后处理的事件的下一个开始恢复读取。在 Lambda 的事件源映射中，resume token 的管理是自动化的。Change Streams 的变更日志最多保留 7 天，因此如果处理停止 7 天以上，旧的事件就会丢失。为应对长时间的故障，推荐采用在 Change Streams 之外定期获取完整快照的设计。启用 Change Streams 会对集群的性能产生少许影响，因此在生产环境中事先实施性能测试。
Change Streams 的费用考虑
Change Streams 本身不产生额外费用，但保留变更日志会消耗 I/O 和存储。变更日志的保留期最长为 7 天，写入多的集合的存储使用量会增加。使用 Lambda 触发器时，会产生 Lambda 调用次数和执行时间的费用。对于变更频率高的集合，调大 Lambda 的批处理大小，减少调用次数，以优化成本。选择转发到 Kinesis Data Streams 时，会追加分片小时的费用。
变更数据捕获的应用范围
Change Streams 是以数据的变更为起点联动各种处理的基础。具有代表性的是让搜索引擎的索引跟随文档变更的用途，以及使被变更数据的缓存失效、始终返回最新数据的用途。维护另一个针对读取优化的视图、把变更流向分析平台进行汇总等用法也在扩展。其优点是无需修改写入端的应用程序，就可以以松耦合的方式追加后续处理，从而提高逐步扩展系统时的灵活性。
变更事件的过滤与整形
Change Streams 使用与 MongoDB 兼容的聚合管道，可以筛选要接收的变更。可以进行只针对特定的集合或操作类型、只在关注的字段发生变化时才响应之类的控制。使用在更新事件中获取变更后整个文档的选项，就可以把完整的状态而不仅是差异传给后续处理。通过只放行需要的事件，可以降低下游的处理负载和成本。不是在接收端对全部事件进行筛选，而是在靠近源头的阶段进行筛选的设计效率高。
向 Kinesis 和 MSK 的扇出
想把变更事件送到多个处理系统时，通过 Lambda 转发到 Kinesis Data Streams 或 MSK 的架构很有效。一旦汇集到流式处理平台，多个消费者就可以各自出于不同目的消费同样的变更，并行运行搜索更新 / 分析 / 通知等。对于顺序很重要的数据，通过键的设计将其汇集到同一个分片或分区来保持顺序。可以随着需求的增长，从直接用 Lambda 处理的简单架构，发展为中间加入流式处理平台的高扩展性架构。
设计上的注意事项与最佳实践
在使用 Change Streams 的事件驱动中，掌握几条常规做法。将处理设计为幂等，使同一事件即使被重新投递也不会出现问题。使用 resume token 使处理能够从中断位置恢复，并且为应对处理停止超过变更日志保留期就会丢失旧变更这一点，另外获取快照。启用可能会影响集群的负载，因此在投入生产之前验证性能。监控延迟和失败，在积压增加时尽早应对，就可以维持高可靠性的变更联动。
总结
DocumentDB 的 Change Streams 是实时捕获文档的变更、构建事件驱动架构的功能。通过 Lambda 触发器自动处理变更，通过与 Kinesis Data Streams 的集成将数据投递到下游的分析管道。用 resume token 管理处理的恢复位置，实现高可靠性的变更数据捕获。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。