Kafka Connect Sink对接多单分区Topic写MongoDB的适配与配置咨询

Kafka Connect完全适配该Kafka到MongoDB的消息同步场景。该组件原生支持主题正则匹配、分区级并行消费、无状态水平扩缩容，后续新增符合命名规则的主题时不需要手动修改同步配置或重启任务，完全匹配主题数量持续增长的业务特点。

• 主题匹配规则配置：不要硬编码固定主题列表，在Connector配置项中使用topics.regex参数设置正则匹配规则，对应topic.XXX.name的命名格式可配置为topics.regex=topic\\..*\\.name，后续新增符合规则的主题会被Connector自动识别并纳入同步范围。
• 重平衡优化配置：在Worker全局配置中开启静态消费组成员能力，为每个Worker配置唯一的group.instance.id（可直接取节点主机名拼接固定前缀），减少节点重启、扩缩容时触发的消费组重平衡停顿时间。
• Sink写入优化配置：调整MongoDB Sink的批量写入参数，根据单条消息大小将mongodb.batch.size设置为500-2000区间，mongodb.flush.interval.ms设置为1000-5000区间，匹配业务可接受的同步延迟要求即可，避免单条写入带来的不必要性能开销。

tasks.max不需要和当前主题数量一一绑定，初始值建议设置为未来1年预期总主题数的70%，同时取值上限不超过集群总可用CPU核数的1.5倍。
配置逻辑参考：

1. 该场景下每个主题仅1个分区，单个Task可同时消费多个单分区主题，只要批量写入参数配置合理，单Task每秒可稳定处理数千条消息，不需要为每个主题单独分配Task造成资源浪费。
2. 后续如果主题规模增长、同步延迟升高，可随时调大tasks.max参数重启对应Connector，框架会自动重新分配分区，不会中断整体同步链路。
3. 注意不要将tasks.max设置为大于所有匹配主题的总分区数，多余的Task会持续处于空闲状态，白白占用集群资源。

• 部署模式必须选择分布式模式（Distributed），禁止使用单机模式（Standalone），单机模式不支持高可用与水平扩缩容，无法适配主题持续增长的场景。
• 生产环境最小部署规模为3台Worker节点组成集群，避免单点故障，单节点故障时其上运行的Task会自动漂移到其余存活节点，同步链路不会中断。
• 单节点资源配置按每运行1个Task分配1-2核CPU、2-4GB内存估算，同时预留30%左右的冗余资源，用于承接节点故障时漂移过来的Task。举个例子，如果tasks.max配置为24，总资源需求为24-48核CPU、48-96GB内存，按3节点均分的话，单节点配置8-16核CPU、16-32GB内存即可满足要求。
• 后续同步流量、主题规模上涨时，直接将新的Worker节点加入现有集群即可，不需要修改现有Connector配置，框架会自动将部分Task调度到新节点完成水平扩容。

避坑提示：MongoDB Sink Connector建议选择官方维护的版本，不要使用第三方老旧版本，避免出现正则识别主题异常、偏移量提交错误的问题。

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