为何选Kafka Connect MongoDB源连接器而非直接使用Change Streams

针对高吞吐量、明确要求系统可扩展性的业务场景，优先选择「MongoDB Kafka源连接器投递变更到Kafka Topic，再消费Topic消息」的方案，两类方案的核心差异和选型依据如下：

两种方案的核心特性对比 #

• 直接消费MongoDB Change Streams
  本质是消费端直连MongoDB节点，基于oplog拉取变更事件，优势是链路短、不需要额外部署中间件，轻量场景下搭建速度快。但天生不适合高吞吐、多消费端的场景，核心问题包括：
  • 所有消费压力直接打在MongoDB上，每新增一个消费端就要额外占用MongoDB连接和计算资源，高吞吐场景下很容易抢占主业务的读写资源，严重时会影响主库稳定性
  • 没有内置消息缓存层，消费端宕机后如果resume token过期，要么丢失变更数据，要么需要全量回扫oplog拖垮数据库；流量突增消费端处理不及时时，也没有缓冲空间，直接导致变更延迟飙升
  • 扩展成本极高，新增消费逻辑就要新接入一套Change Stream任务，MongoDB侧负载会随消费端数量线性上涨，根本无法支撑多业务线同时订阅变更的需求
  • 需要自行实现消息重试、幂等保障、消息回溯、分区消费等通用流处理能力，开发和长期维护成本非常高
• MongoDB Kafka源连接器 + Kafka消费方案
  这套架构将变更拉取逻辑统一收敛到Kafka Connect集群，拉取到的变更先持久化写入Kafka多副本Topic，下游所有消费端都从Kafka读取数据，完全适配高吞吐、强可扩展的要求，核心优势：
  • MongoDB侧负载完全可控：不管下游新增多少消费组、多少业务方使用这份变更数据，始终只有Kafka Connect的少量任务连接MongoDB拉取oplog，不会因为消费端扩容影响主库稳定性
  • 高吞吐能力充足：Kafka本身就是为高吞吐日志流场景设计的，单集群可以轻松支撑十万级QPS的消息读写，配合Topic分区并行消费能力，大流量下只要新增消费实例就能线性提升消费处理能力，不需要调整MongoDB侧任何配置
  • 扩展灵活性极强：新业务要接入变更数据只要申请对应Topic的读权限即可，不需要单独申请MongoDB权限、也不用重新配置Change Stream任务；Kafka Connect本身也支持水平扩缩容，拉取变更的能力可以随集群节点数线性提升
  • 可靠性有兜底：变更数据写入Kafka后会做多副本持久化，支持按偏移量、时间戳任意回溯消费，消费端出问题可以随时重放数据，不会丢数，也不需要回查MongoDB增加额外负载
  • 生态复用性高：后续如果要做变更实时数仓同步、异构索引更新、缓存失效等其他逻辑，都可以直接复用同一份Kafka Topic数据，不用重复开发数据拉取、格式转换的工作

选型判断边界 #

只有同时满足以下所有条件，才考虑选择直连Change Streams的方案：

• 变更峰值QPS长期低于1万，未来1年内没有明确的流量翻倍增长预期
• 消费端数量不超过2个，没有多团队/多业务共用变更数据的规划
• 团队没有现成的Kafka集群运维能力，希望尽可能压缩技术栈、减少组件依赖

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