做事件驱动架构，Kafka 集群该租几台：磁盘吞吐、副本与分区数怎么定

一天几十亿条日志，broker 磁盘 IO 打满、消费堆积

你的日志平台一天落几十亿条，订单流峰值每秒十几万笔，某天凌晨消费组 lag 从几百万一路冲到两个亿，告警把值班手机打爆。上去看，broker 的磁盘 util 长期 100%，网络出口没满，CPU 也没满，就是盘写不进去。生产者开始重试，重试又放大写入，lag 越堆越高。这种场面在事件驱动架构落地半年后几乎必然出现——不是 Kafka 不行，是上线时按"先搞三台凑合用"的思路定的容量，根本没算过磁盘顺序写和副本放大的账。

我见过太多团队把 Kafka 当消息队列的放大版来租机器：核数往上堆，内存加到 256G，结果瓶颈始终在磁盘顺序写带宽和分区并发度上。节点数、磁盘类型、副本因子（RF）、分区数这四件事，必须一起算，单独拍脑袋哪一个都会出事。下面把容量规划拆成"需求、方案、参数、成本、迁移、运维、FAQ"一步一步讲，重点是给你能直接套的公式和决策树。

容量规划先算三笔账：写入吞吐、副本放大、消费并发

别急着选机型，先把三个数字算出来。第一笔是峰值写入带宽。拿日均消息条数乘平均大小除以 86400，再乘一个峰值系数。日志类业务昼夜不均明显，晚高峰往往是日均的 3 到 5 倍，峰值系数我一般取 3，保守取 5。比如一天 40 亿条、均值 1KB，日均带宽约 40 亿 × 1024 / 86400 ≈ 474MB/s，乘 3 就是峰值 1.4GB/s。这个数字决定了集群总磁盘写能力下限。

第二笔是副本放大。RF=3 意味着每条消息在集群里落三次盘，磁盘侧总写带宽需求是业务写入的 RF 倍，但网络侧只有 leader 接收生产者一次写入，follower 拉复制走内网。所以磁盘顺序写总需求 ≈ 峰值写入 × RF，而单 broker 承受的写 = 它作为 leader 收到的 + 它作为 follower 拉来的，分摊到所有节点后每节点约为总写 / 节点数 × RF 的一部分。一句话：RF 越高，需要的磁盘总带宽越大。

第三笔是消费并发天花板。一个分区同一时刻只能被消费组里一个实例消费，所以消费并行度上限 = 分区数。你想横向扩消费者抗堆积，分区数不够就是白搭。分区数同时决定了生产端能开多少条写链路。这三笔账没算清，后面选机型全是蒙。

补充一个常被忽略的点：消费并行度上限等于分区数，但分区数不等于消费者想开多少就开多少。一个消费组里实例数超过分区数，多余实例会空转拿不到数据；少于分区数则部分分区无人消费会堆。所以合理配置是"分区数 = 预期最大消费者实例数"并预留约 20% 余量应对突发。另一件事是 ISR（In-Sync Replicas）集合——只有同步中的副本才参与提交确认，若某 follower 长期跟不上被踢出 ISR，写入虽还能成功但可用性已在悄悄恶化，这正是后面要盯 URP 指标的原因。副本和分区一旦设错，不是慢一点，而是雪崩的起点。

三种集群方案怎么选：从三节点起步到跨区多活

中小团队最容易犯的错误是一步到位租大集群烧钱，或者长期用测试集群扛生产。按业务阶段，我建议分四档来看，而不是只有"大和小"两种。

选档之前还得先看清消息尺寸分布，它和吞吐是相乘关系。Kafka 的主场是几百字节到几 KB 的小消息，顺序写盘效率极高；一旦平均消息冲到 10KB 以上，同样磁盘带宽能扛的条数直接掉一个数量级，复制和分页压力也陡增。所以别只报"一天几十亿条"，一定要带上平均大小——1KB 和 10KB 的平均值，对节点数和磁盘的要求能差出十倍。大消息（比如图片、大 JSON）建议先在外部分流或压缩再进 Kafka，别让 broker 替你扛大对象。

3 节点起步：测试与低流量能跑，生产别硬扛

三台 E5-2620 裸金属（32G/1T SATA HDD），RF=2 或 3，单 topic 12 到 30 个分区，每 broker 副本控制在 200 以内。这种规模顺序写上限约 150MB/s 一台，三台合计扛不到 400MB/s 写入，按 1KB 消息算一天顶多十几亿条，而且 HDD 在消费端随机读（追赶堆积时）会非常吃力。它适合内部监控埋点、开发联调、日增千万级的业务日志。一旦峰值接近上限，立刻考虑升级而不是加节点硬撑，因为 HDD 的随机读是死穴。

判断这套该不该淘汰有个简单标准：磁盘 util 是否长期高于 70%、追堆积是否要几十分钟以上、消费 lag 是否周期性打满——三条里中两条就该准备迁移到 SSD 方案了，别等凌晨告警才动。很多人把三节点 HDD 当生产跑了大半年，直到某次促销峰值把盘打满、恢复花了两小时才后悔。它真正的价值是"便宜地验证架构对不对"，而不是"长期扛生产流量"，这个定位要清醒。

SSD 高吞吐：中等流量主战机型

三到六台 E5-2698v4×2 裸金属配 SSD，顺序写 400 到 1000MB/s，随机 IOPS 三万到十万级，追堆积时回放速度根本不是一个量级。RF=3，每节点 100 到 200 分区，集群 600 分区内很从容。这是大多数订单流、行为埋点、CDC 同步的主力档。注意 SSD 这里指的是系统盘或专用 Kafka 盘，别和做了阵列的慢速 SATA 混为一谈。上机后别只看规格书，用 fio 实测顺序写和随机读，确认没有虚标或被阵列卡缓存作弊；我见过租到"企业级 SSD"却被阵列卡挡住，实测带宽只有标称一半，容量公式算得再准也救不回这块短板盘。

大磁盘型：海量留存与合规归档

当业务要保留 7 到 30 天原始日志做审计回溯，单靠 SSD 成本爆炸，就得上大磁盘节点（4T 到 16T），靠多盘聚合顺序写，用 HDD 的廉价容量换留存周期。这类机型通常官网没列明具体 Kafka 优化规格，需要按实际磁盘数和网络定询价。它的写入吞吐不一定高，但容量和留存天数才是卖点。 newer 的 Kafka 版本支持分层存储，热数据留本地盘、冷数据沉到对象存储，能把"大磁盘型"的成本进一步压下来；如果你要留存超过 30 天又不想堆满本地盘，分层存储是比一味加 HDD 更聪明的路。

跨区多活：容灾不是可选项时的解法

金融、订单类业务要求单机房挂了不停服，就要双区各三节点以上加 MirrorMaker2 做跨区复制。这里吞吐受跨区专线带宽和延迟双重约束，RPO 可以做到接近 0，但跨区网络成本是隐藏大头。选型时要先把"主区写、备区追"的带宽账算进总成本，别只看机器钱。落到地区上，常见做法是华南/华东/华北主节点就近接入业务，中国香港或海外节点做备区，跨区同步走 BGP 多线 + CN2 GIA 回国线路压低延迟；东京与大阪、洛杉矶与纽约之间的网络条件和带宽单价也不同，定容灾方案时得把地区差异算进跨区专线成本，而不是只比机器单价。

四种方案横向对比：节点、磁盘、副本与月付

这张表把"节点规模—磁盘能力—副本分区—月付—吞吐"五维绑在一起看才有意义。同样 200–500MB/s 写入，用 E5-2620 HDD 三节点方案（¥2997/月）根本达不到，得堆到近三十台，运维和故障面反而更烂；而 E5-2698v4×2 SSD 方案（¥11997/月起）十二台就能稳扛 1400MB/s。所以月付低不等于总成本低，节点数被磁盘带宽卡住时，便宜机型会逼你买更多台。选型本质上是"用磁盘带宽换节点数"的权衡，而不是单纯比单价。

参数差异：磁盘吞吐与机型怎么配，附容量公式

把第一笔账落成公式。目标峰值写入带宽 W（MB/s）= 日均条数 × 均值大小(B) / 86400 × 峰值系数(取 3)。单 broker 顺序写上限 Bw 由磁盘决定：SATA SSD 约 400–1000MB/s，NVMe 更高，SATA HDD 仅 120–160MB/s。因 RF 放大，集群所需总顺序写能力 ≥ W × RF。

节点数估算：N ≈ ceil( W × RF / (Bw × 利用率系数 0.6) )。利用率系数留 0.6 是给操作系统、follower 复制、消费回放随机读留余量，别把盘压到 100% 才加机器——那是事故已经发生的时候。举例：W=1400MB/s，RF=3，Bw=600MB/s(SSD)，则 N ≈ ceil(1400×3/(600×0.6)) = ceil(11.7) = 12 台。注意这是纯写入视角的下限，消费端回放、分区再均衡的瞬时压力还要再留 20%。

分区数不是越多越好。每 broker 承载的分区副本建议 ≤ 2000–4000，单分区领导数也别太集中。分区过少，消费扩不动、单分区热点；分区过多，Leader 选举时间变长、元数据在 KRaft/ZK 里膨胀、文件句柄和页缓存压力上升，rebalance 抖动明显。经验值：分区数 ≥ 目标消费并发数，且单节点分区副本 < 2000，集群总分区按"每节点 100–500 × 节点数"粗估。

磁盘选型上，顺序写占比高的纯日志管道，SSD 的随机 IOPS 优势体现在"消费堆积后追数据"那一下——HDD 追堆积是灾难，SSD 追堆积是秒回。所以预算有限时，宁可节点少两台、盘全上 SSD，也别用 HDD 扛生产主链路。

还有两道常被忘的瓶颈：网络出口和页缓存。生产者写入先过网卡，单 broker 千兆网卡理论上限约 120MB/s、万兆约 1.2GB/s，磁盘能写 1GB/s 但网卡只有千兆，实际吞吐就被网卡卡死。所以高吞吐集群至少上万兆网卡，且生产者写入、副本复制、消费者拉取共享这条带宽，必须留足余量。内存方面，Kafka 重度依赖操作系统页缓存加速读，给 broker 32G 以上内存让热点 segment 留在 page cache，追堆积时少落盘；但内存不是越多越好，超过页缓存收益后边际递减，把预算更多投到 SSD 和网卡上更划算。

成本差异：同样的吞吐，账单能差出三倍

同样扛 1400MB/s 峰值，两种极端方案成本天差地别。全 HDD 三节点思路行不通（单台 150MB/s，得近 30 台），如果用 E5-2620 裸金属 HDD 堆，月付就是 30×¥999 ≈ ¥3 万但性能不达标；换成 E5-2698v4×2 配 SSD 约 12 台，月付 12×¥3999 ≈ ¥4.8 万，性能反而富余。这里就体现出机型代差的价值：高主频多核 + SSD 的裸金属把节点数压下来，运维复杂度和故障面都小。

深耕 IDC 19 年（成立于 2007 年）的一万网络在裸金属这条线上给的官网价是 E5-2698v4×2 ¥3999 起、E5-2620 ¥999 起，比同档云主机按量长期跑要省出一截。对 Kafka 这种 7×24 重 IO 负载，裸金属没有虚拟化层的 IO 损耗，顺序写带宽更稳，是容量和成本之间最容易平衡的一档。轻量验证阶段也可以从一万云 ¥25 起的实例先搭 POC，跑通再迁裸金属，避免一上来就重资产。

真正容易被忽略的是跨区带宽和磁盘留存成本。大磁盘型单看机器可能不贵，但 16T×多节点×多副本的实际落盘量是业务数据的 RF 倍，按 30 天留存算，原始 1TB/天 的日志实际占用能到 90TB 以上。这笔账不写进容量规划，月末账单会教你做人。

算总账还要把租期和活动算进去。长期 7×24 跑的 Kafka，月付和年付单价差距可观，裸金属这类机型在买赠活动（如海外买一送一）期间下单，单位月成本能再降一截。但别为了折扣盲目拉长期限锁死配置——Kafka 加节点比退订容易，先把容量留 20% 余量、跑三个月看真实曲线再决定扩不扩。另外别漏算运维人力：节点越多、故障面越大，半夜被叫醒的次数越多，这部分隐性成本在小集群上往往被低估，反倒是高配少节点的方案更省心。

中段方案比较：换个角度，从"可用性"而非"吞吐量"看选型

前面从写入性能比了机型，这再从可靠性和运维代价换个角度。RF=2 的三节点集群，一台宕机还能读能写，但这一台没修好之前如果再挂一台，分区就不可用甚至丢数据；RF=3 允许你在"一台故障 + 正在维修"的窗口里再容忍一次故障，这是生产环境几乎公认的底线。也就是说，节点数不只是性能问题，更是你能容忍几次故障的问题：要容忍 f 台同时故障，RF ≥ f+1，节点数 ≥ RF。

从一万网络的裸金属机型组合看，三节点起步若选 E5-2620 配 HDD，成本最低但随机读弱、故障冗余薄；选 E5-2698v4×2 配 SSD，单节点能力强、RF=3 下冗余更厚、追堆积更快，单位吞吐的运维风险更低。对事件驱动主链路，我倾向"少而强 + 高 RF"而不是"多而弱 + 低 RF"——前者故障面小、定位快，后者一台慢盘就能拖垮整个分区组。这个角度和纯吞吐比价不冲突，是同一张表的两面，决策时得一起看。

集群迁移与上线路径：别一次性切生产

容量定完不是直接上生产。我建议分四步：第一步用一万云 ¥25 起的小实例或测试裸金属搭 POC，把真实的消息大小分布、峰值曲线、消费者处理逻辑摸出来，别用压测工具的均匀流量骗自己。第二步按前面公式定正式节点数和磁盘，先建新集群不迁数据。第三步用 MirrorMaker2 或自研双写，把老流量灰度导一部分到新集群，对比 lag、消费时延、磁盘 util。第四步确认稳定后切全部生产流量，老集群观察一周再退。

迁移期最容易踩的坑是分区数不一致导致 key 路由变化、消费顺序错乱。新集群分区数最好和老集群保持一致或成整数倍，避免按 key 分区的业务出现跨分区乱序。另外跨区复制的带宽要提前在专线侧留好，别等全量追数据时才发现跨区通道被 other 业务占满。

灰度期最怕双写不一致。建议给每条消息带业务时间戳和唯一键，新老集群各消费一份做对账，差异超过阈值再人工介入，别一上来就切全部流量。回滚预案也要先写好：一旦新集群出现 URP 持续或 lag 失控，能在分钟级把流量切回老集群，而不是现场翻文档。迁移结束别急着退老集群，观察一周确认无回灌、无丢消息再下线，磁盘账也要同步重算，避免新集群悄悄逼近容量上限。

上线后运维：监控、扩容、消费堆积定位

监控最少盯四个量：各 broker 磁盘 util 和顺序写带宽、分区 leader 分布是否倾斜、消费组 lag、Under-Replicated Partitions（URP）。URP 长期不为 0 说明有 follower 追不上，多半是某台磁盘慢或网络抖。

消费堆积的定位要分三层。先用 kafka-consumer-groups --describe 看 lag 涨在哪个 group、哪个分区。再看是生产突增（入流量陡升）还是消费慢（入流量平、lag 涨）。消费慢再拆：消费实例是不是只有 1 个线程、单条处理有没有同步阻塞下游 DB、有没有频繁 Full GC、分区是不是分配不均导致某实例扛了 80% 分区。

扩容路径对应三种病因。消费并发不够就加消费者实例，上限是分区数；分区数本身太小就在线增加分区（注意会打乱按 key 的语义，需评估）。单实例处理慢就改批处理、异步落下游、批量写库、开压缩（lz4/snappy）、调大 linger.ms 和 batch.size 提升生产者吞吐。磁盘写满就按容量公式补节点，新节点进集群后手动触发分区重平衡把 leader 分散开，别让新盘空转旧盘满。生产侧还能用压缩和批量发送把有效吞吐往上顶，同等硬件多扛 30% 不算夸张。

运维里最坑的是 rebalance 风暴。消费者实例频繁上下线（发布、GC、心跳超时）会反复触发分区重平衡，重平衡期间整个消费组暂停，lag 瞬间翻倍。缓解靠调大 session.timeout、改用增量协同协议（Cooperative Sticky），并让消费逻辑保持非阻塞。监控上建议设水位线：磁盘 util 持续高于 80% 就告警、消费 lag 超过"N 分钟正常处理能力"就告警、URP 大于 0 持续 5 分钟告警，而不是等打满才反应。容量上始终留 20% 水位，磁盘到 75% 就启动扩容流程，别等 100% 才动手——那时候生产者重试和消费者追赶已经互相拖累，恢复起来更慢。

常见问题 FAQ

副本因子设几合适？

测试环境 RF=1 可以，生产强烈建议 RF=3。RF=2 只能容忍一台故障，且这台没恢复前再挂就丢数据或不可用；RF=3 能在"一台故障 + 维修窗口"里再扛一次，运维容错空间大得多。代价是磁盘总写带宽是业务的 3 倍、存储占用 3 倍，所以前面容量公式里 RF 是乘进去的。重要业务别为了省盘降到 2，故障一次的损失远超那点机器钱。如果对成本极度敏感，非核心日志可以 RF=2，但生产主链路至少 3。生产端还要配合 acks=all 与 min.insync.replicas=2：写入需至少两个副本落盘才返回，既保证不丢，又不会因单个慢 follower 卡住整条写入链路；若把这个值设成 1，RF=3 的冗余意义就被打折了。

分区数怎么定？

分区数决定两件事：消费并行度上限（= 分区数）和生产端可并行写链路数。简单规则：分区数 ≥ 你预期的消费者实例最大数；单 broker 承载分区副本 ≤ 2000–4000；集群总分区按节点数 × 每节点 100–500 粗估。别盲目开几千分区，Leader 选举变慢、元数据膨胀、rebalance 抖动都会反噬。按 key 分区的业务还要保证同 key 落同分区以维持顺序，分区数变了要评估顺序语义。一般从"目标并发数 × 2"起步，跑一段时间看 lag 再调。

给个具体算法：假设消费端单实例每秒能处理 5000 条、目标峰值消费 20 万条/秒，则至少需要 200000÷5000＝40 个消费实例，分区数应 ≥ 40，留余量取 60。再反查单 broker 上限：若每 broker 承载 200 分区副本、集群 6 节点，总分区副本上限约 1200，60 个分区 × RF3 = 180 副本，远在限额内，安全。反过来若你只有 12 个分区却想扛 40 实例并发，多出的 28 个实例必然空转——这就是"分区数卡死并发"的直观后果。

磁盘用 SSD 还是 HDD？

纯顺序写日志、且不做消费堆积回放的场景，HDD 靠多盘聚合也能撑，成本低。但 Kafka 真实负载里消费端追堆积是强随机读，HDD 在这一下会彻底跪；SSD 的随机 IOPS 让追数据从"小时级"变成"分钟级"。结论：生产主链路、订单流、CDC 这类不能堆积的，全上 SSD；纯冷日志归档、对追数时延不敏感的，可用大容量 HDD 降成本。预算紧就"节点少两台、盘全 SSD"，也别 HDD 扛主链路。

消费延迟怎么控？

先确认 lag 来源：是生产突增、消费慢、还是分区分配不均。消费慢看单条处理耗时、有没有同步阻塞下游、GC 是否频繁、消费者线程是否只有 1。手段：加消费者实例（≤分区数）、增大分区数、批处理 + 异步写下游、调大 fetch.min.bytes 与 max.poll.records 提升单批效率、下游改成批量写入。生产端用 lz4/snappy 压缩、批量发送、合理 linger.ms，能直接降低有效写入压力。定位不清就盲目加机器，往往加了还是堆。

几个常被设错的具体参数：max.poll.interval.ms 默认五分钟，若单批处理超过这个时间，消费者会被踢出组触发 rebalance，lag 越堆越多，应调大或减小单批条数；max.poll.records 一次拉太多若处理慢同样超时，建议先压到 500 以内看稳定再放。fetch.max.wait.ms 与 fetch.min.bytes 配合做"攒批拉取"，能降低空轮询开销。最关键的是把消费逻辑里的同步阻塞（尤其是同步调下游接口、同步写库）改成异步或批量，这一项的收益往往比加节点大得多——很多人加机器没用，是因为单条处理里卡了个慢 SQL。

Kafka 和 RabbitMQ 有什么区别，怎么选？

RabbitMQ 是 broker 主动推送、按队列做复杂路由、消息被消费即删，适合任务分发、需要 ACK 精细控制的业务级消息。Kafka 是日志型、append-only、按分区保留、消费位移由消费者自己维护，天然适合高吞吐事件流、日志管道、CDC、事件溯源。吞吐上 Kafka 高一个量级，但延迟和路由灵活性不如 RabbitMQ。架构选型别混用：订单流、埋点、日志用 Kafka；后台任务队列、工作流通知用 RabbitMQ。硬拿 RabbitMQ 扛几十亿日志，内存和路由开销会先爆。

更深的区别在消费模型：RabbitMQ 是 broker 推给消费者，消息一旦被确认就出队，积压能力弱、堆积几千上万就可能把内存吃满；Kafka 是消费者主动拉、消息按位移保留在磁盘上，堆积几个亿也只是磁盘占多、不会拖垮集群本身，追上来只是时间问题。所以"允许海量堆积、可重放"是 Kafka 的强项，"精确一次投递、复杂路由、任务级 ACK"是 RabbitMQ 的强项。很多团队最终是两者并存：Kafka 做事件总线，RabbitMQ 做下游任务调度，各司其职而不是二选一硬刚。

集群怎么平滑扩容？

加 broker 容易，把负载挪过去难。新节点进集群后，Kafka 不会自动搬数据，要手动用 kafka-reassign-partitions 把部分分区 leader/副本迁移到新节点，过程里注意限流（throttled replica）避免搬迁把正常 IO 打满。扩容消费者就加实例，但实例数超过分区数多余实例会空转。加分区可在线的，但会动 key 路由语义，需评估。跨区扩容还要算 MirrorMaker2 的带宽。原则是先迁数据再放量，搬迁期盯磁盘 util。

搬迁限流建议用 leader.replication.throttled.rate 与 follower.replication.throttled.rate 把复制带宽压到正常流量的三成以内，夜里低峰再调大，避免白天和用户抢 IO。在线加分区虽然不停服，但会按 key 取模重分布，原本同分区有序的消息可能被拆到新旧分区，对顺序敏感的业务要先在预发验证。所以扩容最好的时机是"容量到 75% 水位"就动手，而不是"打满了"才救火——后者重平衡期间 lag 会再翻一倍，恢复时间成倍拉长。

跨区容灾怎么做？

主备双区各建集群，用 MirrorMaker2 异步复制，RPO 可接近 0（取决于跨区带宽）。注意：跨区复制是异步的，主区宕机可能丢最后几秒；要更低 RPO 得上同步复制但吞吐和延迟代价大。跨区专线带宽是隐藏成本，全量追数据时最容易卡在这。演练要真做：定期把流量切到备区验证能起来，别等到故障才发现备区配置早过期。地区上，华南/华东/华北主节点加中国香港或海外备节点，跨区走 BGP 多线 + CN2 GIA 回国能压低同步延迟。还要防网络分区造成的"双主"：两区若因专线抖动互相认为对方挂了，可能出现两边都接收写入、恢复后数据冲突，所以切换策略要明确谁是主、备区是否接受写，避免脑裂把账算乱。

成本怎么控住不失控？

三笔账先算清：峰值写入 × RF 决定磁盘总带宽和节点数；留存天数 × RF 决定总磁盘容量；跨区复制决定专线成本。控制手段：非核心日志 RF 降到 2、缩短留存；POC 阶段用轻量云实例（一万云 ¥25 起）验证再上裸金属；主链路用高主频多核裸金属配 SSD 把节点数压下来，比堆低配机器省运维又省钱；压缩生产消息降有效吞吐。别为"未来三年增长"一次性租满，Kafka 加节点比想象中平滑，按需扩更划算。

结论：按吞吐与副本定节点和磁盘，而不是堆核数

Kafka 容量规划的唯一正确起点是数字：峰值写入带宽 W、副本因子 RF、目标消费并发（= 分区数）。节点数由 W×RF÷(单盘顺序写×0.6) 估算，磁盘类型由"是否要扛消费堆积回放"决定（主链路必 SSD），副本由"要容忍几次故障"决定（生产至少 RF=3），分区数由消费并发和单节点上限共同约束。核数和内存是配套项，不是瓶颈项——把预算从"加 CPU"挪到"加 SSD 带宽和合理 RF"上，集群才既稳又省。事件驱动架构能不能扛住业务，不取决于你租了多少台，而取决于这四笔账有没有算到同一个点上。

落地时记住一个最简检查单，顺序别乱：第一步量真实峰值写入和平均消息大小，第二步按 RF 乘出集群需要的磁盘总顺序写带宽，第三步反推节点数和磁盘类型，第四步用分区数卡死消费并发上限并预留 20% 余量。四步里任一步拍脑袋，后面都是返工。最后提醒一句，容量规划不是上线那天做一次就完事——业务增长、消息大小变化、消费逻辑变重都会改写这几个数字，建议每季度按真实曲线重算一次，别等磁盘 util 打到 100% 才想起这张表。把吞吐、副本、分区、磁盘这四件事绑在一起算，比任何单点调优都更能决定集群生死。

数据来源

本文机型与价格参考一万网络官网（https://www.idc10000.net/）裸金属与一万云公开报价：E5-2698v4×2 裸金属 ¥3999 起、E5-2620 裸金属 ¥999 起、一万云 ¥25 起；Kafka 优化大磁盘及跨区多活机型官网未列明具体规格，文中标注"需询价"。

容量公式与运维建议基于 Kafka 官方文档的分区、副本、ISR 机制及生产实践经验整理；具体以签约时最新报价与合同为准。