把Kafka从测试环境挪到生产环境最需要转变的一个思路就是跑通和跑稳是两码事。docker-compose 起个单机 Kafkatopic 一建、消息一发看起来一切正常但一旦碰上流量波动、磁盘故障、消费者堆积生产集群的各种问题马上就会暴露出来。这篇文章作为 Kafka 系列的第 4 篇重点讲生产环境规划部署——从集群规模怎么算、硬件怎么选到操作系统和 Broker 参数怎么调再到监控告警怎么搭、部署时最容易踩哪些坑方向基本按照从 0 到 1 上线的顺序来走。如果你正准备把 Kafka 真正接到线上或者已经在维护一套集群但总觉得心里没底这篇应该能帮你把思路理顺。1. 部署前先做容量规划别等流量上来再改集群1.1 从业务流量反推存储和带宽很多人规划 Kafka 集群时第一反应是问“要几台机器”这个顺序其实反了。你连流量都不知道怎么知道机器够不够容量规划的第一步永远是估算业务侧的消息流量。我通常会让业务方提供三个数消息的峰值写入速率单位用 MB/s 更直观不要只给条数因为单条消息大小差异能差出几个量级消息需要保留多久也就是 retention 天数副本因子预计设多少生产环境一般 3 副本。有了这三个数存储量就好算了。单副本存储量 峰值写入速率 × 86400 秒 × 保留天数再乘副本因子最后加一个 20% 的预留用于应对消息大小波动和 compaction 带来的临时空间需求。举个例子业务给的消息峰值是 20MB/s打算保留 3 天副本因子 3那么单副本存储是 20 × 86400 × 3 5,184,000MB约 5.06TB。三个副本就是 15.19TB再加 20% 余量大概要准备 18.2TB 的可用存储。注意这是裸容量如果用了 RAID10 还要把冗余算进去。带宽也要提前算。写入流量 20MB/s副本同步还要产生 20MB/s × 2 的内部流量这就有 60MB/s下游消费者如果按同样的速率读加上网络协议开销轻松突破 100MB/s。这个量级下千兆网卡已经很悬了生产环境建议直接上万兆或者至少网卡 bonding 做链路聚合。我见过不止一次因为 MB/s 和 Mb/s 没换算清楚上线后才发现带宽被打满的案例。1.2 CPU、内存、磁盘、网卡怎么配比才不浪费Kafka 的硬件选型有个核心原则你买的不是一台 Java 应用服务器而是一台以磁盘顺序读写为核心、依赖操作系统 PageCache 的存储引擎。所以硬件配比不能按普通 Web 服务的思路来。先说说最容易翻车的内存。我曾经见过有人把一台 64G 内存的机器给 JVM 堆分了 48G结果 Kafka 的吞吐反而上不去GC 频繁到把请求处理线程卡死。Kafka 官方也明确说过堆内存不需要太大因为大量读写其实发生在 PageCache 里——消息从网络进来先落 PageCache消费者读的时候也是从 PageCache 走JVM 堆只是用来管理分区的元数据、同步状态这些轻量结构。堆设太大GC 反而成了瓶颈。我的建议是堆内存给 6~8G 足够剩下全部留给操作系统做 PageCache这才是 Kafka 能跑满磁盘性能的关键。CPU 方面Kafka 本身不是 CPU 密集型应用但对核数比较敏感因为网络线程和 IO 线程都要占核。入门配置 8 核就够跑标准生产环境建议 16 核以上。磁盘是 Kafka 的核心资源机械盘也并不是不能用Kafka 顺序写对机械盘很友好SSD 带来的提升主要在处理随机读和高 IOPS 场景。如果不想在 RAID 上花太多心思就用多块盘做 JBOD 配合 Kafka 自身的副本机制会比 RAID5 靠谱得多。这里给一份我习惯用的参考配置表大家可以根据自己的规模按比例伸缩规模Broker 数内存CPU磁盘网卡入门/测试332G8 核4×2TB SATA千兆标准生产3~564G16 核6×4TB SSD 或 SATA万兆大规模5128G32 核8×8TB SSD万兆1.3 先定分区数还是先定 Broker 数这个话题我放在容量规划最后说因为很多人会在第一步就卡住到底需要多少个分区、多少台 Broker正确的思考路径应该是先根据目标吞吐定分区数再反推 Broker 数量。分区的意义在于并行度消息写入一个分区本质上是单线程顺序写单个分区的吞吐上限取决于磁盘顺序写性能和网络带宽。对一个中等配置的机器来说单个分区跑几十 MB/s 是正常的。如果你的目标峰值是 200MB/s单分区按 30MB/s 乐观估算至少需要 7 个分区。但分区数绝不是越多越好。每个分区都对应一组日志段文件和索引文件文件句柄会涨leader 切换和消费者 Rebalance 的时间也会随着分区数增加而拉长。业界有个经验值单个 Broker 上的分区总数尽量控制在 2000 以内超过这个量级不是不能跑但维护成本和故障恢复时间都会显著上升。Broker 数量则要看两件事一是总吞吐二是副本分布。3 副本的集群至少要 3 台 Broker否则副本挤在同一台机器上容灾意义就打了折扣。吞吐上如果单 Broker 能扛 500MB/s 的读写合计流量那么 200MB/s 写入加 200MB/s 读取的负载3 台就已经有富余。我的建议是起步别少于 3 台也别为了省钱把两个 Broker 装在一台物理机上生产环境要么不搞要搞就按高可用来。2. 操作系统与 JDK 调优Kafka 的稳定性下限在这2.1 必改的内核参数和文件句柄Kafka 部署到生产环境操作系统层面的调优是最容易被跳过的。很多人的习惯是装完 JDK 解压 Kafka 就启动直到线上出现“too many open files”或者诡异的 GC 崩溃才开始补课。文件句柄是第一个要改的。Kafka 每个分区会打开日志段文件、索引文件还有网络连接也算句柄一台 Broker 上几千个分区很常见所以默认的 1024 远远不够。至少要设到 100000稳妥起见建议 65535 以上用 systemd 启动的话还要注意 service 文件里的 LimitNOFILE 有没有跟着改。再看看内核参数。我会把下面这几项写进 sysctl.conf然后 sysctl -p 生效vm.swappiness1 vm.max_map_count262144 net.core.somaxconn4096 net.ipv4.ip_local_port_range1024 65535vm.swappiness 从默认的 60 降到 1目的是让系统尽量少用 swap。Kafka 依赖 PageCache如果内存里的页面频繁被换到磁盘读写性能会直接雪崩。不过我不太建议设成 0内核在内存极端紧张时完全没有 swap 兜底OOM 杀进程的风险反而更高设 1 是权衡。vm.max_map_count 是给 Java 进程的 mmap 数量上限。Kafka 的日志段和索引文件大量使用 mmap默认的 65530 在分区多的时候很容易触顶表现为进程崩溃或者 mmap 报错。设到 262144 是参考 Elasticsearch 的常见做法Kafka 同样需要。2.2 JVM 堆内存与 GC 怎么设置Kafka 自带的启动脚本里默认的堆内存只有 1G这个值在测试环境够用生产环境必须改。我前面说了堆不是越大越好6~8G 是一个比较稳的范围除非你的 Broker 上分区特别多或者使用了大量事务否则不需要更大。GC 选择上新版本 Kafka 用 G1 是主流配合下面这套参数export KAFKA_HEAP_OPTS-Xms6G -Xmx6G export KAFKA_JVM_PERFORMANCE_OPTS-server -XX:UseG1GC -XX:MaxGCPauseMillis20 -XX:DisableExplicitGC-Xms 和 -Xmx 设成一样避免 JVM 运行中动态扩缩堆引发额外停顿。-XX:DisableExplicitGC 是为了防止某些客户端或第三方库调用 System.gc() 触发 Full GC这个坑我在早期踩过业务侧一旦有人代码里写了 System.gc()整个集群的响应就会周期性抽搐。上线之后要盯 GC 日志。Kafka 的 GC 停顿如果超过 1 秒消费者端的超时就会批量触发表现为 Rebalance。建议启动脚本里加上 GC 日志参数方便事后排查export KAFKA_JVM_PERFORMANCE_OPTS$KAFKA_JVM_PERFORMANCE_OPTS -Xlog:gc*:file/data/kafka/logs/gc.log:time,uptime,level,tags:filecount10,filesize100m2.3 磁盘挂载和文件系统选择磁盘这块大部分人会忽略挂载方式。Kafka 的 log.dirs 支持配置多个目录多个目录之间用逗号分隔Kafka 会自动把分区分布到不同目录上。这本来是个非常好的负载均衡机制但如果有人图省事把两块盘做成了 LVM 再挂到一个目录上那么坏一块物理盘会导致整个挂载点失效Kafka 可能会把挂在同一个文件系统下的所有分区都标记为离线这就不划算了。文件系统我一般用 ext4 或者 xfs两者都能满足 Kafka 的需求。挂载参数里记得加 noatime关闭 atime 更新可以减少不必要的磁盘写操作/dev/sdb1 /data/kafka/logs ext4 defaults,noatime,nodiratime 0 0还有 RAID 策略。如果你用的是机械盘尽量别用 RAID5RAID5 在写入时有校验计算开销而且数据恢复期间一旦再坏一块盘就会全部沦陷。RAID10 或者 JBOD 是更合理的选择。RAID0 虽然写入最快但一块盘挂了整个阵列完蛋除非你非常确定 Kafka 3 副本的可靠性足够兜底否则别在磁盘层把可靠性压到零。3. KRaft 还是 ZooKeeper元数据管理选型要趁早3.1 两套架构的差异和选型Kafka 的元数据管理经历了从 ZooKeeper 到 KRaft 的演进这是生产环境部署绕不开的一个决策点。传统模式下Broker 把 topic 信息、分区副本分配、Controller 选举这些元数据都放在外部的 ZooKeeper 集群里。缺点很明显多引入一个分布式系统就多一倍的运维负担ZooKeeper 本身也要部署奇数节点、处理会话超时而且 Kafka 和 ZooKeeper 的版本兼容性偶尔会把人折磨到崩溃。KRaft 模式则把元数据管理收编进了 Kafka 自身由一组 Controller 节点组成 quorum通过日志复制机制维护元数据不再需要外部 ZooKeeper。从架构上看更简洁部署和运维链路都短了而且 Controller 的选举和元数据加载速度比 ZK 模式快不少。如果你的 Kafka 版本在 3.3 及以上新集群我建议直接用 KRaft。如果已经用 ZK 模式跑了很久没有迫切诉求也可以先用着但升级路线要提前规划。这里有个选型的细节KRaft 支持 combined 模式和 split 模式。小集群比如 3 台可以把 controller 角色和 broker 角色放在同一进程里省机器大集群则建议把 controller 拆出来独立部署避免 Controller 的负载影响 Broker 的数据读写。3.2 KRaft 模式部署的几个要点KRaft 部署最大的坑在于初始化。ZooKeeper 模式只需要启动就完事KRaft 模式启动前必须先格式化存储目录生成集群元数据。命令大概是这样的kafka-storage.sh random-uuid kafka-storage.sh format -t cluster-id -c config/server.propertiesrandom-uuid 生成一个集群 ID然后 format 时把集群 ID 写进存储目录。注意这个操作只能做一次如果节点存储目录已经格式化过再次 format 会报错或者导致集群 ID 不一致。集群 ID 不一致的节点之间会互相排斥表现就是各起各的永远组不成集群。process.roles 这个参数要重点检查。combined 模式配 process.rolesbroker,controllersplit 模式中 controller 节点配 process.rolescontrollerbroker 节点配 process.rolesbroker。另外 controller.quorum.voters 要列出所有 controller 节点的 ID 和地址比如controller.quorum.voters1kf-controller-01:9093,2kf-controller-02:9093,3kf-controller-03:9093如果这个参数里的节点 ID 和实际 node.id 对不上节点之间就无法建立 quorum。3.3 从 ZK 模式迁移到 KRaft 的注意点已经跑在 ZooKeeper 模式上的集群想迁移到 KRaft不是简单改个参数重启就行。官方提供了一个迁移工具会分阶段把 ZK 里的元数据迁移到 KRaft 控制器同时保持 Broker 数据不动。这个过程中最需要注意的是迁移是单向的虽然工具支持回滚但回滚场景比较有限。我做迁移演练时的建议是至少先在测试环境完整跑一遍迁移流程。重点关注两个东西一是元数据迁移期间是否允许业务正常读写二是迁移完成后所有 topic 的分区分配是否和原来一致。确实遇到过迁移后个别分区 leader 变化导致客户端抖动的现象所以迁移窗口选在业务低峰期比较稳妥。4. Broker 核心参数配置照着这份清单核对就行4.1 网络和请求处理参数Kafka 的请求处理链路是客户端连接进来由 network thread 接包放入请求队列然后 io thread 从队列里取请求执行。这两个线程池的大小直接影响处理能力。num.network.threads 默认是 3负责接受网络连接和处理请求收发。这个值在 CPU 核数多时可以适当调大比如 8 核机器给 4~5 个。num.io.threads 默认是 8负责真正执行消息写入和读取磁盘吞吐高的时候 8 个不一定够我一般会调到 16 左右但要结合 CPU 核数线程太多上下文切换反而浪费。socket.request.max.bytes 默认 104857600也就是 100MB。这个参数定义了单个请求的最大尺寸如果业务里有大消息一定要提前调大否则消息超过这个值会直接在服务端被拒。另外有两个容易被忽略的背压参数queued.max.requests 默认 500意思是线程处理不过来时请求队列最多积压多少。积压满了之后网络层会开始阻塞客户端起到保护作用。生产环境如果观测到请求队列经常打满正确的做法是增加 io thread 或者优化磁盘性能而不是单纯把这个值调大否则只会让延迟更难看。4.2 日志段与清理策略日志段log segment是 Kafka 存储的基本单位log.segment.bytes 默认 1GB。这个参数决定了日志文件切分的大小我一般建议保持 1GB 或者更小一点不要为了减少文件数量调大到好几 GB。原因是日志段的切分会配合索引文件的加载段太大时旧数据的清理和索引重建的耗时都会变长。反过来如果段太小比如几十 MB会产生大量小文件元数据开销就很明显。清理策略主要看 log.cleanup.policy。绝大多数消息场景用 delete也就是按时间或大小删除旧日志。log.retention.hours 默认 168 小时即 7 天如果你的业务要求保留 3 天就改成 72。另一个是 log.retention.bytes按整个日志目录的总大小来限制两个策略同时配置时只要任意一个条件达到就会触发删除。这里要特别提醒一个生产环境开关auto.create.topics.enable。Kafka 默认是 true客户端发送消息到一个不存在的 topic 时Broker 会自动创建这个 topic而且用的是默认的分区数和副本因子。生产环境必须把这个参数设成 false否则业务方一旦把 topic 名拼错系统会“贴心”地创建一个单副本的 topic数据可靠性打折扣不说你还完全不知道有这个东西存在。4.3 副本同步与数据可靠性参数Kafka 的数据可靠性完全靠副本机制保证所以跟副本相关的参数我会单独拉出来说。首先是 default.replication.factor建议设 3。同时还要关注几个内部 topic 的副本因子offsets.topic.replication.factor 控制消费者 offset 存储的副本数transaction.state.log.replication.factor 控制事务日志的副本数这两个内部 topic 的默认值在部分版本里是 1 或 3生产环境至少要确保它们不小于 3否则元数据本身就是单点。然后是 min.insync.replicas这个参数控制的是生产者使用 acksall 时至少要有多少个同步副本确认写入才算成功。我建议设成 2。它配合副本因子 3 的效果是允许一台 Broker 挂掉数据仍然不会丢但如果两台同时挂写入就会失败。假如把 min.insync.replicas 设成 1那 acksall 形同虚设只要 leader 自己写成功就 ack副本没跟上照样返回成功这时候磁盘坏了数据就真丢了。还有一个谈之色变的参数unclean.leader.election.enable。默认是 false意味着当 leader 所在的 Broker 挂了之后Kafka 只会从 ISR 集合里选新的 leader。如果把这个参数设成 true那么 ISR 之外那些数据落后的副本也可能被选为 leader这样做的唯一好处是快速恢复写入代价是丢消息。生产环境我强烈建议保持 false宁可短暂不可用也不能接受数据丢失。副本拉取相关的参数里replica.lag.time.max.ms 默认 30000表示一个副本超过 30 秒没跟上最新数据就会被移出 ISR。这个值不要调太小比如设成 1000遇到瞬间的 GC 停顿或者网络抖动副本就会频繁进出 ISR反而引发 leader 切换和客户端重试。num.replica.fetchers 默认 1如果你的 topic 写入吞吐大、副本经常跟不上可以调到 2 或 3让副本拉取更快一些。4.4 内部 Topic 和客户端交互参数最后一个容易漏掉的是 group.initial.rebalance.delay.ms默认 3000。消费者组初次启动时Coordinator 会等这个时间再触发 Rebalance目的是给组里其他消费者一个陆续加入的机会避免每加入一个消费者就重新分配一次分区。如果你发现消费者组启动时频繁 Rebalance除了检查心跳参数也可以确认这个值没有被改小。还有 message.max.bytes默认约 1MB。如果你的业务里有超过 1MB 的大消息比如图片 base64 或者日志文件片段这个值要调大但要记住它只是服务端一侧的限制。生产者端的 max.request.size、消费者端的 max.partition.fetch.bytes 也要同步调整否则服务端收下了客户端反而拒收。我建议大消息场景里把这些参数统一调成一致避免互相踩坑。5. 监控告警不搭监控的生产环境等于裸奔5.1 必看的 JMX 指标与含义Kafka 的指标主要通过 JMX 暴露监控做得好不好取决于你知道该盯哪些 MBean。指标很多但生产环境真正需要重点盯的就那么几个。UnderReplicatedPartitions 是最核心的副本健康指标表示有多少分区当前处于副本落后状态。这个数长期大于 0 说明某些副本拉取跟不上要么磁盘慢要么网络有问题要么负载不均衡。OfflinePartitionsCount 则更严重表示分区所有副本都下线了直接影响读写可用性。还有一个 ActiveControllerCount正常情况下整个集群应该只有 1如果变成 0 或者大于 1说明 Controller 选举出了问题集群的元数据操作会瘫痪。吞吐相关的是 BytesInPerSec、BytesOutPerSec 和 MessagesInPerSec。这些指标主要用来和容量规划的数据对账看看实际流量是否已经接近当时的设计峰值。RequestHandlerAvgIdlePercent 和 NetworkProcessorAvgIdlePercent 反映的是线程利用率这两个值越低说明线程越忙低于 30% 的时候就要警惕了可能马上要出现处理延迟。还有一个消费者视角的关键指标消费者组的 Lag也就是消费进度落后生产进度多少。Broker 端的 JMX 不直接提供 Lag需要通过工具或者 Prometheus 的 kafka_exporter 从 group 协调器获取但它是判断业务健康度的第一指标。5.2 告警阈值怎么定才不误报告警阈值定得太灵敏会被误报淹没定得太宽松又失去意义。我的经验是分层级设置并且给关键指标加持续时间条件避免瞬时抖动就触发。UnderReplicatedPartitions 设置为持续 5 分钟大于 0 才告警因为短暂的副本落后可能是 GC 停顿或网络抖动造成的会自动恢复。OfflinePartitionsCount 则不需要持续时间一旦大于 0 立即告警这是最高优先级。RequestHandlerAvgIdlePercent 连续 5 分钟低于 30% 就告警说明请求处理线程已经过载。磁盘使用率超过 80% 给预警超过 90% 就要立即处理Kafka 需要额外的空间来执行日志删除和 compaction磁盘写满会导致 Broker 直接下线。消费者 Lag 的告警阈值最不好定因为它和业务容忍度强相关。我的做法是先用一个相对宽松的阈值比如 10000 条起步跑一段时间观察正常水位再根据业务要求收紧。告警的意义是告诉你数据没有及时被消费而不是让你天天被骚扰。下面整理了一个速查表可以直接抄指标告警条件级别UnderReplicatedPartitions 0 持续 5 分钟高OfflinePartitionsCount 0 立即严重ActiveControllerCount! 1 立即严重RequestHandlerAvgIdlePercent 30% 持续 5 分钟高磁盘使用率 80% 预警 90% 立即高Full GC 次数 1 次/分钟高消费者 Lag按业务容忍度中5.3 监控落地方式Kafka 监控的主流做法是JMX 指标通过 Prometheus 的 jmx_exporter 暴露Grafana 绘图表Alertmanager 负责告警。这套组合基本是行业标配网上也有很多现成的 Grafana Dashboard 可以导入。如果没有条件搭一整套 Prometheus至少要写一个脚本来抓 JMX 指标。Kafka 自带的工具可以一条命令拿到指标快照bin/kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.server:typeBrokerTopicMetrics,nameBytesInPerSecJmxTool 不依赖外部组件出问题时候临时拉一下指标非常方便。我曾在一个只有 3 台 Broker 的小集群上用 crontab 每 5 分钟抓一次关键指标配上简单的日志关键字告警也撑过了很长一段时间。监控系统的优先级是先有数据再谈自动化。裸奔的生产环境不是不能跑是出了问题你连定位方向都没有。6. 部署过程中常见的问题和排查思路6.1 消息过大导致生产者报错生产环境最常见的消息问题就是 RecordTooLargeException。客户端报这个错说明单条消息尺寸已经超过了某个环节的限制。排查时要同时检查 Broker 端的 message.max.bytes、topic 维度的 max.message.bytes以及生产者端的 max.request.size还要看消费者的 fetch 配置。我遇到过一个案例业务方把 5MB 的消息直接往默认配置的 Kafka 里发服务端报错后他们以为是偶发网络问题重试了三次才来找我。改完 Broker 端的 message.max.bytes 后客户端依然报错因为生产者的 max.request.size 没改。这类问题通常不是一处配置而是链路各环节都要过一遍。6.2 磁盘写满引发日志段删除失败磁盘写满是个很棘手的问题。Kafka 的日志清理并不是实时触发的删除动作每隔一段时间检查一次期间如果磁盘继续写很快就满了。满盘之后 Broker 会进入只读状态部分分区报 NotLeaderForPartition 错误消费者读不到新数据。我处理过的一个典型案例是某个 topic 的保留时间设成了 7 天但业务方实际堆积的日志量远超预期7 天前数据还没消费完磁盘就满了。当时临时措施是赶紧调小 log.retention.hours让 Broker 尽快清理旧段等磁盘使用率降下来之后再重新扩容磁盘。生产环境遇到磁盘紧张优先通过调整 retention 解决不要去手动删除日志文件。手动 rm 日志段会导致索引和日志不一致问题更大。6.3 消费者组不断 Rebalance消费者组频繁 Rebalance 是线上最影响业务的故障之一。现象是消费者频繁加入、离开组分区所有权不断移交消费基本停滞Lag 直线上升。原因一般有两种一种是消费者的处理时间超过了 max.poll.interval.ms 默认的 5 分钟。比如某条消息处理时调用了外部接口耗时非常长消费者在 poll 下次消息之前就被判定为“失联”踢出组触发 Rebalance。另一种是网络问题或 GC 停顿导致心跳超时session.timeout.ms 设得太小也会放大这个问题。排查时先看 Broker 日志里有没有成员加入、离开的记录再看监控里的 Rebalance 次数。解决方向上处理慢的要优化业务逻辑或者把 max.poll.interval.ms 调大、把 max.poll.records 调小让每次 poll 拉到的消息少一些。心跳超时的则要适当调大 session.timeout.ms同时确认客户端所在机器的 GC 是否正常。6.4 请求线程空闲率低但 CPU 不高的怪现象还有一种不太好排查的情况监控显示 RequestHandlerAvgIdlePercent 很低说明 IO 线程快忙死了但系统 CPU 使用率并不高。这通常不是 CPU 不够而是线程在等资源。最常见的原因是磁盘 IO 瓶颈。当磁盘 await 很高时IO 线程会阻塞在等待磁盘响应上CPU 反而闲着。用 iostat 看一眼 %util 基本就能确认。另一个原因是 PageCache 不足老数据需要从磁盘重新读读路径变慢拖垮了整体处理速度。这时候要检查系统内存是不是被其他进程占用了Kafka 所在机器不应该再部署其他吃内存的应用。我的排查习惯是先看 Lag 和 UnderReplicatedPartitions 这类业务相关指标再看操作系统层的 top、iostat、iftop最后翻 Kafka 的 server.log 和 gc.log。按照这个顺序来大部分问题都能在十分钟内定位。如果一上来就翻日志很容易被大量 INFO 日志淹没反而找不到根因。