Kafka 在 CentOS 上的扩展性评估
总体结论
在 CentOS 上，Kafka 的扩展性表现突出：依托多 Broker 的横向扩展与按 Topic 分区 的并行处理，可线性提升吞吐与容量；配合 ZooKeeper 或 KRaft 元数据管理，集群可稳定扩展到上千 Broker、数十万分区规模。Kafka 的性能对数据量基本保持恒定，适合长期留存与回放；在 KRaft 模式下，元数据传播与恢复效率显著提升，官方给出的目标是支持单集群数百万分区的扩展上限。
扩展方式与边界
- 横向扩展（Scale-out）：通过增加 Broker 节点提升整体容量与吞吐；在 CentOS 常见做法是每台机器部署一个 Broker，统一通过 listeners/advertised.listeners 对外暴露端口，客户端以多个 Broker 地址作为 bootstrap.servers 实现连接与故障切换。
- 纵向扩展（Scale-up）：提升单机资源（CPU、内存、磁盘、网络）可直接提升单 Broker 的吞吐与 IOPS；建议为日志目录使用 SSD 并合理设置 log.retention.hours、log.segment.bytes 等参数以匹配负载特征。
- 并行度与上限：Topic 的分区数决定并行度上限；在 ZooKeeper 模式下，集群有效分区上限通常为数万级；迁移到 KRaft 后，分区上限可扩展至数百万级，更适合超大规模场景。
在 CentOS 上的扩展实践要点
- 基础部署与网络：安装 Java 8/11，为每台 Broker 配置唯一的 broker.id 与正确的 listeners/advertised.listeners（避免使用 localhost），开放 9092 等端口并配置防火墙放行；客户端以多个 Broker 地址初始化连接以实现负载均衡与容错。
- 元数据与版本选择：传统 ZooKeeper 模式需先行启动 ZK 再启动 Kafka；KRaft 模式取消外部 ZK 依赖，部署更简洁、恢复更快，适合在 CentOS 7/8 上构建大规模集群（如 Kafka 3.5.x）。
- 分区与复制：创建 Topic 时结合峰值吞吐与容错需求设置合理的 –partitions 与 –replication-factor（生产环境常用 3），并规划定期扩容分区与副本再均衡策略，避免热点与不均衡。
- 监控与调优：开启 JMX 并结合 Prometheus/Grafana 监控关键指标；按需调整 num.partitions、log.retention.hours、log.segment.bytes 与 JVM 堆大小，并使用 SSD 降低写放大与尾延迟。