★ FEATURED ARTICLE 做Kafka集群这件事我发现很多人的顺序是反的上来就装包、改参数最后压测不达标再回头怀疑机器不行。实际上在Oracle Linux 8.4上搭建Kafka集群并不难难的是在“高吞吐量、实时数据流处理”这个目标下把操作系统、Broker、生产者、消费者四个层面的参数一次调对。我最近刚交付完一套基于Oracle Linux 8.4的Kafka集群从环境规划到压测调优踩了不少坑这篇文章就把完整过程拆开来讲包含部署命令、核心配置、参数取舍、压测方法和故障排查你可以直接照着操作也能避开那些文档里不会写的坑。1. 开始之前先想清楚集群规划这盘棋1.1 版本选型与节点规划Oracle Linux 8.4的系统版本不算新但胜在稳定生命周期长内核默认是UEK R75.4.x和普通RHEL 8系列完全兼容。选择它做Kafka底座主要看重的是它在生产环境里的内核稳定性以及不用折腾驱动兼容性。Kafka本身是Java应用不依赖内核特性所以UEK还是兼容内核都无所谓系统层面重点是内核参数调优这部分后面专门讲。Kafka版本我选了kafka_2.13-3.4.1搭配OpenJDK 11。为什么不用最新的3.6或4.0因为3.4这个版本在ZooKeeper模式下非常成熟社区踩坑记录多网上能搜到的运维经验也最丰富。Kafka 3.4还支持KRaft模式去ZooKeeper但我生产上没用原因很简单团队运维习惯还停留在ZooKeeper模式而且KRaft当时还在持续迭代我不想在依赖核心的组件上赌太新的东西。如果你从头搭建自己的环境可以测试KRaft但参考这篇文章时建议先按ZooKeeper模式走稳妥第一。节点规划上我强烈建议最少3个Broker节点这也是Kafka生态最经典的部署规模节点角色配置建议node1Broker Zookeeper16C / 32G内存 / 2块NVMe SSDnode2Broker Zookeeper16C / 32G内存 / 2块NVMe SSDnode3Broker Zookeeper16C / 32G内存 / 2块NVMe SSD3个节点意味着副本因子可以设置为3任何一个节点宕机数据依然有2个副本在线配合min.insync.replicas2生产写入不会中断。CPU方面Kafka是CPU密集和IO密集混合型应用压缩、解压、网络读写都会吃CPU16核起步没什么好犹豫的。存储则必须用独立数据盘不要和系统盘混在一起否则磁盘IO竞争会直接在压测时暴露出来。磁盘容量可以按这个公式估算日新增数据量 × 保留天数 ÷ 副本数再乘以1.4的缓冲系数。举例来说如果每天Topic产生800GB数据保留3天副本因子为3单台节点存储估算为800GB × 3天 ÷ 3副本 × 1.4 ≈ 1.1TB。这里还要额外预留30%给后台清理和压缩操作别把容量卡得太死。1.2 操作系统层面先做对几件事装好系统后别急着装Kafka先处理操作系统层的一堆默认值。这些默认值是为通用服务器设计的对高吞吐Kafka来说全是阻碍。第一件事是关闭透明大页Transparent Huge Pages。Kafka的日志段文件大量使用内存映射透明大页会导致内存分配延迟抖动直接表现就是请求延迟毛刺。关闭方法如下# 临时关闭 echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag # 永久生效写入 /etc/rc.d/rc.local cat /etc/rc.d/rc.local EOF echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag EOF chmod x /etc/rc.d/rc.local第二件事是调整swap策略。Kafka高吞吐的关键之一就是Page Cache也就是把热数据留在内存里让磁盘顺序读写变成内存读写。如果系统频繁触发swapPage Cache被换出性能会断崖式下跌。我把vm.swappiness调到1并不是彻底禁用swap而是告诉内核“能不用swap就尽量别用”给Page Cache留足空间。echo vm.swappiness 1 /etc/sysctl.conf sysctl -p第三件事是修改文件句柄和线程数限制。Kafka Broker需要维持大量网络连接单机上几千个文件描述符是常态除非你跑了不到3个Broker。修改/etc/security/limits.confcat /etc/security/limits.conf EOF kafka soft nofile 1048576 kafka hard nofile 1048576 kafka soft nproc 65535 kafka hard nproc 65535 EOF如果你用的systemd管理服务我后面会讲还要在service文件里显式设置LimitNOFILE1048576否则limits.conf对systemd服务不生效这是个很容易踩的坑。第四件事是磁盘挂载参数。数据盘挂载时加上noatime,nodiratime减少访问时间戳的写入。SSD的IO调度器建议设为none让NVMe走自己的硬件队列避免内核调度器干扰# 对NVMe SSD设备 echo none /sys/block/nvme0n1/queue/scheduler1.3 网络与安全配置要点Kafka节点间通信主要用两个端口Broker之间的9092默认ZooKeeper的2181。如果是多节点集群Broker之间的内网流量非常夸张尤其是副本复制和消费者拉取阶段千兆网卡基本不够用建议至少万兆。这听起来奢侈但高吞吐目标下网络是绕不过去的瓶颈。防火墙和SELinux我建议这样处理如果是内网专用环境可以直接放行指定IP段如果必须开SELinux那就要为Kafka监听端口单独配置策略但说实话很费劲生产环境里大多数团队在同等条件下直接关闭SELinux。我倾向于更务实的方案用firewall-cmd做白名单放行firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.0.0.0/24 port port9092 protocoltcp accept firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.0.0.0/24 port port2181 protocoltcp accept firewall-cmd --reload特别要注意的是advertised.listeners配置。Kafka客户端连接的是advertised.listeners里暴露的地址不一定是Broker本机的网卡IP。很多新手在这里把地址配成了localhost客户端当然连不上。多网卡环境下我会明确指定数据网卡IP不要让Kafka自己去猜。2. 部署Kafka Broker从解压到开机自启2.1 安装JDK并部署二进制包Oracle Linux 8.4的Yum源里有OpenJDK直接装yum install -y java-11-openjdk-devel java -version注意装的是-devel版本不只是JRE。Kafka启动时需要完整的JDK工具链某些监控脚本也要用到jconsole、jstack这些工具。Kafka安装包从官网下载二进制压缩包这里有一个小建议不要用发行版自带的Kafka包版本通常滞后而且打包路径很乱出了问题没法对照官方文档。我习惯把Kafka装在/opt/kafka数据目录放在/data/kafka日志目录放在/data/kafka/logs路径规划清晰后续维护少很多麻烦。# 创建专用用户 useradd -r -s /sbin/nologin kafka mkdir -p /data/kafka/logs chown -R kafka:kafka /data/kafka # 解压到 /opt/kafka tar -zxvf kafka_2.13-3.4.1.tgz -C /opt/ mv /opt/kafka_2.13-3.4.1 /opt/kafka mkdir -p /opt/kafka/logs chown -R kafka:kafka /opt/kafka2.2 server.properties逐项拆解每个Broker节点的/opt/kafka/config/server.properties是核心配置文件我的参考配置如下broker.id1 listenersPLAINTEXT://10.0.0.11:9092 advertised.listenersPLAINTEXT://10.0.0.11:9092 log.dirs/data/kafka/data num.network.threads6 num.io.threads16 socket.send.buffer.bytes1024000 socket.receive.buffer.bytes1024000 socket.request.max.bytes104857600 num.partitions12 default.replication.factor3 offsets.topic.replication.factor3 transaction.state.log.replication.factor3 transaction.state.log.min.isr2 log.retention.hours72 log.segment.bytes1073741824 log.retention.check.interval.ms300000 auto.create.topics.enablefalse unclean.leader.election.enablefalse逐个说下关键项和我的调参逻辑broker.id必须全局唯一这个不用解释。listeners和advertised.listeners我直接写内网IP避免Kafka在启动时自动解析主机名出错。如果你用主机名必须在/etc/hosts里写好映射否则跨节点通信时解析不到IP各种超时满天飞。log.dirs是日志数据目录可以配置多个路径用逗号分隔。Kafka会把不同分区的数据分散到多个目录相当于软件层面的磁盘条带化。如果节点上有多块数据盘我建议都用上吞吐会有可感知的提升。但是要注意不能把Page Cache所在的系统盘混进来。num.network.threads和num.io.threads这两个参数后面优化章节会细说。这里先按6和16配置实际压测后再微调。socket.send.buffer.bytes和socket.receive.buffer.bytes我调大到了1MB左右这个参数影响网络吞吐默认值偏保守。num.partitions12是新建Topic的默认分区数。分区数不是越多越好每个分区会占用一定的文件句柄和内存而且分区太多会导致分区leader分布不均。12个分区在3节点集群上每个节点平均4个leader分布比较均衡。官方建议分区数不超过Broker数 × 磁盘吞吐系数什么场景配多少分区后面压测部分再讲。auto.create.topic.enablefalse是我强烈建议关掉的参数。谁也不想某一个客户端手滑往不存在的Topic发消息结果集群自动创建了一堆垃圾分区既占内存又难清理。Topic规范化创建写进发布流程比什么参数调优都重要。生产环境可靠性相关参数unclean.leader.election.enablefalse必须保留默认确保leader不会从一个落后过多的副本中选举产生宁可短暂不可用也不能丢数据。2.3 用systemd管理Broker进程直接nohup kafka-server-start.sh这种方式启动进程死了没人拉起来提交一次发布代码忘了带-daemon参数还会导致SSH挂住。我建议使用systemd统一管理实现开机自启、崩溃自动拉起、日志journal化统一采集。创建/etc/systemd/system/kafka.service[Unit] DescriptionApache Kafka Server Afternetwork.target zookeeper.service [Service] Typeforking Userkafka Groupkafka EnvironmentJAVA_HOME/usr/lib/jvm/java-11-openjdk EnvironmentKAFKA_HEAP_OPTS-Xms6g -Xmx6g ExecStart/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties ExecStop/opt/kafka/bin/kafka-server-stop.sh LimitNOFILE1048576 Restarton-failure RestartSec10 [Install] WantedBymulti-user.target这里有几个细节值得注意。Typeforking是因为kafka-server-start.sh不带-daemon时本身就会fork后台进程systemd识别主进程退出、子进程存活的状态。环境变量KAFKA_HEAP_OPTS用来控制JVM堆大小后面优化章节会展开。LimitNOFILE1048576在service文件里显式声明这就是前面提到的systemd服务不读limits.conf的坑。启动并验证systemctl daemon-reload systemctl start kafka systemctl enable kafka systemctl status kafka如果还要用ZooKeeper做协调服务同样写一个zookeeper.service。我给ZooKeeper单独限定了内存避免它和Kafka争抢堆内存[Unit] DescriptionApache ZooKeeper Server Afternetwork.target [Service] Typeforking Userkafka Groupkafka EnvironmentZOO_LOG_DIR/data/kafka/logs ExecStart/opt/kafka/bin/zookeeper-server-start.sh /opt/kafka/config/zookeeper.properties ExecStop/opt/kafka/bin/zookeeper-server-stop.sh LimitNOFILE1048576 Restarton-failure RestartSec10 [Install] WantedBymulti-user.target3. 高吞吐优化不是堆参数是理解参数3.1 Kafka高吞吐的底层来源先说清一件事Kafka的吞吐能力很大程度上不是靠JVM堆而是靠操作系统Page Cache和磁盘顺序写。Kafka消息先写入Page Cache后台再批量刷到磁盘消费者读取时优先命中Page Cache命中不了再从磁盘顺序读。这决定了高吞吐场景下的核心策略——让Page Cache尽量大、让磁盘写入尽量顺序化、让网络缓冲尽量宽裕。这也是为什么我强调JVM堆不要给太大。如果给Kafka的JVM堆分配了16GB那么留给Page Cache的内存就只剩16GB假设物理内存32GB。而Kafka的堆主要用来存放元数据、索引、请求缓冲等6GB就足够了。堆设得越大Full GC时间越长反而会把原本可以躺在Page Cache里的热数据挤出去吞吐不升反降。这一点是很多人踩过的坑。零拷贝sendfile也是Kafka高吞吐的来源之一。消费者拉取消息时数据可以从Page Cache直接通过网卡发送不经过用户态和JVM堆复制。理解这一点后你就会明白消费者消费速度的瓶颈通常不在Kafka本身而在消费端的处理逻辑和网络带宽。3.2 Broker端参数优化我调整Broker参数时遵循一个顺序先调CPU和网络线程再调Socket缓冲最后检查副本相关的参数。num.network.threads负责处理网络请求的线程数默认是3。这个参数跟Broker所在机器的核数直接相关我在16核机器上先用6因为网络线程是IO密集型给多了只会增加上下文切换。num.io.threads默认是8我设为16因为Kafka的磁盘IO操作由这些线程执行在SSD上稍微加大有助于并行处理多个分区请求。这两个参数不是越大越好压测时如果发现CPU打到90%以上说明线程数已经够用再加没有意义。queued.max.requests在网络线程和IO线程之间做缓冲默认500。如果磁盘暂时跟不上请求这个队列能兜住一定量的请求避免客户端直接超时。我只在高写入场景下调到1000数值太大反而会增加延迟。num.replica.fetchers是副本同步线程数默认1我直接调到4。这是很多调优文章容易忽略的参数。当集群有多个Topic、多个分区时Follower副本从Leader拉取数据的速度很关键。1个线程意味着所有副本的同步请求串行遇到大流量时ISR会频繁收缩。调大后单台节点上的副本同步可以并行进行配合万兆内网同步速度基本跟得上写入速度。log.flush.interval.messages和log.flush.interval.ms控制日志刷盘频率Kafka默认依赖操作系统刷盘这是对的。手动把刷盘间隔调得过短会直接废掉Page Cache的优势把随机写变成常态。保持默认或者调大刷盘间隔可靠性交给副本机制来保障这是Kafka的设计哲学。3.3 生产者参数优化生产者是Kafka吞吐的第一入口这里参数调整对吞吐量的影响最立竿见影。batch.size控制生产者批量发送的缓冲区大小默认16KB对于高吞吐场景太小。我压测时逐步调到64KB甚至128KB批量越大单次网络请求携带的数据越多单位时间能发送的消息数越高。但要注意如果Topic的消息都很小批次可能凑不满就要发送这时候光调batch没效果还得配合linger.ms。linger.ms控制消息在缓冲区等待的时间默认0也就是有消息就立刻发这样batch基本形同虚设。我调成10到20毫秒让生产者多花十几毫秒积攒一个批次。这是吞吐和延迟的经典权衡高吞吐场景下20ms的额外延迟完全可接受换来的是吞吐量可能翻倍。你可以观察压测结果逐步调整我的经验是batch.size65536, linger.ms10是一个不错的起点。compression.type对吞吐的提升异常明显。消息压缩后网络传输量大幅下降CPU换带宽非常划算。我生产环境用的lz4压缩速度快、CPU开销低压测中相比不压缩大约有30%以上的吞吐提升。如果消息内容重复度高zstd压缩率更好但CPU开销略高建议压测对比后再决定。acks和retries是最需要权衡的一组参数。acks1时生产者只要leader写入成功就返回吞吐最高但leader宕机时可能丢消息。acksall时所有ISR副本都写入才返回可靠性最高吞吐会低一些。我压测后发现在内网环境、副本同步正常时acksall配合min.insync.replicas2的吞吐下降并不显著为了数据安全我选了acksall。这里给一个参考配置acksall retries3 batch.size65536 linger.ms10 compression.typelz4 max.in.flight.requests.per.connection5 enable.idempotencetruemax.in.flight.requests.per.connection5允许客户端在未收到确认前发送最多5个请求对吞吐有利。如果你同时开了幂等性乱序问题由Kafka自身解决不用担心多次重试导致消息顺序错乱。3.4 消费者参数优化消费者端吞吐优化容易被忽视但消费速度上不去最后就是Lag堆积整个实时链路变成假实时。fetch.min.bytes默认1字节意味着Broker有一点点数据就返回这会导致消费者频繁发起拉取请求网络往返开销巨大。我设为1KB甚至4KB让Broker攒够一批数据再返回。配合fetch.max.wait.ms500即使数据量不够最多等500毫秒也会返回兼顾了延迟。max.partition.fetch.bytes控制单个分区单次拉取的最大字节数默认1MB对高吞吐场景勉强够用。如果业务消息体量大建议调大到2MB。这里要注意总值等于max.partition.fetch.bytes乘以分区数如果分区多单次拉取会使用大量内存。enable.auto.commitfalse是我一直坚持的配置。自动提交虽然省事但可能在消息处理崩溃后造成数据丢失或者处理超长任务时被阻塞导致rebalance。手动提交虽然复杂一点但能把提交时机和消费完成绑定防止重复消费和数据丢失。都做实时数据流了这点可靠性投入不能省。消费者组的消费者数量不要超过分区的数量。比如Topic有12个分区你起了16个消费者那4个消费者会一直空转浪费资源。消费者数量最好等于分区数或者略少于分区数。如果消费速度跟不上优先考虑扩展分区而不是堆消费者。3.5 一套可以直接抄的组合方案结合上面的分析整理一套我实测下来稳定且吞吐表现不错的参数组合位置参数值说明Brokernum.io.threads16磁盘IO并行度Brokernum.network.threads6网络线程数Brokernum.replica.fetchers4副本拉取并行度Brokersocket.send.buffer.bytes1024000Socket发送缓冲Brokersocket.receive.buffer.bytes1024000Socket接收缓冲Producerbatch.size65536批量大小64KBProducerlinger.ms10等待积攒批次Producercompression.typelz4启用压缩Produceracksall高可靠性Consumerfetch.min.bytes4096攒批拉取Consumerfetch.max.wait.ms500最大等待时间Consumerenable.auto.commitfalse手动提交这套配置在我的3节点16C/32G环境下单Topic双分区压测生产吞吐稳定在每秒30万条左右1000字节消息P99延迟控制在80ms以内。当然每套环境不一样务必以压测数据为准。4. 压测与瓶颈定位性能只能说能测才算数4.1 官方压测工具用法Kafka自带的性能测试脚本是调优必备一个是kafka-producer-perf-test.sh一个是kafka-consumer-perf-test.sh。Kafka 3.x版本里消费压测脚本已经独立出来了不要再用老文章里的kafka-consumer-perf-test参数版本不同命令差别很大。生产压测我用的命令bin/kafka-producer-perf-test.sh \ --topic perf-test \ --num-records 5000000 \ --record-size 1000 \ --throughput -1 \ --producer-props bootstrap.servers10.0.0.11:9092,10.0.0.12:9092,10.0.0.13:9092 \ batch.size65536 linger.ms10 compression.typelz4 acksall--throughput -1表示不限制吞吐上限跑出当前配置下的最大能力。--record-size 1000模拟1KB消息这是最常见的数据体量。压测结束后脚本会输出每秒消息数、每秒数据量和延迟分位数这三项是判断性能的核心指标。消费压测命令bin/kafka-consumer-perf-test.sh \ --bootstrap-server 10.0.0.11:9092,10.0.0.12:9092,10.0.0.13:9092 \ --topic perf-test \ --messages 5000000 \ --group perf-consumer-group \ --threads 8这里注意--threads是消费线程数不是消费者组实例数。消费压测主要看消费吞吐是否跟得上生产吞吐如果消费速率明显低于生产速率就要检查消费者配置和网络带宽了。4.2 读懂压测结果的三个关键点第一个关键点是延迟分位数。脚本会输出50th, 95th, 99th百分位延迟我通常会额外关注P999因为实时流处理场景很难容忍偶发长尾延迟。P99在80ms以内算健康如果P99远高于P50说明存在明显的周期性问题优先怀疑GC停顿或磁盘IO抖动。第二个关键点是吞吐量有没有达到一个相对平稳的平台。如果你不断调大生产者的batch.size吞吐一直在涨说明还没到瓶颈如果涨到某个值后开始回落说明缓冲设置已经过度增加了GC压力和内存占用这时候要停下来找其他瓶颈。第三个关键点是对比单分区和全分区的吞吐。先测--topic perf-test这个Topic只有1个分区再测有12个分区的Topic如果分区增加后吞吐没有相应提升说明瓶颈在节点网络或CPU而不是分区并行度。如果提升了说明当前并行度还不够可以继续增加分区。4.3 性能瓶颈定位思路压测不达标时你要有一套系统的定位方法而不是盲目改参数。先用top看CPU。如果CPU使用率已经接近饱和再看看是用户态还是内核态。用户态高大概率是压缩解压和GC开销考虑降低压缩级别或者换压缩算法内核态高大概率是网络和IO中断过多考虑加大socket缓冲或者检查网卡多队列。如果CPU不高但吞吐上不去重点检查磁盘。用iostat -x 1看磁盘%util和await。如果磁盘长时间在95%以上说明存储是瓶颈。Kafka是顺序写SSD的连续写能力通常在1GB/s以上如果达不到看看是不是文件系统挂载参数有问题或者数据目录跨盘分布不均匀。如果磁盘和CPU都很健康那就是网络瓶颈。用iperf3或者系统级的sar -n DEV 1看网卡流量是否接近带宽上限。我遇到过千兆网卡跑满导致吞吐上不去的情况后来换了万兆网卡问题直接消失。这里再强调一下JVM的检查。压测过程要盯着GC日志我通常开启-Xlog:gc*:gc.log并定期检查Full GC次数。如果Full GC频繁说明堆太小或堆内对象异常如果老年代持续增长就要排查是否有未释放的缓存进入了堆。Kafka的JVM堆参数我建议用较小的固定值6GB到8GB剩下内存全部留给Page Cache。5. 常见故障排查与日常运维实录5.1 高频故障速查现象可能原因排查解决生产者报TimeoutExceptionISR副本数不足acksall时等待副本超时检查Broker是否有节点宕机查看ISR列表是否只剩leader消费者反复rebalanceSession超时时间太短消费处理耗时长于session.timeout.ms调大session.timeout.ms和max.poll.interval.ms跨节点连接失败advertised.listeners配置成localhost或错误IP检查advertised.listeners确保客户端能访问该地址磁盘空间不停涨log.retention.hours太大或Topic消息量大用kafka-log-dirs查看目录分布调整保留策略分区leader频繁切换磁盘IO抖动导致心跳超时检查磁盘await优化存储性能部分分区不可用磁盘满或Broker崩溃后未恢复df -h检查磁盘查看server.log中详细报错消费Lag持续增长消费者吞吐跟不上生产吞吐或分区数少于消费者数增加分区数优化消费者端fetch参数5.2 两个印象深刻的排查记录先说一个ISR频繁收缩的问题。某次压测刚开始生产端频繁报NotLeaderOrFollowerException我查看Topic的describe信息发现ISR列表不断变化。一开始怀疑是Broker负载太高后来用iostat -x一看复制数据时磁盘%util飙到100%而数据盘用的是普通SATA盘根本扛不住多个分区的复制IO。后来把数据盘换成NVMe SSDISR稳定了同样配置下吞吐提升了一倍多。这件事让我坚定了一个原则Kafka集群的数据盘必须用SSD最好NVMe磁盘性能决定吞吐下限。另一个是生产者和消费者不在同一个网段的场景。Broker本身在同一内网但生产客户端在另外一个网段网络要经过三层设备。压测时吞吐始终上不去用sar看到网络包量正常但重传率异常高。排查后发现是跨网段通信时TCP窗口缩放有问题Broker端的net.ipv4.tcp_window_scaling被关了。开启后吞吐恢复正常。网络参数有时比Kafka自身参数更影响吞吐这是很多人忽略的盲区。5.3 日常巡检的监控指标与命令Kafka的JMX指标是判断集群健康度的第一手资料重点关注这几项BytesInPerSec和BytesOutPerSec流入流出速率用来自定义告警阈值UnderReplicatedPartitions小于副本因子的分区数正常应为0IsrShrinksPerSec和IsrExpandsPerSecISR收缩扩张频率频繁波动说明副本同步不稳定RequestHandlerAvgIdlePercent请求处理线程空闲率如果长期低于30%说明IO线程吃紧LogFlushRateAndTimeMs日志刷盘频率和时间异常偏高说明磁盘IO有问题不用特意搭一套监控系统的话可以用JMX暴露方式配合现有监控。在kafka-server-start.sh里添加export JMX_PORT9999然后用jconsole连接Broker IP的9999端口查看指标。生产上更推荐用Prometheus的JMX Exporter方式采集但那是另一个话题了这里不展开。日常巡检命令也很重要# 查看Topic分区leader分布 bin/kafka-topics.sh --bootstrap-server 10.0.0.11:9092 --describe --topic perf-test # 查看消费者组Lag bin/kafka-consumer-groups.sh --bootstrap-server 10.0.0.11:9092 --describe --group my-group # 查看日志目录磁盘占用 bin/kafka-log-dirs.sh --bootstrap-server 10.0.0.11:9092 --describe --topic-list perf-test我一般每天定时跑一次消费者组Lag检查任何Topic的Lag超过阈值就触发人工介入这套机制帮我们提前发现了好几次潜在故障。最后分享一个实际调试中的体会如果你打算在高吞吐和可靠性之间找平衡先把底层存储和网络做对再谈参数调优参数里最见效的往往是batch.size、linger.ms、compression.type和num.replica.fetchers这几个但最终验证效果还是绕不过一遍又一遍的压测。另外如果能给Kafka单独配一块NVMe SSD承载数据目录这个决定会在你未来每一次压测和线上高峰中得到回报。
阅读完成 · 觉得有帮助？
