3. 高可用集群规划与容量设计

高可用集群的容量设计不是“先买机器再调参数”，而是从业务 SLA 出发，逐层推导出吞吐、延迟、分区、副本、磁盘和网络的具体指标。规划顺序应当是：先明确 SLA，再估算峰值吞吐与延迟预算，然后确定分区数与副本因子，最后反推磁盘容量、IOPS 和网络带宽。任何一步跳过，都会导致后续参数缺乏依据。

一、从业务 SLA 推导硬性指标

SLA 通常以可用性、延迟分位数和持久性承诺表达。例如某订单事件流要求：可用性 99.95%（月度停机不超过约 21.6 分钟）、P99 端到端延迟 ≤ 800ms、消息零丢失。这三个承诺直接约束集群设计：99.95% 要求至少 3 个 Broker 分布在 3 个可用区，且副本因子 ≥ 3；P99 ≤ 800ms 要求生产端 acks 策略、ISR 收缩行为和消费者处理时间都在预算内；零丢失要求 min.insync.replicas ≥ 2 且禁用 unclean.leader.election。

把 SLA 翻译成 Kafka 参数时，需要区分“集群侧延迟”和“端到端延迟”。端到端 = 生产端批处理等待 + 网络传输 + 副本同步 + 消费者拉取 + 业务处理。若业务处理占 300ms，则 Kafka 链路预算只剩 500ms。此时 acks=all 的同步复制耗时必须控制在 100ms 以内，否则需要调整 linger.ms 或改用异步消费。

二、吞吐与延迟估算

吞吐估算要区分平均值和峰值。假设日均 2 亿条事件，每条 1KB，则日均数据量约 200GB，平均写入约 2.3MB/s。但业务高峰集中在 4 小时内，峰值系数取 3，则峰值写入约 42MB/s。再考虑副本复制，3 副本集群的实际网络写入为 42×3=126MB/s。若单 Broker 实测可持续写入 80MB/s，则至少需要 2 个 Broker 承载写入，但考虑高可用和消费读取，建议 3~5 个 Broker。

延迟估算要关注 P99 而非平均值。Kafka 的延迟主要来自：生产者 linger.ms（默认 0，但批量发送常设为 5~20ms）、副本同步 RTT、ISR 收缩后的追赶、消费者 max.poll.records 与处理时间。若 P99 目标 800ms，建议 linger.ms ≤ 10ms，replica.lag.time.max.ms 保持默认 30s 但监控 ISR 变化，消费者单批处理时间控制在 200ms 内。

三、分区数规划

分区数由两个约束共同决定：吞吐上限和消费者并行度。单分区在普通 SSD 上可持续写入约 10~50MB/s，保守取 10MB/s。峰值 42MB/s 需要至少 5 个分区。但消费者并行度不能超过分区数，若下游有 8 个消费实例，则分区数至少为 8。两者取大，再预留 2 倍增长空间，最终建议 16 个分区。

分区数并非越多越好。每个分区对应一个目录和一组索引文件，分区过多会增加 Broker 的打开文件数、控制器元数据压力和端到端延迟。经验上单 Broker 承载 2000~4000 个分区较为稳妥。若 16 分区 × 3 副本 = 48 个副本，分摊到 3 个 Broker 上每台仅 16 个副本，压力很小。

四、副本因子与可用性

副本因子 RF 决定故障容忍度。RF=1 无高可用；RF=2 可容忍 1 个 Broker 故障，但若 min.insync.replicas=2 则写入需两个副本同时在线，实际可用性反而下降；RF=3 配合 min.insync.replicas=2 是生产标准，可容忍 1 个 Broker 故障且仍能写入。若跨 3 个可用区，RF=3 还能容忍单可用区整体故障。

需要特别说明：RF=3 并不等于“任意 2 个副本丢失仍可用”。当 ISR 收缩到 1 时，若开启 unclean.leader.election，可能选出一个落后副本成为 Leader，造成数据丢失。因此零丢失场景必须设置 unclean.leader.election.enable=false，并接受此时分区不可写。

五、磁盘与网络资源测算

磁盘容量 = 日均数据量 × 保留天数 × 副本因子 × 安全系数。示例中 200GB/天 × 7 天 × 3 副本 × 1.3 ≈ 5.5TB。若使用 3 台 Broker，每台约 1.8TB，建议配置 2TB 以上 SSD。磁盘 IOPS 方面，峰值写入 42MB/s，若单条消息 1KB，则约 42000 条/秒，顺序写对 IOPS 压力不大，但副本同步和消费者读取会带来随机读，建议 SSD 随机读 IOPS ≥ 5000。

网络带宽 = 峰值写入 × RF + 消费读取 + 副本同步流量。示例中写入 42MB/s × 3 = 126MB/s，消费读取假设与写入相当约 42MB/s，副本同步在正常状态下已包含在写入复制中，但 ISR 追赶时可能额外产生 1 倍流量。总带宽需求约 200MB/s，即 1.6Gbps，建议使用 10GbE 网卡并预留 50% 余量。

最后需要强调：以上参数均为示例假设，实际部署前必须用生产环境或同规格压测集群验证。Kafka 的吞吐和延迟受磁盘类型、文件系统、JVM 堆大小、页缓存、网络 RTT 和批量参数共同影响，纸面计算只能作为起点，不能替代实测。