📚 课程目录第4章 Kafka集群规划

4. Kafka集群规划

金融行情管道与普通日志管道最大的区别在于：行情数据具有强时效性、突发峰值高、丢包代价大、且往往要求端到端延迟稳定在毫秒级。因此，Kafka集群规划不能只按“能存下”来算，而必须同时满足吞吐、延迟、可用性和容灾四个约束。本节围绕Broker数量、磁盘、网络、机架感知与跨机房五个维度，给出一套可落地的规划方法。

一、核心原理：先定SLA，再反推资源

行情管道的SLA通常包含三项：峰值吞吐（如50万条/秒）、端到端P99延迟（如<50ms）、以及RPO/RTO（如RPO=0，RTO<30s）。规划的第一步是把SLA翻译成Kafka侧的硬指标：分区数、副本数、单Broker承载量、磁盘IOPS与网络带宽。很多团队先买机器再压测，结果发现瓶颈在网卡或磁盘顺序写，返工成本极高。

规划顺序建议：SLA → 分区与副本 → 单Broker吞吐上限 → Broker数量 → 磁盘与网络规格 → 机架与机房拓扑。任何一步倒置，都会导致后续反复调整。

二、Broker数量：按吞吐与分区双约束计算

Broker数量由两个约束共同决定：吞吐约束和分区约束。吞吐约束用“峰值吞吐 ÷ 单Broker安全吞吐”估算；分区约束用“总分区数 ÷ 单Broker推荐分区数”估算。行情场景单Broker安全吞吐建议取实测值的60%，留出突发余量。

# 示例：峰值 50万条/秒，单条平均 500B
峰值带宽 = 500000 * 500B ≈ 250 MB/s（含副本约 500 MB/s）
单Broker安全吞吐（3副本、万兆网）≈ 120 MB/s
Broker数量（吞吐约束）= 500 / 120 ≈ 5 台
总分区数 = 200，单Broker推荐 ≤ 100 分区
Broker数量（分区约束）= 200 / 100 = 2 台
最终取 max(5, 2) 并向上取整到机架倍数 → 6 台（3机架 × 2）

注意：副本因子为3时，网络与磁盘写放大接近3倍，计算时必须计入。若使用机架感知，Broker数量最好是机架数的整数倍，便于副本均匀分布。

三、磁盘选型：顺序写、IOPS与容量三者权衡

Kafka以顺序写为主，但行情管道存在大量小批量写入和消费者追赶读，因此磁盘不能只看顺序带宽。SSD在随机读、fsync延迟和故障恢复速度上明显优于HDD，是行情场景的首选。容量规划按“日增量 × 保留天数 × 副本因子 × 1.3（索引与压缩余量）”估算。

维度	HDD	SATA SSD	NVMe SSD
顺序写带宽	150–200 MB/s	400–550 MB/s	2–7 GB/s
随机读IOPS	约 100–200	约 5万–10万	约 50万+
fsync延迟	毫秒级抖动大	亚毫秒	亚毫秒且稳定
适用场景	冷数据归档	常规行情管道	高频低延迟核心链路

行情核心链路建议NVMe，历史回放与归档可用SATA SSD或HDD分层。单Broker建议多块盘做JBOD而非RAID，让Kafka自行管理副本，避免RAID重建拖慢整体。

四、网络带宽：别让网卡成为隐形瓶颈

Kafka是网络密集型系统，副本同步、消费者拉取、跨机房复制都会占用带宽。经验公式：所需带宽 ≈ 峰值写入带宽 ×（副本因子 + 消费者数 + 跨机房复制份数）。万兆网卡实际可用约 1.1 GB/s，但建议只用到70%。

# 查看网卡与丢包
ethtool -S eth0 | grep -E "drop|error"
sar -n DEV 1 5

# Kafka关键网络参数
num.network.threads=8
num.io.threads=16
socket.send.buffer.bytes=1048576
socket.receive.buffer.bytes=1048576
replica.fetch.max.bytes=1048576

若单Broker峰值写入250 MB/s、3副本、2个消费组、1份跨机房复制，则出口带宽约 250×(3+2+1)=1.5 GB/s，已超过万兆实际上限，必须拆分Broker或升级到25G/100G网卡。

五、机架感知与跨机房部署策略

机架感知通过 broker.rack 参数让Kafka把同一分区的副本分散到不同机架，避免单机架断电导致分区不可用。跨机房部署则要在“同步复制低延迟”与“异步复制高吞吐”之间取舍。

同城双机房：可用同步复制（min.insync.replicas=2），RPO=0，但跨机房RTT需<2ms，否则延迟飙升。
异地多机房：建议异步复制或MirrorMaker2，主集群本地3副本，异地做灾备，RPO以秒计。
机架感知配置：每台Broker设置唯一rack，副本因子≥3且跨3机架，才能容忍单机架故障。

# server.properties 机架感知
broker.rack=rack-a
default.replication.factor=3
min.insync.replicas=2
unclean.leader.election.enable=false

常见误区：把机架感知当成“配了就行”。若Broker数量不是机架数整数倍，或分区副本分配未均衡，仍会出现同机架多副本。上线前务必用 kafka-topics --describe 检查每个分区的副本分布。

六、案例复盘：一次行情峰值导致的副本同步延迟

某券商行情管道初期使用6台Broker、3机架、SATA SSD、万兆网。开盘集合竞价时峰值冲到80万条/秒，监控发现ISR频繁收缩，P99延迟从20ms升到300ms。排查发现两个问题：一是单Broker分区数超过250，副本同步线程争抢严重；二是跨机房异步复制占用了30%出口带宽，挤压了本地副本同步。

调整方案：Broker扩到9台（3机架×3），单Broker分区降到120以内；跨机房复制改为独立网卡并限速；将 replica.fetch.max.bytes 从1MB调到4MB，减少小包往返。调整后ISR稳定，P99回到35ms以内。这个案例说明：Broker数量、磁盘、网络、机架与跨机房不是独立参数，必须联合调优。

上线前必做三项检查：1）用 kafka-topics --describe 确认副本跨机架；2）用 kafka-producer-perf-test 压测峰值1.5倍；3）模拟单机架断电，验证min.insync.replicas与unclean.leader.election配置是否符合预期。

综上，行情Kafka集群规划的本质是：以SLA为起点，用吞吐和分区双约束定Broker数量，用顺序写与fsync延迟定磁盘，用副本与消费者数量定网络，用机架感知保本地高可用，用跨机房策略平衡RPO与吞吐。五者联动，才能支撑金融行情管道的高吞吐与低延迟。