使用Debezium将SQL Server实时同步到Kafka的架构及方案咨询

Topic数量相关问题 #

默认配置下Debezium SQL Server连接器会为每张匹配到的待同步表生成独立Kafka Topic，默认命名规则为[连接器实例名].[数据库名].[Schema名].[表名]，如果你用单个连接器对接全部500个客户库的所有表，确实会生成25万个Topic。

不需要为每个客户单独部署独立Kafka集群，单Kafka集群可稳定承载十万级以上Topic，只要做好集群资源配置即可。如果担心Topic过多带来的元数据管理、资源浪费问题，可以通过两种方式优化：

• 配置Debezium内置的Topic Router单消息转换（SMT）规则，自定义Topic路由逻辑，比如将同一客户的所有表变更消息路由到同一个Topic，下游消费时通过消息内置的源表元数据字段区分即可，可将Topic数量压缩到500个甚至更少
• 按业务域拆分连接器实例，不用为单个客户单独部署连接器，也不用单独搭建集群，降低运维成本

同步方案选型问题 #

没有绝对的最优方案，两种方案各有适用场景，根据你的业务需求选择即可：

优先选Debezium的场景 #

• 不想侵入现有业务代码，做无感知同步
• 需要覆盖所有表变更路径，包括非业务代码触发的变更（比如后台批量改数据、定时任务更新、DBA手动操作等）
• 对数据一致性、事件顺序要求高，需要保证不丢变更、不重复发送，能拿到变更前后的完整字段值
• 待同步的表数量多，业务代码埋点成本极高

优先选业务代码埋点发事件的场景 #

• 仅需要同步核心业务操作触发的变更，不需要覆盖全表所有变更路径
• 事件需要附带数据库中不存在的业务上下文信息（比如操作人ID、操作场景标识等）
• 后续业务逻辑、表结构变动少，可保证代码埋点不会遗漏变更路径

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