4. Confluent集群规划与部署
Confluent集群规划不是简单地把几台机器装好Kafka就结束，它决定了后续三到五年内消息中枢能否稳定承载业务增长。规划的核心问题可以归结为五个：需要多少计算资源、节点分别承担什么角色、磁盘用什么介质和RAID策略、网络如何隔离与冗余、故障时如何保证不丢数据且快速恢复。下面按这五个维度展开，并给出可参考的示例参数与判断依据。
一、容量评估：从吞吐和保留量反推节点数
容量评估的起点是业务指标，而不是硬件参数。需要先明确三个输入：峰值写入吞吐（MB/s）、消息平均大小、保留时长与副本数。以某企业订单与日志混合场景为例，假设峰值写入为 120 MB/s，平均消息 1 KB，保留 7 天，副本因子 3。则每日原始数据量约为 120×86400≈10.4 TB，7 天约 72.6 TB，乘以副本因子 3 后实际占用约 218 TB。若单节点可用存储按 8 TB 计算，仅存储就需要约 28 个节点；再考虑压缩比（日志类通常 3~5 倍），实际可降至 8~10 个节点。这说明压缩比和保留策略对节点数影响极大，必须实测或按业务类型估算。
计算资源方面，Kafka 对 CPU 的消耗主要来自压缩、解压、TLS 加解密和副本同步。经验上，每 100 MB/s 写入大约需要 8~12 个物理核心。内存主要用于页缓存，建议每节点至少 64 GB，其中 50% 以上留给操作系统页缓存，JVM 堆不宜超过 6~8 GB，避免 GC 停顿影响请求延迟。网络则按“写入吞吐×副本因子 + 消费吞吐”估算，示例场景下峰值网络约 120×3+120=480 MB/s，即约 4 Gbps，因此建议使用 10 GbE 或 25 GbE 网卡，并预留 30% 余量。
二、节点角色：Broker、Controller、Connect、Schema Registry 的分工
Confluent 集群中，Broker 负责消息存储与读写，Controller 负责元数据管理和分区 Leader 选举。生产环境建议将 Controller 与 Broker 分离部署，避免元数据操作与数据面争抢资源。KRaft 模式下，通常部署 3 或 5 个专用 Controller 节点，奇数个以保证选举多数派。Broker 节点则按机架或可用区均匀分布，确保分区副本跨故障域。
Connect 集群用于数据集成，建议独立部署，避免连接器故障拖垮 Broker。Schema Registry 通常与 Broker 同机部署或独立小集群，但必须保证其可用性，因为所有生产者和消费者都依赖它做 schema 校验。对于中小规模集群，可以将 Schema Registry 与 Controller 合并到 3 台管理节点；大规模集群则建议完全分离。
三、存储选型：介质、RAID 与文件系统
Kafka 的存储性能直接决定集群吞吐和延迟。生产环境强烈建议使用 NVMe SSD，尤其是对延迟敏感的在线业务。如果成本受限，可采用“SSD 做日志段 + HDD 做冷数据”的分层方案，但需要 Confluent Tiered Storage 支持。单节点磁盘容量建议不超过 8~12 TB 可用空间，过大容量会导致副本恢复时间过长，增加运维风险。
RAID 策略上，Kafka 自身通过副本因子保证数据冗余，因此不建议使用 RAID 5/6，因为写惩罚会显著降低吞吐。推荐 JBOD（Just a Bunch Of Disks）或 RAID 10。JBOD 下每个磁盘独立挂载，Kafka 的 log.dirs 配置多个路径，可以并行写入，故障时只影响部分分区。文件系统推荐 XFS，其在处理大文件和并发写入时表现优于 ext4。挂载参数建议 noatime，减少不必要的元数据写入。
四、网络规划：隔离、冗余与带宽
网络规划要解决三个问题：流量隔离、故障域隔离和带宽保障。建议至少划分三个网络平面：管理网用于 Controller 选举和监控，数据网用于 Broker 间副本同步和客户端读写，集成网用于 Connect 与外部系统通信。三个平面物理或 VLAN 隔离，避免相互干扰。
带宽方面，Broker 间副本同步流量通常最大，建议数据网使用 25 GbE 绑定（LACP）或双网卡冗余。客户端接入建议通过负载均衡器或 DNS 轮询，避免单点。跨可用区部署时，要评估跨区流量费用和延迟，通常建议副本因子 3 且跨 3 个可用区，但需接受跨区同步带来的额外延迟（通常增加 1~3 ms）。
五、高可用部署策略：故障域与恢复目标
高可用的核心是“任何单点故障不影响业务”。具体策略包括：Controller 部署 3 或 5 个节点，跨机架分布；Broker 按机架感知分配副本，设置 broker.rack 参数，确保同一分区的副本不在同一机架；设置 unclean.leader.election.enable=false，防止数据丢失；配置 min.insync.replicas=2 与 acks=all，保证写入至少两个副本确认。
恢复目标方面，建议 RTO（恢复时间目标）控制在 1 分钟内，RPO（恢复点目标）为 0。为达到这个目标，需要监控 ISR 收缩情况，设置合理的 replica.lag.time.max.ms（默认 30 秒，可调整为 10 秒以更快剔除慢副本）。同时，定期做故障演练，例如手动 kill 一个 Broker，观察分区 Leader 切换是否在秒级完成，客户端是否自动重连。
最后，规划不是一次性的。建议每季度根据实际吞吐、磁盘使用率和 ISR 延迟做一次容量复核，当磁盘使用率超过 70% 或网络峰值超过 60% 时，就应启动扩容评估。扩容时优先增加 Broker 节点并触发分区重分配，而不是简单扩大单节点磁盘，这样才能保持故障恢复的敏捷性。