4. 集群规划与容量设计

Kafka 集群规划的核心不是“先买机器再调参数”，而是从业务写入量、保留时长、副本冗余和可用区容灾四个约束反推分区数、磁盘、网络与 Broker 数量。规划做得好，集群可以平稳扩容两三年；规划做得差，往往在流量翻倍时被迫停机重分区。本节围绕分区数估算、副本因子、磁盘吞吐与保留策略、网络带宽、机架感知与跨可用区部署、容量增长模型与压测方法展开，并给出可直接套用的估算过程。

一、分区数估算：从目标吞吐反推

分区是 Kafka 并行度的基本单位。单个分区只能由消费者组内一个消费者消费，因此分区数首先决定消费并行度上限；同时分区数也决定生产端可并行的写入通道。估算时先明确三个输入：峰值写入吞吐 T（MB/s）、单分区可持续写入能力 P（MB/s）、期望消费并行度 C。

单分区写入能力受 Broker 磁盘、页缓存刷盘和副本同步影响，经验上单分区在普通 SSD 上可持续 10～30 MB/s，保守取 P = 10 MB/s。若业务峰值写入为 200 MB/s，则仅按吞吐需要 200 / 10 = 20 个分区；若消费端需要 60 个并行消费者，则分区数至少 60。取两者较大值并预留 30% 余量，得到约 80 个分区。示例计算如下：

峰值写入 T = 200 MB/s
单分区能力 P = 10 MB/s
消费并行度 C = 60
按吞吐: ceil(200 / 10) = 20
按消费: 60
取大并预留 30%: ceil(60 × 1.3) = 78 → 取 80 个分区

分区数并非越多越好。分区过多会增大 Controller 元数据压力、延长 Leader 选举时间、增加端到端延迟，并让每分区可用磁盘变小。一般建议单 Broker 承载分区数控制在 2000～4000 以内，单集群分区总数控制在数万级别。若估算结果远超此范围，应优先考虑拆分集群或按业务域分主题治理。

二、副本因子与最小同步副本

副本因子 replication.factor 决定数据冗余度。生产环境通常取 3：可容忍单 Broker 故障而不丢数据，同时兼顾写入放大。副本因子为 2 时容错能力弱，为 1 时无冗余，仅适用于可重放或临时数据。与副本因子配套的是 min.insync.replicas，它决定写入至少需要多少个副本确认。常见组合是副本因子 3、min.insync.replicas=2，配合生产者 acks=all，可在单副本故障时仍保证写入不丢。

三、磁盘吞吐、保留策略与容量计算

磁盘容量由写入速率与保留时长共同决定。单主题每日数据量可按 日均写入速率 × 86400 估算，再乘以副本因子得到实际落盘量。例如某主题峰值 200 MB/s、日均 80 MB/s，副本因子 3，保留 7 天：

日均原始数据 = 80 MB/s × 86400 s ≈ 6.6 TB/天
含副本落盘 = 6.6 TB × 3 ≈ 19.8 TB/天
保留 7 天 = 19.8 × 7 ≈ 138.6 TB
再预留 20% 压缩与索引开销 → 约 166 TB

保留策略有两种：按时间 retention.ms 和按大小 retention.bytes，二者同时生效时以先达到者为准。日志压缩 cleanup.policy=compact 适用于键值快照类主题，可显著降低长期存储。磁盘吞吐方面，应保证单 Broker 磁盘顺序写能力高于其承载分区的总写入速率，并留出副本同步与消费读取的余量。机械盘适合大容量冷数据，SSD 适合高吞吐热数据，混合部署时需按主题分级。

四、网络带宽与跨可用区流量

Kafka 的网络开销主要来自三部分：生产者写入、副本同步、消费者读取。副本同步在跨可用区部署时会跨越可用区边界，产生额外延迟和流量费用。规划时按“写入流量 × 副本因子 + 消费流量”估算单 Broker 出向带宽，并预留 30% 余量。若跨可用区副本同步占主导，应优先考虑同可用区副本优先、跨区仅作容灾的机架感知策略。

五、机架感知与跨可用区部署

机架感知通过 broker.rack 标识 Broker 所在机架或可用区，Kafka 在分配副本时尽量让同一分区的副本分布在不同机架，从而在单机架故障时仍可用。跨可用区部署通常采用“三可用区、每区若干 Broker、副本因子 3”的拓扑，使每个分区在三个可用区各有一份副本。这样单可用区故障时，分区仍有两个副本在线，满足 min.insync.replicas=2 的写入条件。

六、容量增长模型与压测方法

容量增长模型把未来 12～24 个月的写入增长、保留策略变化和副本策略变化纳入同一张表，按季度滚动更新。核心公式是：所需磁盘 = 日均写入 × 副本因子 × 保留天数 × (1 + 开销系数)。当预测值超过当前集群可用容量的 70% 时，应触发扩容或调整保留策略。

压测是验证规划是否成立的关键手段。推荐使用 Kafka 自带的 kafka-producer-perf-test.sh 和 kafka-consumer-perf-test.sh，在预生产环境按峰值流量的 1.2 倍施压，观察 Broker 的磁盘写入延迟、网络出向带宽、ISR 收缩次数和端到端延迟。压测应覆盖三种场景：正常写入、单 Broker 下线、单可用区不可用。若单可用区故障时 ISR 频繁收缩或写入超时，说明副本同步带宽或 min.insync.replicas 配置需要调整。

综合来看，集群规划是一个“估算—压测—修正—再估算”的闭环。分区数决定并行度上限，副本因子与最小同步副本决定容错边界，磁盘与保留策略决定成本，网络与机架感知决定跨可用区可用性。把这些参数放进同一张容量表，并用压测验证，才能让集群在业务增长和故障场景下都保持可控。