3. 生产环境部署：硬件选型与基础调优
兄弟们，到了第三讲，咱们得聊聊真金白银的事了。你架构设计得再天花乱坠，最后不还得落到机房里那几台机器上？硬件选型这事儿，我见过太多人翻车了。要么是钱花了不少，性能没上去；要么是抠抠搜搜，结果线上天天告警。
今天我就把这几年的经验掰开揉碎，跟你聊聊CPU、内存、磁盘、网络到底怎么选，操作系统怎么调，JDK和JVM又该怎么配。嗯，咱们直接进入正题。
核心原则：Kafka是IO密集型应用，不是计算密集型。别把预算都砸在CPU上，磁盘和网络才是瓶颈。
3.1 硬件选型：把钱花在刀刃上
3.1.1 CPU：够用就好，别盲目堆核
Kafka的瓶颈很少在CPU上。它主要的工作就是网络读写和磁盘读写，CPU占用率通常不会太高。我个人习惯，生产环境选个24核或32核的处理器就完全够用了。
为什么会这样？你想想看，Kafka的吞吐量受限于磁盘IO和网络带宽。CPU再快，磁盘写不进去也是白搭。我在项目中遇到过，有人上了64核的机器，结果CPU利用率常年不到10%，纯属浪费。
- 推荐配置：Intel Xeon Gold 或 AMD EPYC 系列，24-32物理核心。
- 避坑：别买高频低核的消费级CPU（比如i9），服务器稳定性才是第一位的。
- 超线程：建议开启，Kafka的多线程模型能利用上。
3.1.2 内存：多多益善，但别浪费
内存是Kafka的命根子。Kafka重度依赖操作系统的页缓存（Page Cache）来加速读写。说白了，你写入的消息先落到Page Cache里，然后异步刷盘；消费的时候，如果数据还在Page Cache里，直接从内存读，速度飞快。
我建议，如果你的服务器有128GB内存，至少分64GB给Page Cache。Kafka进程本身（JVM堆）反而不用太大，8-16GB足矣。
| 场景 | 总内存 | JVM堆 | Page Cache预留 |
|---|---|---|---|
| 中小规模集群 | 64 GB | 8 GB | ~50 GB |
| 大规模集群 | 128 GB | 16 GB | ~100 GB |
| 超高吞吐场景 | 256 GB | 24 GB | ~200 GB |
我的经验：我曾经把JVM堆设到64GB，结果GC频繁导致抖动。后来发现，Kafka的Broker代码本身并不需要那么大堆，大部分数据都在Page Cache里。把堆降下来后，GC停顿几乎消失了。
3.1.3 磁盘：SSD是标配，RAID有讲究
磁盘是Kafka的基石。消息最终要落盘，消费也要读盘。这里我直接给结论：别用机械盘，必须上SSD。
为什么？Kafka的读写模式是顺序读写，机械盘顺序读写还行，但一旦遇到消费者追赶、数据重平衡等场景，随机读写就来了，机械盘直接跪。NVMe SSD的延迟是机械盘的百分之一，吞吐量是几十倍。
关于RAID，我个人的建议是：
- RAID 10：最推荐。兼顾性能和冗余，坏一块盘不影响服务。
- RAID 0：性能最好，但没冗余。如果你有副本机制（副本数≥2），可以考虑。
- RAID 5/6：不推荐。写惩罚严重，Kafka的写性能会大打折扣。
注意：千万别用RAID卡自带的缓存。Kafka自己管理刷盘策略，RAID卡缓存反而可能造成数据丢失。建议把RAID卡设置为直通模式（HBA模式）或关闭写缓存。
3.1.4 网络：万兆起步，别省这点钱
Kafka是分布式系统，Broker之间要复制数据，Producer要发消息，Consumer要拉消息。网络带宽不够，一切都白搭。
我见过最惨的一次，客户用了千兆网络，结果Producer端压测到50MB/s就上不去了，网络打满。换了万兆网卡后，直接飙到500MB/s。
- 推荐：万兆以太网（10GbE），至少千兆双网卡绑定。
- 进阶：25GbE或40GbE，适合超大规模集群。
- 延迟：尽量用低延迟交换机，避免跨机房部署。
3.2 操作系统优化：榨干硬件性能
硬件选好了，系统不调优等于白买。Linux内核参数里藏着很多性能开关，默认配置是为通用场景设计的，对Kafka来说太保守了。
3.2.1 文件系统与挂载参数
文件系统推荐XFS，别用ext4。XFS在大文件和高并发场景下表现更好。
挂载参数也很关键：
# /etc/fstab 示例
/dev/nvme0n1 /data/kafka xfs defaults,noatime,nodiratime,nobarrier 0 0- noatime/nodiratime：禁止更新访问时间，减少不必要的磁盘写入。
- nobarrier：关闭写屏障。Kafka自己保证数据一致性，不需要文件系统层再刷一次。
3.2.2 内核参数调优
这些参数我每次部署都会改，直接贴出来：
# /etc/sysctl.conf 追加以下内容
# 网络优化
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.netdev_max_backlog = 5000
# 文件系统
vm.dirty_ratio = 60
vm.dirty_background_ratio = 10
# 内存
vm.swappiness = 1
vm.max_map_count = 655360解释几个关键的：
- vm.dirty_ratio = 60：允许Page Cache中脏页占内存的60%再刷盘。Kafka喜欢攒一批再写，提高吞吐。
- vm.swappiness = 1：尽量别用swap。Kafka进程如果被换出内存，性能直接崩。
- net.core.rmem/wmem_max：增大网络缓冲区，应对高吞吐。
避坑指南：我曾经把vm.dirty_ratio设到90%，结果一次刷盘导致IO尖刺，消费者延迟飙升。后来调到60%，平衡了吞吐和延迟。
3.3 JDK版本选择与JVM调优基础
Kafka是用Java写的，JDK的选择直接影响运行稳定性。这里我踩过不少坑。
3.3.1 JDK版本：别用太新的，也别用太旧的
我个人推荐JDK 11。为什么不是JDK 8？JDK 8太老了，G1垃圾回收器在JDK 8上还有不少bug。为什么不是JDK 17？JDK 17虽然新，但有些Kafka版本还没完全验证过，生产环境求稳为主。
选JDK 11的理由：
- G1 GC在JDK 11上已经非常成熟。
- 支持ZGC（虽然Kafka不太需要）。
- 长期支持版本（LTS），维护周期长。
注意：别用OpenJDK的早期版本，建议用Adoptium（原AdoptOpenJDK）或Amazon Corretto。Oracle JDK从JDK 11开始收费了，别踩这个坑。
3.3.2 JVM调优：别乱调，先理解原理
很多新手一上来就调各种JVM参数，结果越调越糟。Kafka的JVM调优其实很简单，核心就是管好堆内存和GC。
我常用的JVM参数：
-Xms8g -Xmx8g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=20
-XX:InitiatingHeapOccupancyPercent=35
-XX:+DisableExplicitGC
-XX:+ParallelRefProcEnabled
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/kafka/dumps解释一下：
- -Xms8g -Xmx8g：堆大小设成一样，避免运行时动态调整。
- UseG1GC：G1是默认的，适合大堆内存。
- MaxGCPauseMillis=20：目标GC停顿控制在20ms以内。
- InitiatingHeapOccupancyPercent=35：堆占用到35%就开始并发标记。Kafka对象存活时间短，早点触发GC可以减少Full GC风险。
- DisableExplicitGC：禁止System.gc()，防止第三方库触发Full GC。
核心思路：Kafka的JVM堆不要太大，8-16GB就够了。剩下的内存留给操作系统做Page Cache。堆太大反而会导致GC停顿变长。
3.4 知识体系总览
下面这张图，我把本章的核心逻辑串起来了。你可以把它当作一个检查清单，部署的时候对照着来。