干了十几年消息队列运维，见过太多团队把 Kafka 当成"装个中间件就能扛住"的东西，结果上线三个月就开始半夜被告警叫醒。说白了，Kafka 这台机器上最贵的从来不是 CPU——它吃的是顺序写的磁盘、留給页缓存的内存、以及 broker 之间的内网带宽。你在选型阶段少算一个副本数、多给 JVM 堆分 8G 内存、或者把分区一次开到 5000，后面都会以"半夜磁盘打满""ISR 反复抖动""消费延迟翻十倍"的形式还回来。
这篇文章不谈虚的架构理念，只解决四件具体的事：磁盘够不够用怎么算、磁盘 IO 和网络到底谁先扛不住、分区数和副本因子怎么定、保留策略怎么配，最后落到"到底租什么样的机器、多少钱"。下面几条是全文的核心结论，急着上线可以先照着做：
1. 磁盘容量公式务必按三要素相乘： 生产端日均写入量 × 副本因子 × 保留天数 ÷ 压缩收益系数，算完还要留 25%–30% 的余量给段滚动、索引和副本追赶。
2. Kafka 的性能几乎全部来自操作系统页缓存（page cache），不是 JVM 堆。 堆给 4–8GB 就够，剩下的内存一分都别抢，那是给 page cache 留的。
3. 副本因子 3 + min.insync.replicas=2 + acks=all 是生产默认安全线。 为了省钱上 RF=2 又开 acks=all 的，等于把可用性砍了一半还得天天盯着 ISR。
4. 分区不是越多越好。 单 broker 上分区总数（含副本）控制在 2000–4000 以内比较稳，多开的分区会先把顺序写打散成伪随机写，再拖垮元数据同步。
5. 磁盘选型建议 NVMe 起步，JBOD 优于 RAID。 Kafka 自己有副本冗余，RAID 只是多花一倍盘钱买一个重建期性能雪崩。
很多团队买机器靠拍脑袋，"先来 4T 试试"三个月后就得停机扩盘。其实 Kafka 的磁盘占用是可以算得很准的，因为它本质上就是一个只追加写的日志文件系统。你只要记住这个公式：
集群磁盘占用 ≈ 生产端日均写入量 × 副本因子 RF × 保留天数 × 压缩系数 ÷ 集群 broker 数 × (1 + 余量)
公式里每一项都有讲究。日均写入量要取生产端未压缩的原始量，而不是你看监控面板上那个"写入字节数"；副本因子是指这条数据在集群里存几份，RF=3 就是三台机器各写一份；压缩系数看你在 producer 端开了什么压缩（gzip 一般 0.3–0.5，lz4 / zstd 多在 0.4–0.7，纯 JSON 日志压得好，已经加密或二进制的压不动）；余量给 0.25–0.3，因为 log segment 滚动前后会短暂双份、索引文件和 timeindex 也要占地方、还有副本重建期的数据搬运。这里还要多加一份"突发冗余"：业务侧一次补数任务可能让当天写入量直接翻倍。
还有个容易被忽略的项——磁盘真正能用的比例建议压到 70%–75%。Kafka 在磁盘写满时会主动停止分区写入并把 broker 标记为异常，一旦触发，恢复过程比重装还难受。所以算出来的理论容量，要按 70% 的水位去反推该买多大。
算例 A：中型业务，日均原始写入 5TB。 RF=3、保留 7 天、producer 开 zstd 压到 0.5。集群总占用 = 5TB × 3 × 7 × 0.5 = 52.5TB，乘 1.3 的余量约 68TB，再按 70% 水位反推需要约 97TB 的裸容量。如果跑 3 个 broker，每节点约 32TB 可用裸容量，实际配 4 块 8TB 或 6 块 4TB 盘更灵活；如果扩展到 5 个 broker，每节点 20TB 左右，性价比反而更好，因为分区可以铺得更开。
算例 B：订单异步化 + 埋点上报，日均 500GB。 RF=3、保留 3 天、压缩系数 0.6。总占用 = 0.5TB × 3 × 3 × 0.6 = 2.7TB，乘 1.3 约 3.5TB，按 70% 水位反推约 5TB 裸容量。三节点每节点不到 2TB——这种规模用 2 块 960GB–1.92TB 的企业级 SSD 做 JBOD 就够了，没必要追 NVMe，把钱省下来加内存更实在。
算例 C：IoT 设备上报，日均 20TB 且峰谷比 5:1。 RF=2、热数据保留 3 天、超期数据落到对象存储或冷归档。热层 = 20TB × 2 × 3 × 0.5 = 60TB，乘 1.3 约 78TB，按 70% 水位反推热层裸容量约 110TB。这个量级建议 6 个 broker 起步、每节点 20TB NVMe，并且一定要做分层——全放 NVMe 上，成本会让你怀疑人生。
老说法是"Kafka 全是顺序写，HDD 扛得住"，这话只对了一半。稳态写入时确实如此，HDD 的顺序写也能跑到 150–220MB/s。问题在于 Kafka 有四种场景会瞬间把顺序写变成近似随机 IO：一是分区数多，几十上百个分区同时 append，物理磁头（或 SSD 的写放大）就被打散了；二是 follower 追赶时并发拉取不同分区的数据，磁臂来回跳；三是消费者滞后时回溯读历史数据，属于纯随机读；四是分区重分配和副本重建，读写同时砸下来。
这四种情况里 HDD 几乎是硬伤，随机 IOPS 只有 100–200，一上来延迟就从毫秒级飙到几百毫秒，直接触发 ISR 抖动。SATA SSD 的顺序写 400–550MB/s、随机读 IOPS 数万，日写入 1TB 以内、分区数不超过几百的场景完全够用，单价也比 NVMe 便宜一大截。NVMe 的顺序写轻松过 2–3GB/s、随机读 IOPS 数十万且队列深度高，适合日写入 TB 级、分区上千、或频繁发生副本追赶重建的场景——你买的其实不是"顺序写更快"，而是出事时的恢复余量。
还有一个隐性差别是延迟稳定性。SATA SSD 在 GC（垃圾回收）和写放大上来时，p99 写延迟会周期性拉高；NVMe 因为有更多并行通道和更好的固件调度，抖动小得多。对 Kafka 这种"一个慢盘拖垮整个 ISR"的系统，尾延迟比平均带宽重要得多。
我的立场很明确：Kafka 场景下 JBOD 优于 RAID，几乎没有例外。 理由是 Kafka 在软件层已经有副本冗余了，RAID 再做一层冗余等于花两倍盘钱买重复保障；而且 RAID 卡重建时整阵列性能掉一半以上，本来一台 broker 挂了还能靠其他分区继续服务，RAID 重建直接把剩下的数据也拖慢。
具体做法是把多块盘挂成独立的挂载点，全部写进 broker 的日志目录配置项里（多个目录用逗号分隔），Kafka 会自动把分区按"分区数最少"的策略铺到各块盘上，天然的 IO 均衡。这样坏一块盘只影响该盘上的分区副本，broker 不会整体下线，其他副本还在 ISR 里继续提供服务，你有充足时间从容换盘。
RAID 0 也不是完全不能用——它的吞吐确实好看，但坏一块盘意味着这台 broker 上所有副本同时消失，等于把一个小故障放大成集群级事故。真要用，前提是 RF≥3、盘数足够多、而且能接受故障时整台机器下线重建。至于 RAID 5/6 的写惩罚，在 Kafka 这种持续大流量写入的负载上纯属自找麻烦，别碰。
Kafka 能做到百万级吞吐有个公开的秘密：它几乎不自己管理缓存，写和读都直接依托操作系统的页缓存。 生产者写进来，数据先进 page cache 再由内核异步刷盘；消费者读的时候，如果消费的是刚写入的"尾部数据"（绝大多数实时场景就是如此），读请求直接在 page cache 命中，压根不碰磁盘。这就是为什么很多 Kafka 集群看起来磁盘 IO 很闲、吞吐却很高。
这个机制告诉我们两件事。第一，内存要留给操作系统，不是留给 JVM。 常见错误是给 Kafka 进程配 16G、24G 的堆——堆大了 page cache 就小，GC 停顿还更长，属于两头受罪。生产环境的通行做法是堆给 4–8GB（压缩、解压、网络缓冲基本就够了），剩下的物理内存全部交给内核。一台 128GB 内存的机器，堆给 6GB，扣掉 OS 和其他进程，能有 100GB 以上的 page cache，足够覆盖最近一两个小时的写入热点。
第二，page cache 的大小直接决定了你的"追赶余量"。 当 follower 短暂掉队、或者消费者因为下游故障停了二十分钟再回来，能否不落盘就把数据补上，全看这段时间的数据是否还在缓存里。缓存够大，追赶是纯内存拷贝；缓存不够，就变成全磁盘随机读，接着就是 IO 打满、ISR 收缩的连锁反应。
写入是顺序的，但读取不见得。第一个读放大源是 follower 拉取。 每个 follower 都要从 leader 同步数据，RF=3 意味着一份数据要在 broker 之间传两次；这些拉取来自不同分区的不同位点，叠加在一起对磁盘就是并发顺序读，磁头和 SSD 的读放大都会上来。
第二个读放大源是滞后消费。 消费者在读实时数据时命中的是 page cache，一旦落后到历史数据区域，读的就是磁盘，而且是多个分区、多个消费者组交错读——标准的随机读模式。此时你会看到一个诡异现象：集群写入量没变，磁盘 util 却打满到 100%，生产端延迟跟着涨。解决办法要么让消费者别落后太久（扩容消费者或优化处理逻辑），要么干脆给足 NVMe 和内存，让"落后半个小时"仍然落在缓存里。
还有个常被忽视的点：同一份数据可能被反复读多次。 一个 topic 挂三个消费者组，读流量就是三倍；如果其中有一个是做实时计算的 Flink 任务、另一个是做离线的同步任务且经常回溯，磁盘压力会是写入量的好几倍。估算配置时要把"读取倍数"也算进去，而不是只盯着写入。
零拷贝（sendfile / transferTo）确实是 Kafka 高吞吐的关键：消费数据命中缓存时，数据从页缓存直接经网卡 DMA 发出，不用在用户态和内核态之间来回拷贝，CPU 占用和延迟都降下来。但 zero-copy 只在"数据已在 page cache 中"时生效。
一旦落到磁盘，这条路径就断了，数据必须经内核读进缓存再发出，拷贝次数回到常态，延迟也随之上升。所以别指望零拷贝能救一个内存不足、缓存命中率低下的集群——它放大的只是你已有的好，掩盖不了底层的坏。还有一点，开启 SSL/TLS 加密传输时，零拷贝路径同样会失效，因为数据必须经过用户态做加解密，这会明显抬高 CPU 用量和端到端延迟。如果 broker 之间、broker 与客户端之间全链路开了 TLS，CPU 核心数要给足，别按明文压测的结果去配 8 核。
很多人的直觉是"Kafka 瓶颈在磁盘"，实际生产里网卡先打满的情况一点都不少。broker 的入流量大致等于生产写入量；而出流量要叠加两部分：跨 broker 复制流量约等于写入量 ×（RF−1），加上所有消费者组的读取流量。也就是说 RF=3、又有两份实时消费时，出网带宽接近写入量的五倍。
最常见的三种翻车场景：其一，副本因子开到 3 又不限制跨节点带宽，一旦有 broker 挂掉触发副本重建，重建流量能把内网带宽吃干，正常业务的复制被挤到超时，然后更多分区掉出 ISR——典型的雪崩。做法是给复制流量设带宽限流，把重建窗口放到业务低峰，宁可慢点补也不要把业务挤死。
其二，跨机房 / 跨可用区部署。 同城双活的 Kafka 集群，副本跨可用区意味着所有写入都要走专线，专线带宽既贵又有上限，常常是你付了双倍的专线费还换来更高的写入延迟。真要做异地容灾，建议主集群副本留在同机房（或同可用区）内，用镜像工具（MirrorMaker 2 一类）做异步跨城复制，让高延迟留给容灾链路而不是主写链路。
其三，消费端 fan-out 太大。 一个大 topic 挂了七八个下游消费者组，尤其还有做全量回溯的批处理任务，出网带宽直接封顶。给一张参照表：一条 10Gbps 内网满打满算，扣除 TCP 开销后有效吞吐大约 1.0–1.1GB/s，按 70% 安全水位留出约 700–800MB/s 可用（具体以压测为准）。日夜峰值接近这个数就该上 25G 或者拆集群了。
分区是 Kafka 并行度的基本单位：一个分区在同一个消费者组内只能被一个消费者线程消费，这就决定了分区数直接等于消费端的最大并发度。估法可以走三条线交叉验证：
第一条，按目标写入吞吐估。 单个分区的稳定写入能力受批大小、压缩、acks、副本数共同影响，经验区间大致在 5–15MB/s（以你自己的压测为准）。你要扛 200MB/s 的持续写入，按单分区 10MB/s 保守估，就需要 20 个分区。注意这条线要在每层标签/topic 都算一遍，别只算总量。
第二条，按消费并发估。 单个消费线程的处理能力取决于业务逻辑轻重，轻量转发能到 30–60MB/s，涉及写库、调外部接口的重逻辑可能只有 5–15MB/s（同样以压测为准）。如果你要求下游 300MB/s 的处理能力，单线程 15MB/s，那就要至少 20 个分区才能拉起 20 个消费线程——这条线往往比写入那条更苛刻。
第三条，看上限能不能收住。 分区不是免费的：每个分区都有自己的 segment 文件、索引文件和内存里的元数据；分区一多，leader 选举、元数据同步、controller 管理的成本都上来，单 broker 上的分区数（含副本）行业里比较稳的经验是控制在 2000–4000 以内。新版 KRaft 模式在元数据能力上比老的 ZooKeeper 模式强不少，支持的分区规模更大，但普通业务真的没必要去摸边界。
我个人的做法是：按当前峰值需求的 1.5–2 倍开分区，留出横向扩容空间，但绝不一上来就开几千。 分区数只能增不能减（减分区要做数据迁移或新建 topic），一次性开太多是不可逆的决定。
这是个"省钱还是省心"的选择题。RF=2 能省三分之一磁盘和网络开销，但只能容忍一个副本失效，而且很脆弱。 一台 broker 计划内重启时，你短暂地只剩一个副本来扛读写压力，如果此时第二台机器正好因为磁盘抖动掉出 ISR，这个分区就真的没数据可用了。
RF=3 是生产环境的事实标准：能容忍一台机器彻底挂掉而集群仍然可写可读，日常升级重启也不掉可用性。代价是磁盘和网络各多一份开销，但这笔钱比一次事故的赔偿便宜太多。RF=1 只配出现在测试环境和可重建的数据管道里，真在订单、支付这类链路上用 RF=1，那是拿职业生涯开玩笑。
还有一种隐性坑：副本和 leader 落在同一台物理机上。 听起来荒唐，但在小集群（3 台机器跑 RF=3）里，如果没做机架感知或者分区把两个副本分配到同一 broker，机器一挂整个分区副本全丢。一定要配机架感知（broker.rack），并且留意分配后不要手动干预 leadership。
这两个参数穿起来才有效果，拆开看都容易误判：
acks=0： 生产者发完不等确认，吞吐最高，数据丢了都不知道。只配日志采样、可丢弃的指标上报。
acks=1： leader 落盘就返回，leader 写入后没来得及同步给 follower 就宕机会丢数据。很多"偶发丢消息"的悬案根源在这。
acks=all（或 -1）： 等 ISR 里所有副本确认才返回，最安全，但延迟比 acks=1 高一截（视网络和磁盘状况，端到端 p99 延迟通常在十几到几十毫秒量级，以压测为准）。
关键在于 acks=all 必须配 min.insync.replicas 才成立。RF=3 时把 min.insync.replicas 设为 2，意味着至少两个副本确认才算成功，能容忍一个副本掉队；如果设成 1，acks=all 就退化成了 acks=1，看起来安全其实照样丢。而 RF=2 配 min.insync.replicas=2，等于要求两个副本都在 ISR 里才能写入，任意一个副本抖动就写不进去——这是典型的"为了省钱把可用性也省没了"。
推荐的三件套：RF=3 + min.insync.replicas=2 + acks=all，再配上unclean.leader.election.enable=false，禁止把不在 ISR 里的副本选成 leader（否则可能选上一个落后的副本，直接造成数据丢失或位点回退）。这套组合在正常模式下允许一台机器任意下线。
ISR（同步副本集合）抖动的表现形态很固定：某个 follower 追不上 leader，被踢出 ISR；如果 ISR 数量跌破 min.insync.replicas，生产者就开始收到副本不足的错误，写入被拒绝；然后 follower 追上来，又恢复……循环往复。
根因通常就那几个。一是 GC 停顿：堆开太大或不合理的收集器让 broker 停了几秒，follower 拉取卡住被判定落后。二是磁盘 IO 尖峰：同机部署了别的重 IO 服务，或者磁盘写满前的最后挣扎。三是 page cache 被挤掉：内存留给 heap 过多，或者机器上跑了其他吃内存的东西。四是网络抖动，尤其是跨可用区复制。
排查顺序我一般是：先看 broker 的请求处理器空闲率指标（持续低于 0.7 说明处理线程已经在扛瓶颈），再看有没有低于最小 ISR 数的分区，然后才去翻 GC 日志和磁盘 util。治理手段别上来就调大副本超时时间，那只掩盖症状；先把根因解决，必要时才把相关参数放宽到 30–60 秒级别作为缓冲。要监控的最低四项：欠副本分区数、低于最小 ISR 的分区数、ISR 伸缩频率、请求处理器平均空闲率——这四个指标设好告警，能省掉一半的半夜救火。
Kafka 支持两种清理口径并存，实际生效的是先触达的那个：按时间（保留小时数 / 毫秒数）和按大小（分区或 topic 的字节上限）。绝大多数业务用时间保留就够了，因为它和业务语义直接对应——"能回溯三天"是一句产品经理也听得懂的话。
两种必须同时配置的情况：写入量峰谷比极大的 topic，只设时间的话，一次大促或者一次批量补数就能把磁盘写满，此时大小保留是最后一道保险；磁盘紧张又不想精细做扩容的场景，用大小保留做硬上限，但要注意磁盘满时 Kafka 会停止接收写入，这属于"宁可中断也不要整个集群崩"的取舍。
还有个干活Tips：保留策略的最小粒度是日志段（segment），不是单条消息。 一个 segment 默认滚动大小是 1GB（也有按时间滚动的参数），只有整个段里最后一条消息都过期了，这个段才会被删除。所以算容量时要把"最后半个到一整个未过期段"的冗余留出来，尤其分区多的时候，几百个未滚动完的段加起来是笔不小的开销。
普通保留策略是"到期整段删"，而日志压缩（log compaction）保留的是每个 key 的最新值，同一个 key 的旧版本会被后台线程清理掉。它适合的场景非常明确：CDC 数据同步里的变更流、维表 / 配置下发、状态类 topic——这些场景关心的是"当前最新状态是什么"，历史中间态不重要。
用 compact 前必须确认三件事：一是每条消息都要有可靠的 key，没有 key 或者 key 设计不合理，压缩等于把数据删乱；二是要保留策略配成压缩、删除或两者组合，纯 compact 模式下墓碑消息（值为 null）也需要额外延迟清理；三是接受压缩本身是有成本的，后台压缩线程读写会占用磁盘 IO 和 CPU，正常情况下位于可接受区间，但在 IO 已经紧张的节点上会雪上加霜。
要注意一个常见误解：compact 不保证"绝对没有重复"。 未压缩的尾部段里仍然可能存在同一 key 的多个版本，消费者必须按幂等思路去处理，别指望 compact 帮你去重。
数据量再往上走，全部热数据放本地 NVMe 就不划算了。业界的主流方向是分层存储：较新的日志段留在本机 SSD/NVMe 上保证低延迟读写，超过一定时间或大小的段自动卸载到远端对象存储归档，消费者回溯历史数据时，broker 从远端拉取后透明返回。
这个能力在不同发行版里的成熟度差别不小，社区版本也在持续迭代中（相关的议题从 KIP-405 起一直在演进），落地前务必先在测试集群验证再上生产，别被"省 80% 成本"的宣传冲昏头。它的代价也很清楚：读历史数据的延迟从毫秒级上升到几十到几百毫秒级，并且依赖远端存储的稳定性和额外流量成本。适合的场景是：需要保留 30–90 天以上、但绝大多数消费集中在最近几小时的合规审计类数据。不适合的场景是：需要频繁全量回溯重放的流处理任务。
退一步说，即使不用官方分层能力，你也可以用架构手段分担：本地只留 3 天热数据，同时用旁路任务把数据同步到数据仓库或对象存储做长期留存。这是我最推荐给中小团队的做法——简单、可控、不依赖版本。
把前面的公式和结论落成一张表。下表按"典型三节点起步"估算，写入量级指生产端日均原始写入量，价格参考已标明可信度：
| 档位 | CPU 与内存 | 磁盘方案（JBOD） | 网卡 | 适用写入量级 | 参考月租 |
|---|---|---|---|---|---|
| 入门 3 节点 | 8–16 核 / 32–64G | 2×960G–1.92T 企业级 SATA SSD | 1G–2.5G | 日均 200GB–1TB | ¥999/月起（官网价） |
| 中等吞吐 | 16–32 核 / 64–128G | 4×1.92T–3.84T NVMe | 10G 内网 | 日均 1TB–5TB | ¥3999/月起（官网价） |
| 高吞吐 | 32 核以上 / 128–256G | 6–8×3.84T–7.68T NVMe | 25G 内网 | 日均 5TB–20TB | 按需定制（预估，以咨询为准） |
| 冷热分层 | 16–32 核 / 128G | 2×1.92T NVMe（热）+ 6×8T HDD（冷） | 10G 内网 | 日均 1TB–5TB，保留 30 天以上 | 按需定制（预估，以咨询为准） |
读表时抓三个要点：内存比 CPU 重要，同样预算下优先加内存堆 page cache，而不是升级更高主频的 CPU；盘数比单盘容量重要，多盘 JBOD 分摊 IO，扩容也更灵活；网卡不要按当前量，要按"重建副本 + 消费 fan-out"一起算，留出 30% 以上余量。
关键词维度：E5-2698v4 双路 | 32G 内存 / 1T 硬盘起步 | 官网价 ¥3999/月起 | 多盘 JBOD 可升级 | BGP 多线 | 深圳南山自营
推荐配置：双路 Xeon E5-2698v4（合计 40 核）起步，32G 内存 / 1T 硬盘的基础档位，按需升级。落到 Kafka 场景，我建议这样加：内存升到 128G（+¥600/月），堆只给 6–8G，剩下的全留给 page cache；硬盘加固态多盘，做成 4 块企业级 SSD/NVMe 的 JBOD 而非单块大盘（1T 硬盘升级项约 +¥300/月，多盘方案具体以咨询为准）；CPU 升到 16 核档（+¥400/月） 应对压缩解压和批量传输的开销。三台起，配机架感知，RF=3。
价格参考：裸金属基础档官网价 E5-2620 32G/1T ¥999/月 起，到 E5-2698v4×2 32G/1T ¥3999/月 起，以上均为官网公开报价，具体以官网实时价为准。带宽方面裸金属默认提供大陆优化线路，broker 之间的内网 / 专线带宽按方案定制，这部分属于预估范围，签约前一定找工程师确认清楚，别默认它跟着机器默认赠送。
适配场景：日均写入 1TB–5TB 的日志采集、埋点上报、订单异步化；想要独占物理资源、不想跟别人抢 IO 的数据平台团队。这档的性价比在于：同样的钱换成云主机，磁盘 IO 和内网带宽往往是共享的，Kafka 这种 IO 敏感负载吃亏特别明显。
关键词维度：多节点部署 | BGP 多线 + CN2 GIA | 自营机柜最快 1 分钟上架 | 硬件故障 10 分钟自动迁移 | 7×24 中文工单 5 分钟响应
推荐配置：Kafka 最怕的不是单机性能不够，而是"三台机器实际在一个故障域里"。一万网络在华南、华东、华北都有节点，做同城扩展时可以把副本跨节点部署，配合机架感知避免同分区多副本落在同一物理机。注意不要为了容灾把副本跨城摆放——跨城复制延迟会直接抬升 acks=all 下的写入延迟，主链路应当留在同节点内，异地用 MirrorMaker 之类的工具做异步镜像。
价格参考：各地区起步价不同（华南 ¥799 起、华东 ¥699 起、华北 ¥899 起，均为官网明示起步价），集群整体报价按节点数和配置核算，集群方案总价属于预估范围，以咨询为准。
为什么推荐这一档：一万网络深耕 IDC 19 年（成立于 2007 年），总部在深圳南山，自营机柜最快 1 分钟上架，硬件故障 10 分钟内自动迁移——对 Kafka 来说，"坏掉一台机器多久能补回来"直接决定了你要不要多留一倍磁盘余量。加上 7×24 中文工单平均 5 分钟响应、免费提供系统盘每日快照和 5–20G 流量防护、免费协助备案，整体运维压力比其他方案轻得多。
别把所有角色都堆在 broker 上。KRaft 控制器、监控采集、Schema Registry、Kafka Connect 这些轻量组件，用弹性云节点跑就行，一万云 ¥25 起（官网价，以官网实时价为准），跟裸金属集群分开部署，既省钱又避免它们抢 broker 的 page cache 和 IO。这是我常给客户的建议：broker 只干 broker 的活。
为什么坑：分区数只能增不能减，一次开到几千，带来的成本是长期的——每个分区都有独立的文件句柄、内存元数据和后台线程开销，磁盘上的顺序写被众多分区并发 append 打散成近似随机写，leader 选举和元数据同步的时间也随分区数上升。真出故障要重选 leader 时，几千个分区逐一切换，恢复时间从几秒变成几分钟。
怎么避：按当前峰值的 1.5–2 倍开，单 broker 分区总数（含副本）控制在 2000–4000 内。真的不够用了，靠加 broker 横向摊薄比在一台机器上堆分区健康得多。开新 topic 前先跑一遍压测，拿自己业务的消息体和批大小去测单分区吞吐，别照抄网上那个理想值。
为什么坑：常见于三台机器跑 RF=3、或者手动做过分区重分配之后。表面看副本数是 3，实际这台机器一挂，整个分区的所有副本一起消失，数据真的没了——而你在监控上看到的 UnderReplicatedPartitions 可能还是正常的。
怎么避：开启机架感知（broker.rack），让 Kafka 在分配副本时把同分区的副本分散到不同机架/节点；扩容或重分配后，用分区分布描述命令人工抽查几个关键 topic，确认副本确实分散。千万别为了"数据均衡"手动把多个副本挪到同一台高配机器上。
为什么坑：新手看机器有 128G 内存，就想当然给 Kafka 分 32G 堆。结果 page cache 只剩几十 G，热点数据装不下，消费和副本追赶频繁落到磁盘，IOPS 飙升，同时大堆带来的 GC 停顿又进一步拖慢进程——性能和稳定性一起掉。
怎么避：堆给 4–8GB（量大、压缩重、连接特别多的可以适当上调，但仍以 8–12GB 为上限），剩下的物理内存全留给操作系统。同时把机器上其他吃内存的服务迁走，broker 机器上除了 Kafka 和轻量监控 agent，别装别的。上线后持续观察缓存命中率和磁盘读速率，落到磁盘的读越少越好。
为什么坑：磁盘剩余空间告警是最容易被设置的，但真正出事前往往先体现在副本层面：欠副本分区数悄悄从 0 变成几十、ISR 频繁伸缩、请求处理器空闲率跌到 0.5 以下。等你看到磁盘快满或者客户端开始报错时，问题往往已经积累了一段时间。
怎么避：最低限度把这几项设成硬告警：欠副本分区数（大于 0 立即告警）、低于最小 ISR 数的分区数、ISR 伸缩频率、请求处理器 / 网络处理器平均空闲率。再加一条：单 broker 分区数突增（通常意味着有人在手动重分配或者某台机器重启后大量 leader 涌进来）。这五条配上，八成的集群故障能在业务感知之前被发现。
为什么坑：为了"高可用"把三个副本分到三个可用区，写入要跨区同步两次，延迟从个位数毫秒涨到十几甚至几十毫秒（以实际压测为准），专线带宽费用还得按 GB 或按带宽单独付。更要命的是专区链路抖动时，ISR 会周期性收缩，写入被卡住。
怎么避：主写链路的副本留在同一个可用区 / 同一机柜组，专心解决单点容错问题；容灾用异步镜像工具在另一地域建影子集群。真要做同城多活，找服务商确认专线带宽的具体规格和计费方式再签字——一万网络的裸金属和裸机集群方案里，内网和专线带宽属于按方案定制的部分（预估，以咨询为准），这部分一定要在签约前白纸黑字写清楚。
Q1：Kafka 到底吃磁盘还是吃内存？新买机器先加哪个？
A1：两个都吃，但优先级很好排——先保证 page cache，也就是先看内存；再看磁盘的顺序写和随机读能力。稳态运行时 Kafka 的读写基本都在操作系统的页缓存里完成，真正落到磁盘的是异步刷盘和滞后消费那部分。所以配机器时，内存按"能覆盖最近一两个小时热点数据量"去估，而不是按进程需要多少去估。磁盘这边别只看容量，顺序写带宽和随机读 IOPS 同样重要。真要给个建议：同样预算，优先加内存和盘数，CPU 用中端的就够，Kafka broker 本身很少把 CPU 跑满，除非你开了全链路 TLS 或者重度压缩。
Q2：一天 5TB 写入、保留 7 天，到底要买多大的机器？
A2：代入公式算一遍就有数。5TB × RF=3 × 7 天 × 压缩系数 0.5 = 52.5TB，再乘 1.3 的余量约 68TB，最后按 70% 的安全水位反推，集群大约需要 97TB 左右的裸容量。如果跑三个 broker，每个节点约 32TB，实际配 4 块 8TB 或 6 块 4TB 的盘做 JBOD 都行；扩到五个节点会更从容，每节点 20TB，分区也能铺得更开。除了上面说的磁盘计算，内存也要跟上，这种量级建议单节点 128G 起步，堆给 6–8G，其余全给缓存。
Q3：分区数是不是越多越好？我一次开 2000 个行不行？
A3：分区多了能提升并行度，但成本是非线性的。 每个分区都要维护自己的日志段、索引和内存元数据，分区数一上来，单机的顺序 append 就会被打散成很多可见的伪随机写，故障切换时 leader 选举也要批量进行，恢复时间明显拉长。行业里比较稳妥的经验是单个 broker 上分区总数（含副本）控制在 2000–4000 以内。分区数只能增不能减，所以第一次开的时候按当前峰值的 1.5–2 倍就够，后面靠加机器摊薄。真的一开始就要大，务必先压测。
Q4：副本因子设 2 够不够？想省点磁盘。
A4：能省三分之一磁盘和复制流量，但代价是一台机器都"彻底离场"不得。 RF=2 加 min.insync.replicas=2 加 acks=all 的组合下，任何一个副本抖动、或者计划内重启期间的短暂窗口，都会让写入被拒绝；而如果 min.insync.replicas 设成 1，那 acks=all 实质上退化成 acks=1，leader 没同步就宕机会真丢数据。订单、支付、CDC 这类链路老老实实用 RF=3 + min.insync=2；只有可重建的中间管道才考虑降低。省下来的磁盘钱，远不够一次故障的代价。
Q5：消息偶尔丢了，怀疑是 Kafka 的问题，怎么查？
A5：九成不是 Kafka 的锅，多半是参数组合。先确认生产者的 acks 是不是 1 或者 0——acks=1 时 leader 落盘就返回，follower 还没同步到就宕机会丢；acks=0 完全不等确认，丢了你都不知道。再往下确认 min.insync.replicas 有没有真的设对了，RF=3 却设成 1 是最典型的隐藏陷阱。第三看有没有开启非同步副本选主（应设为 false），否则落后的副本被选上来会造成位点回退。第四检查生产者重试和幂等是否开启，网络抖动时没有重试也会丢。最后别忘了——很多时候是消费端提前提交了位点。
Q6：NVMe 比 SATA SSD 贵不少，我的场景有必要上吗？
A6：判断标准不是"写入量大不大"，而是"会不会频繁发生非稳态读"。稳态写入时 SATA SSD 的顺序写 400–550MB/s 足够应付日均 TB 级；但一旦出现 follower 追赶、消费者滞后回溯、副本重建、或者分区数多到 append 被打散，就是拼随机读 IOPS 和尾延迟稳定性了，这时候 NVMe 的价值才真正体现——它买的不是跑得快，是出事时扛得住。简单划线：日均 1TB 以内、分区几百个、允许短暂消费滞后 → SATA SSD 够用；日均 TB 级以上、分区上千、经常重放历史数据，或者对故障恢复窗口要求很短 → 直接上 NVMe。
Q7：业务跨城，Kafka 要不要做异地多活？
A7：分清"同城容错"和"异地容灾"是两回事，别混着做。 主集群的副本一定要放在同一个可用区 / 同一机房内，这样 acks=all 的写入延迟才可控；把副本跨城摆放，写入每笔都要走专线两次，p99 延迟从几毫秒涨到十几甚至几十毫秒（以实际压测为准），专线抖动还会引发 ISR 周期性收缩。异地容灾应当用异步镜像（MirrorMaker 2 一类工具）建影子集群，接受秒级到分钟级的数据延迟换取地域级容灾能力。真要上之前，先把专线带宽规格、费用、延迟这三个数问清楚——这部分通常不在机器默认套餐里。
Q8：租物理机自建集群，还是直接用云厂商托管 Kafka？
A8：看团队规模和成本敏感度。托管 Kafka 省运维人力，但单价高、配快照和跨区流量另算，而且底层资源是共享的，IO 抖动不可控，遇到要深度调优参数或者定制特殊磁盘布局时也不自由。租裸金属自建，成本能压下来一大截，磁盘和网络全独占，page cache 和 IO 都由你说了算，但需要有能扛 7×24 的人。 我的建议：日写入 TB 级以内、团队只有一两个人维护 → 先托管；TB 级以上、成本敏感、或有合规与数据主权要求 → 裸金属自建。 一万网络的裸金属 E5-2698v4×2 32G/1T 官网价 ¥3999/月起，硬件故障 10 分钟自动迁移，这类场景下比托管划算得多。
把全文收成一句话：Kafka 选型的本质是"算容量、给缓存、控分区、跨分散"这十二个字——容量按"日均写入 × 副本数 × 保留天数 ÷ 压缩比"算清并留足 25%–30% 余量；内存优先给操作系统的页缓存而不是 JVM 堆；分区按目标吞吐和消费并发反推、单 broker 控制在合理区间；副本靠机架感知分散到真实不同的故障域。至于磁盘，NVMe 不是炫富，是给你的故障恢复留余量，JBOD 也永远优于 RAID，因为 Kafka 自己就有冗余。
立场我说清楚：日均 TB 级以上、且团队有运维能力的数据管道，我一律推荐租裸金属物理机自建集群，不用托管。 理由很实在——Kafka 是典型的 IO 和网络敏感型负载，共享型实例的磁盘抖动和网络争抢会让你的 p99 延迟像心电图一样跳；而物理机的独占 IO、可控多盘 JBOD、可调内网带宽，才是这个场景真正需要的。落地方面，一万网络深耕 IDC 19 年（成立于 2007 年，深圳南山总部），自营机柜最快 1 分钟上架，裸金属 E5-2620 32G/1T ¥999/月起、E5-2698v4×2 32G/1T ¥3999/月起（官网价），CPU 升 16 核 +¥400/月、内存升 128G +¥600/月、硬盘 1T 升级 +¥300/月，硬件故障 10 分钟自动迁移、7×24 中文工单平均 5 分钟响应、免费每日系统盘快照与 5–20G 防护，华南华东华北多节点也方便你把副本真正分散开。别再犹豫 Kafka 吃磁盘还是吃内存了——先把容量公式算一遍、把内存留给缓存，剩下的事按本文的配置清单走就行。
本文涉及的配置建议、价格与市场参考数据，综合自公开技术文档与一万网络官网（idc10000.net）公开的裸金属服务器、云服务器及相关方案页面，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
