2. 硬件选型与OS调优
Kafka的性能天花板，其实在买服务器那天就定下了。你后面再怎么调JVM、改参数，都只是在硬件划定的圈子里跳舞。我这些年帮人排查过不少Kafka集群问题，有一半以上根因都能追溯到硬件选型失误或者OS层面没做对。
这一章，咱们就把CPU、内存、磁盘、网络、内核参数这五块硬骨头啃下来。嗯，都是实战里绕不过去的坎。
核心观点：Kafka是IO密集型+内存密集型的混合体。CPU不是瓶颈，但选错了会浪费钱；磁盘是命门，选错了直接崩；内核参数是最后一道防线，不调等于裸奔。
1. CPU选型策略：别在核心数上花冤枉钱
很多人一上来就问：Kafka需要多少核？我的回答是：够用就行，别堆核。Kafka的瓶颈几乎从来不在CPU上。它大部分时间在等磁盘IO、等网络、等内存拷贝。
我个人习惯选高频CPU，而不是多核。举个例子，2.5GHz的16核，和3.0GHz的8核，我选后者。为什么？因为Kafka的请求处理线程（网络线程+IO线程）数量有限，核心多了根本跑不满，反而单核频率高能降低请求延迟。
我的经验：生产环境推荐 8~16 核，主频 2.5GHz 以上。如果预算允许，选 Intel Xeon 或 AMD EPYC 系列。别买低功耗的Atom系列，那玩意儿跑Kafka会卡到你怀疑人生。
另外要注意超线程（Hyper-Threading）。我建议关掉。超线程在Kafka场景下收益极低，反而可能因为共享L1/L2缓存导致性能抖动。嗯，这个坑我踩过。
2. 内存分配原则：给页缓存留足口粮
Kafka的内存分配有个铁律：JVM堆内存不要超过系统内存的一半。剩下的留给操作系统做页缓存（Page Cache）。
为什么？因为Kafka读写数据时，数据先走页缓存。生产者发来的消息写到页缓存就返回ack了，消费者读消息也是从页缓存读。页缓存命中率高，磁盘IO就少，延迟就低。
我一般这样分：
| 系统总内存 | JVM堆内存 | 页缓存（剩余） | 适用场景 |
|---|---|---|---|
| 32 GB | 8~10 GB | ~20 GB | 中等流量，消息体较小 |
| 64 GB | 16~20 GB | ~40 GB | 高吞吐，消息体较大 |
| 128 GB | 24~32 GB | ~90 GB | 超高吞吐，大集群 |
注意：JVM堆内存不要超过32GB。超过32GB，JVM会启用压缩指针（Compressed OOPs）失效，内存寻址效率下降。我见过有人给Kafka分了48GB堆，结果GC停顿飙到十几秒，整个集群都跟着抖。
3. 磁盘选型：SSD vs HDD，别犹豫
这个问题其实没什么好纠结的。生产环境，必须用SSD。HDD只适合测试环境或者对延迟完全无感的场景。
你想想看，Kafka的吞吐量受限于磁盘顺序读写速度。一块SATA SSD顺序写能到500MB/s，NVMe SSD能到3GB/s以上。而HDD呢？顶天200MB/s，而且随机IO一上来直接崩到几十MB/s。
我推荐：
- 首选：NVMe SSD（如Intel P5510、Samsung PM9A3）
- 次选：SATA SSD（如Samsung 870 EVO）
- 不推荐：任何HDD，包括15K SAS盘
避坑指南：我曾经在一个项目里用了消费级SSD（比如普通家用盘），结果跑了三个月，盘就写废了。Kafka的写入量非常大，一定要选企业级SSD，带断电保护（PLP）的那种。否则突然掉电，数据可能丢。
另外，磁盘RAID怎么配？我建议用JBOD（直通模式）或者RAID 0。别用RAID 5/6，那玩意儿写惩罚太严重，Kafka的冗余靠副本机制，不需要RAID来保护。
4. 网络带宽规划：万兆是底线
Kafka是网络IO大户。生产者发消息、消费者拉消息、副本同步，全走网络。网络带宽不够，整个集群的吞吐量就被卡死了。
我算过一笔账：一个10节点集群，每台机器写500MB/s，副本数3，那网络总流量大约是 500MB/s × 3（副本）× 2（读写双向）≈ 3GB/s。千兆网卡（1Gbps ≈ 125MB/s）根本扛不住。
所以：
- 小集群（3~5节点）：万兆（10Gbps）起步
- 中大型集群（10+节点）：25Gbps 或 40Gbps
- 超大规模：100Gbps
关键点：网卡队列数要够。多队列网卡（如Intel X710）配合RPS/RFS，能把网络中断分散到多个CPU核心，避免单核打满。我习惯把网卡队列数设为CPU核心数的一半。
5. Linux内核参数调优：把系统调成Kafka的形状
硬件买好了，系统装好了，别急着跑Kafka。先改内核参数。不改的话，默认配置是为通用场景设计的，对Kafka这种高IO、高并发的应用很不友好。
下面这几个参数，我每次部署Kafka必调：
5.1 vm.dirty_ratio 与 vm.dirty_background_ratio
这两个参数控制脏页（dirty pages）的回写策略。Kafka大量使用页缓存，如果脏页比例太高，系统会一次性刷大量数据到磁盘，导致IO尖刺。
我推荐：
# 脏页占内存比例达到10%时，后台开始刷盘
vm.dirty_background_ratio = 5
# 脏页占内存比例达到30%时，进程自己刷盘（会阻塞）
vm.dirty_ratio = 20为什么这么配？默认值分别是10%和30%，对于Kafka来说太高了。我曾经遇到一个集群，默认配置下，每30秒出现一次IO毛刺，延迟从5ms飙到500ms。调低这两个值后，毛刺消失了。
5.2 net.core.somaxconn
这个参数控制TCP连接监听队列的最大长度。Kafka的Acceptor线程接收新连接时，如果队列满了，新连接会被拒绝。
net.core.somaxconn = 1024默认是128，对于高并发场景完全不够。我建议至少设到1024，如果客户端连接数特别多，可以设到2048。
5.3 其他必调参数
| 参数名 | 推荐值 | 说明 |
|---|---|---|
| vm.swappiness | 1 | 尽量少用swap，Kafka进程swap出去就废了 |
| net.ipv4.tcp_rmem | 4096 87380 16777216 | TCP读缓冲区，增大到16MB |
| net.ipv4.tcp_wmem | 4096 65536 16777216 | TCP写缓冲区，增大到16MB |
| net.core.rmem_max | 16777216 | 最大读缓冲区 |
| net.core.wmem_max | 16777216 | 最大写缓冲区 |
| fs.file-max | 1000000 | Kafka会打开大量文件句柄（日志段文件） |
重要：改完参数后，执行 sysctl -p 使其生效。但有些参数（如vm.dirty_ratio）需要重启才能完全生效。我建议在部署Kafka之前，先把这些参数写到 /etc/sysctl.d/99-kafka.conf 里，确保重启后还在。
6. 文件系统与挂载选项
文件系统我推荐XFS，不要用ext4。XFS在大文件、高并发场景下表现更好，而且支持更大的单个文件（Kafka的日志段文件可能很大）。
挂载选项也很关键：
# /etc/fstab 示例
/dev/nvme0n1 /data/kafka xfs defaults,noatime,nodiratime,nobarrier 0 0- noatime/nodiratime：禁止更新文件访问时间，减少不必要的磁盘写入
- nobarrier：禁用写屏障（如果磁盘有独立缓存电池保护，可以开这个提升性能）
我的习惯：每块SSD单独挂载一个目录，Kafka的data.dir配置多个目录，用逗号分隔。这样Kafka会自动把不同分区的数据分散到不同磁盘上，提升并行IO能力。
7. 小结：一张清单搞定硬件与OS调优
嗯，内容不少。我帮你整理成一张检查清单，照着做就行：
- CPU：8~16核，主频≥2.5GHz，关超线程
- 内存：JVM堆 ≤ 系统内存的一半，剩余给页缓存
- 磁盘：企业级NVMe SSD，JBOD模式，XFS文件系统
- 网络：万兆起步，多队列网卡
- 内核参数：调vm.dirty_ratio、somaxconn、swappiness、TCP缓冲区
- 挂载选项：noatime,nodiratime,nobarrier