Kafka部署咨询：对接300个MySQL选多Broker还是单Broker？

一、Broker部署方案：集群化而非单库单Broker #

业界普遍不会采用为每个数据库单独部署Broker的方案，核心原因如下：

• Broker作为Kafka的存储与转发核心节点，本身会占用CPU、内存、磁盘等资源，300个Broker的运维成本极高——你要维护300个节点的配置、监控、扩容、故障排查，反而比管理一个多Broker集群麻烦得多。
• Kafka集群（由多个Broker组成）天生支持横向扩展，单个集群就能轻松承载数千个Topic的读写请求，只需根据实际负载调整Broker数量（比如起步3-5个Broker，后续按CPU、磁盘使用率扩容）即可。
• Debezium的正确实践是为每个MySQL实例部署一个独立的Connector，每个Connector会为数据库的表生成对应的Topic（默认规则是serverName.databaseName.tableName），这些Topic都可以运行在同一个Kafka集群中，无需拆分到单独Broker。

二、ZooKeeper管理Broker的软硬限制 #

硬限制 #

• ZooKeeper的设计定位是协调服务，而非大规模节点管理。默认配置下，ZooKeeper集群最多能稳定支撑几百个客户端节点（包括Kafka Broker、生产者、消费者等），但实际中Kafka集群的Broker数量建议不超过100个——超过这个数量后，ZooKeeper的元数据同步、心跳处理会出现明显延迟，甚至引发集群不稳定。
• 如果你的Broker数量需要超过50个，更推荐使用Kafka的KRaft模式（替代ZooKeeper的内置元数据管理），KRaft专为大规模Kafka集群设计，能支撑上千个Broker的稳定运行。

软限制 #

• 软限制取决于ZooKeeper的硬件配置与参数优化：
  • 硬件：每个ZooKeeper节点至少分配4G内存（建议8G+），使用低延迟的SSD磁盘，避免磁盘IO成为瓶颈。
  • 参数：调整tickTime（心跳间隔，默认2000ms）、sessionTimeout（Broker与ZooKeeper的会话超时，建议设置为10*tickTime），增加ZooKeeper的线程池大小（maxClientCnxns），可以适当提升Broker的支持数量，但上限仍远低于KRaft模式。

三、Broker内部Topic的管理与组织方法 #

1. 统一命名规范 #

建议采用分层命名规则，方便快速识别与管理：

{业务标识}.{数据库名}.{schema名}.{表名}

比如电商场景下的用户表：ecommerce.user_db.public.user_info，通过前缀就能快速过滤某类业务或数据库的所有Topic。

2. 合理规划分区与副本 #

• 分区数：Debezium默认每个表对应1个分区，若某张表的写入量极大（比如每秒上万条变更），可以将分区数增加到3-5个（按主键哈希分区），但要注意单个Broker的总分区数不要超过10000，否则会加重元数据同步的压力。
• 副本数：生产环境建议设置为3个副本（replication.factor=3），保证数据高可用，避免单个Broker故障导致数据丢失。

3. 批量自动化管理 #

• 避免手动创建Topic，用脚本或自动化工具（比如Ansible、Terraform）批量生成符合规范的Topic，同时统一配置Topic的通用参数（比如retention.ms、cleanup.policy）。
• 利用Debezium的配置自动创建Topic：开启topic.creation.enable=true，并配置topic.creation.default.replication.factor等参数，让Connector自动生成符合要求的Topic。

4. 分类配置隔离 #

• 针对不同重要性的表设置不同的存储策略：核心业务表的Topic设置较长的保留时间（比如retention.ms=259200000，即3天），非核心表设置较短的保留时间（比如retention.ms=86400000，即1天），节省磁盘空间。
• 可以用Topic的自定义配置标记不同类型的Topic，方便监控与过滤。

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