如果你手里正好有一批 RHEL 7 的存量服务器想在上面搭一套 Apache Kafka 集群那真正要花心思研究的地方往往是分区机制。我在 RHEL 7 环境里帮团队调过好几套 Kafka 集群最深的体会是集群能启动只算完成了 20%剩下 80% 的性能问题几乎都集中在分区设计、副本配置和生产消费参数这三件事上。这篇文章就把我在 RHEL 7 上部署 Kafka 集群、通过分区机制把消息吞吐量与数据流处理能力拉起来的完整过程写下来包括版本选型、分区数怎么定、系统层怎么配合、压测踩坑等实操细节。1. 为什么把 Kafka 集群放在 RHEL 7 上环境准备与版本选型1.1 存量 RHEL 7 环境上该选哪个 Kafka 版本RHEL 7 的内核是 3.10.xglibc 版本也比较旧。很多人一上来就问“是不是必须升级系统才能跑 Kafka”我的经验是Kafka 2.x 系列在 RHEL 7 上非常成熟根本不用动系统。官方对 JDK 8 的兼容性一直保持得很好而 RHEL 7 通过 yum 就能直接装 OpenJDK 8这就解决了最让人头疼的依赖问题。版本选择上我通常建议 2.8.1 或者 3.3.x。如果团队没有强需求非要上用新特性我更倾向于 2.8.x。原因不是 3.x 不好而是 RHEL 7 上的脚本环境和 glibc 版本比较老新版本 Kafka 的部分 CLI 工具和启动脚本对系统的要求会高一些没必要在生产环境冒险。另一个容易忽略的点是运行模式Kafka 3.x 里 KRaft 模式已经可用但 RHEL 7 生产集群我仍然建议用 ZooKeeper 模式。KRaft 虽然省掉了 ZK 这个组件但成熟度和生态兼容性在 RHEL 7 存量环境里还没到可以闭眼上的程度。如果你是新环境可以用 2.8.1 ZooKeeper 3.6.x 的组合这个组合我实测很稳。JDK 就选 java-1.8.0-openjdkRHEL 7 仓库里直接有。装完检查一下java -versionKafka 启动脚本对 JAVA_HOME 有要求最好在 /etc/profile 里显式 export别指望系统自己找到。1.2 三节点集群的硬件与目录规划Kafka 是典型的吞吐型系统硬件规划影响非常大。我给的参考配置是 3 节点每个节点 32G 内存、两块独立的 SSD 或高速机械盘、万兆网卡。为什么是 3 节点因为 ZooKeeper 选举需要奇数节点Kafka 副本因子通常也配 3任何一个 broker 宕机都不会丢数据还能继续服务。内存这里要多说一句Kafka 本身并不直接把数据存在堆内存里而是大量使用操作系统页缓存。所以 JVM 堆内存不是越大越好我一般给 6G 到 8G剩下的内存全部留给页缓存。这样的好处是消费者读消息时大概率直接命中页缓存连磁盘 IO 都不用走吞吐自然高。磁盘目录规划更关键。我强烈建议每个 broker 至少两块盘、两个独立挂载点分别作为数据目录然后在配置里用log.dirs/data1/kafka,/data2/kafka这种方式都交给 Kafka。Kafka 会自动把不同分区的副本分散到这些目录上等于天然做了负载均衡。如果只有一块 RAID 卷也没关系但吞吐上限会比多盘低不少。角色节点名建议配置数据目录Broker ZKkafka132G / 2块盘 / 10GbE/data1, /data2Broker ZKkafka232G / 2块盘 / 10GbE/data1, /data2Broker ZKkafka332G / 2块盘 / 10GbE/data1, /data2生产环境 ZooKeeper 我建议独立部署三个节点但如果资源有限和 Kafka Broker 混布也能跑只是要注意 ZK 对磁盘延迟敏感不要和 Kafka 抢同一块盘的 IO。1.3 从解压到启动部署的完整记录部署步骤看起来简单但每个细节都有讲究。先装 JDKyum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel然后下载 Kafka 二进制包解压到 /optcd /opt wget https://archive.apache.org/dist/kafka/2.8.1/kafka_2.12-2.8.1.tgz tar -zxvf kafka_2.12-2.8.1.tgz ln -s /opt/kafka_2.12-2.8.1 /opt/kafka重点在 server.properties 的关键配置项。三个节点的 broker.id 必须不同listeners 和 advertised.listeners 要填实际能访问到的 IP千万不要只写 localhost。log.dirs用逗号分隔多个目录zookeeper.connect填三个 ZK 节点。broker.id0 listenersPLAINTEXT://192.168.1.11:9092 advertised.listenersPLAINTEXT://192.168.1.11:9092 log.dirs/data1/kafka,/data2/kafka num.partitions3 default.replication.factor3 min.insync.replicas2 zookeeper.connect192.168.1.11:2181,192.168.1.12:2181,192.168.1.13:2181这里提前把num.partitions和default.replication.factor配置好非常重要。很多人默认分区数是 1后面每个 topic 都要手动改很麻烦。我建议建 topic 时显式指定分区数和副本数不要依赖默认值。启动方式建议用 systemd 管理方便开机自启和查看日志。写一个 /etc/systemd/system/kafka.service[Unit] DescriptionApache Kafka Afternetwork.target [Service] Typesimple Userkafka Groupkafka EnvironmentJAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk ExecStart/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties ExecStop/opt/kafka/bin/kafka-server-stop.sh Restarton-failure [Install] WantedBymulti-user.target用户建议单独建一个 kafka 系统用户不要用 root 跑权限隔离更安全。启动后看是否监听 9092 端口再用kafka-topics.sh建一个测试 topic 验证集群状态。/opt/kafka/bin/kafka-topics.sh --create \ --topic perf-test \ --partitions 16 --replication-factor 3 \ --bootstrap-server 192.168.1.11:9092建完用--describe查看分区和副本分布如果能正常看到 Leader 和 Isr 信息说明集群已经通了。2. 分区机制是如何撑起吞吐量的原理拆解2.1 分区就是并行通道先把这个概念对齐很多人把 Kafka 的吞吐问题当成一个“调参问题”上来就调 batch.size、linger.ms但真正的底座是分区。打个比方一个办事大厅只有一个窗口业务员再努力一小时也就办那么多事如果把窗口开到十个办理能力才能成倍增长。Kafka 的分区就是这个窗口。消息发到 topic 之后是按照分区来存储和读取的。生产者可以往多个分区并行写消费者也可以开多个线程、多个实例同时读不同的分区。Kafka 能做到高吞吐本质上就是靠“分区把数据切碎然后并行处理”而不是靠单点性能。这里有个关键约束Kafka 只保证单个分区内的消息有序不保证跨分区有序。所以设计分区时要明确哪些消息必须按顺序处理就把它们路由到同一个分区。比如订单状态变更这类强顺序业务通常按订单号作为 key让同一个订单的所有消息进同一个分区。而日志、埋点这类允许乱序的数据就不需要为顺序牺牲并行度。数据流处理框架的并行度也跟分区强相关。Kafka Streams、Spark Structured Streaming、Flink 在读取 Kafka topic 时一个分区对应一个处理任务。换句话说分区的上限决定了流处理任务的并行度上限。如果你的流处理作业处理不过来先检查的往往不是 CPU而是 topic 分区数是不是不够。2.2 Leader、Follower、ISR 是如何配合的每个分区在集群里都会有副本通常是 3 个。这些副本角色不同一个是 Leader其余是 Follower。所有生产和消费请求都由 Leader 处理Follower 只做一件事——从 Leader 拉取数据异步同步保证自己有数据的最新副本。这就带来了几个直接影响吞吐的点。第一Leader 处理读写时Follower 的拉取请求会占用 Leader 的磁盘 IO 和网络带宽。复制因子越高Leader 要“喂”给副本的数据量越大。第二生产端acks参数决定了消息写成功需要等多少个确认。acks1只要 Leader 写入成功就返回吞吐最高acksall要等 ISR 里所有副本都同步完才返回可靠性最高但延迟和吞吐都会受影响。ISR 是“在同步中的副本”集合它会动态变化。如果某个 Follower 长时间跟不上 Leader就会被踢出 ISR等它追上来再重新加入。生产端配合min.insync.replicas2的意思是即使某个副本同步不及时只要 ISR 里还有至少两个副本写入就还能继续。我见过不少团队为了可靠性把acksall和min.insync.replicas3一起用结果一个 broker 抖动就导致整个 topic 写入失败。这里要理解min.insync.replicas3意味着必须等 3 个副本全部在 ISR 里才允许写入集群里任何一台机器有问题写入都会被拒。建议是 3 副本配min.insync.replicas2既允许一台宕机时继续写入又保证了至少两份数据落地。2.3 分区数、副本数与吞吐量的量化关系分区数越多能并行的读写通道就越多但这个关系不是无限的。每个分区都会有对应的文件句柄、内存缓冲和元数据开销分区数过多Broker 需要维护的元数据膨胀Leader 选举和分区重平衡的时间也会变长。我们先看一组我在 3 节点、SSD、万兆网卡环境下压测出来的数据配置条件消息大小实测吞吐单分区acks1100B约 25MB/s单分区acksall100B约 15MB/s4 分区acks1linger10ms100B约 80MB/s8 分区acks1压缩 lz4500B JSON约 150MB/s可以清楚看到单分区吞吐有上限而多分区配合批量发送和压缩吞吐能成倍上涨。分区数的估算可以用一个简单经验公式分区数 ≥ max(业务峰值吞吐 / 单分区实测吞吐, 期望消费并行度)单分区吞吐建议用实际环境压测值别拍脑袋。压测完再乘 2 到 3 倍的安全余量因为生产环境有峰值抖动、Broker 滚动重启、副本同步抢占带宽等干扰因素。上界也要控制。我的经验是每个 Broker 上的副本总数不要超过 2000 到 3000一个 topic 的分区数在几十到几百这个区间最常见。分区特别多的 topic一旦触发重平衡几万个分区在集群里重新分配会非常慢这段时间业务消费会明显卡顿。3. 分区规划与生产消费参数从业务吞吐量反推配置3.1 用真实压测数据反推分区数别拍脑袋举一个我实际处理过的案例。业务方要求系统能够稳定扛住 100MB/s 的写入消息平均大小约 500B消费端需要并行处理数据。我先在测试集群上做了单分区压测得到单分区写吞吐大约 25MB/s。按最基础的算法100 除以 25至少需要 4 个分区。但生产环境不能卡着下限跑。高峰期流量通常会有 2 到 3 倍的瞬间波动加上还有副本同步消耗网络和磁盘 IO我最终把 topic 分区数定为 12。后面业务量继续增长又提前预留余量改成了 16。整个过程中同一时间消费者实例数也控制在 8 到 12 个之间保证每个消费者分到 1 到 2 个分区不会出现空转。这个案例里最重要的是“从吞吐目标反推”而不是“默认 3 个分区”。很多人建 topic 时根本不指定分区数全靠 broker 的默认值结果业务一上来吞吐就卡死还以为是机器性能不够。实际上机器负载很低瓶颈纯粹是并行通道太少。除了吞吐量还要考虑流处理任务的并行度。比如 Flink 读取这个 topic 时source task 就可能需要和分区数保持一致分区太少下游再多的计算资源也只能闲着。我建议定分区数时把后续可能接入的流处理任务数量也算进去宁可前期稍微多点也不要后期做分区扩容这种动刀子的操作。3.2 key 路由、粘性分区与数据倾斜这关必须过Kafka 的分区路由规则决定了消息去哪个分区。默认的分区器对 key 做哈希同一个 key 的消息永远进同一个分区没有 key 的消息在 Kafka 高版本已经默认使用粘性分区器即一批消息先填满当前分区再换下一个分区。理解粘性分区很重要。早期版本的轮询策略是每条消息轮流发到不同分区这样一来因为每条消息都要单独计算路由小消息在高并发下会产生大量零碎的请求网络往返次数暴增吞吐反而上不去。粘性分区的思路是把一批消息集中扔到同一个分区攒够批次或者达到 linger.ms 再一起发送请求数量大幅减少吞吐提升明显。数据倾斜是分区配置中最隐蔽的坑。假设你按用户 ID 做 key结果少数几个大用户贡献了 90% 的消息量那么这些用户所在的分区会成为热点这个分区写入特别快、磁盘占用特别大其他分区却很闲。整个系统吞吐再高也会被这几个热分区拖住。解法通常是改造 key比如给大用户 ID 加盐让它分散到多个分区或者干脆从业务上调整路由逻辑。千万别指望通过调大 batch.size 解决倾斜问题那是治标不治本。还要记住有序性和并行度是矛盾的。如果业务强依赖全局顺序那分区只能设 1吞吐自然受限。我的建议是把有顺序要求的消息范围缩小比如“同一订单内部有序”而不是“所有订单全局有序”这样既能用多分区提升吞吐又能保住局部有序。3.3 生产者侧参数把分区并发真正吃满分区数再合理生产者参数不配合也白搭。我最常调的是五个参数acks、batch.size、linger.ms、compression.type、buffer.memory。acks 刚才说过生产集群我一般用acksall配合min.insync.replicas2只要不是对吞吐有极致要求这个组合兼顾可靠性和性能。batch.size 默认 16KB对大量小消息来说偏小。小消息单个体积可能只有几百字节如果不攒批每个请求里只有一条消息网络包利用率极低。我把 batch.size 调到 32KB 或 64KB配合 linger.ms 调到 5 到 20 毫秒吞吐能提升一倍以上。代价是单条消息的延迟增加所以低延迟场景 linger 要小高吞吐场景才值得往大了调。compression.type 是被很多人忽略的加速利器。业务消息大多是 JSON 文本压缩比非常高。lz4 或 zstd 都是好选择压缩后网络带宽占用能降低 50% 以上。带宽省下来副本同步的压力也小了可靠性场景下尤其明显。acksall batch.size65536 linger.ms10 compression.typelz4 buffer.memory67108864 max.in.flight.requests.per.connection5max.in.flight.requests.per.connection 保持 5 可以在 acksall 时依然保持多条请求在途但要注意如果你开启幂等生产者和强顺序保证需要和版本配合好。实测下来这套配置在 16 分区 topic 上单生产者能稳定跑出 80MB/s 以上的写入。3.4 消费者侧参数并发上限就是分区数消费端的核心约束是同一个消费组里一个分区同时只能被一个消费者实例消费。所以消费者线程数、实例数超过分区数时超出的那些是白开的。我见过团队开 20 个消费者线程读一个 8 分区的 topic结果 12 个线程一直在等待还以为是消费逻辑慢。消费吞吐的调优重点是减少请求次数。fetch.min.bytes默认 1 字节意味着只要有数据就返回这样会频繁发起拉取请求调大到 1KB 或 4KB配合fetch.max.wait.ms调到 500 到 1000 毫秒让 broker 攒一批数据再返回消费端吞吐会明显改善。同时max.poll.records要控制好比如设 500避免单次 poll 拉取的数据量太大导致处理时间过长而触发 rebalance。分区数对消费端还有一层含义如果你要用多线程模型提高单实例消费速度最稳妥的做法是一个线程固定消费一个分区不要多个线程抢同一个分区的消息否则要靠本地锁去保证顺序和提交 offset 的幂等性复杂度很高。数据流处理框架也遵循这个逻辑。Flink、Spark 的 source 并行度通常和分区数对齐如果你想让流处理任务水平扩展topic 分区数就要预留足够。这就是为什么我在规划分区数时不只看当前消费需求还会把未来半年可能的流处理任务数量算进去。4. RHEL 7 系统层调优让分区优势真正落地4.1 文件句柄、页缓存与脏页写回的正确姿势分区机制设计得再好底下的操作系统层跟不上也是白搭。RHEL 7 默认对单进程文件句柄限制是 1024Kafka 一个 Broker 起几十个分区后很容易就打满。必须先调到 65535 以上echo kafka soft nofile 65535 /etc/security/limits.conf echo kafka hard nofile 65535 /etc/security/limits.conf页缓存是 Kafka 性能的秘密武器。Kafka 读消息时如果页缓存命中根本不碰磁盘。为了让页缓存发挥最大作用系统层面要避免内存被默认参数糟蹋。把 swappiness 调到 1让系统尽量不换出页面关闭透明大页 THP因为它会导致内存碎片和偶发延迟。echo 1 /proc/sys/vm/swappiness echo never /sys/kernel/mm/transparent_hugepage/enabledRHEL 7 里这些设置在重启后会失效建议写进 /etc/sysctl.conf 和 /etc/rc.local或者用 systemd 的 sysctl 配置统一管理。脏页写回参数vm.dirty_background_ratio和vm.dirty_ratio值得单独说。Kafka 是顺序写为主脏页写回太积极会让磁盘频繁刷写产生周期性吞吐毛刺写回太慢则断电丢数风险变大。我常用vm.dirty_background_ratio5和vm.dirty_ratio30这个组合在生产环境表现比较稳。如果你的机器有电池保护或 UPS可以把 dirty_background_ratio 再调低一点让刷盘更平滑。4.2 多磁盘挂载与 log.dirs 配置的实操细节我前面说过数据目录要多目录。实际操作时每块盘单独格式化、单独挂载不要用 LVM 把它们合成一个大卷。因为 Kafka 本身会按目录分发分区多目录天然提供 IO 隔离合成一个大卷反而把不同盘的吞吐混在一起一个分区写满时可能拖累别的分区。挂载参数建议加noatime避免读操作产生不必要的元数据写日志。SSD 的话挂载时留意一下分配器和对齐问题。磁盘调度器方面机械盘用 deadlineSSD 可以直接用 noop 或 none减少 IO 调度带来的延迟。Kafka 配置里 log.dirs 顺序也要注意。逗号分隔的目录在启动时会被扫描每个新建分区的副本会轮询分配到这些目录里。目录越多分区分布越均匀。我见过有人为了图省事把所有盘都挂到 /data 下然后在 log.dirs 只写一个 /data/kafka结果只有一块盘在干活其他盘全闲着。正确的写法是log.dirs/data1/kafka,/data2/kafka,/data3/kafka,/data4/kafka另外磁盘容量规划要结合日志保留策略。Kafka 默认保留 7 天数据但每个分区的数据量和消息大小不一样。我的经验是给 Kafka 数据盘留至少 30% 的冗余空间否则磁盘写满后 Broker 会直接拒绝写入日志里全是Not enough space的报错排查起来很痛苦。4.3 网络内核参数与 JVM 堆设置Kafka 对网络连接数要求很高生产端、消费端、副本同步都会建大量 TCP 连接。RHEL 7 默认的somaxconn是 128高并发下连接队列很容易溢出。要调大net.core.somaxconn 1024 net.ipv4.tcp_max_syn_backlog 2048 net.core.netdev_max_backlog 4096这些配置写进 /etc/sysctl.conf然后sysctl -p重载。实测在万兆网卡环境下调完这些参数后连接的建立成功率明显改善特别是突发流量场景。JVM 堆内存的设置我一开始就提到了6G 到 8G 足够。不要动不动给到 16G、32G堆太大反而让 GC 停顿变长而且会挤占页面缓存的空间。GC 选择 G1并设置合理的目标停顿时间export KAFKA_HEAP_OPTS-Xms6G -Xmx6G -XX:MaxGCPauseMillis200 -XX:InitiatingHeapOccupancyPercent35InitiatingHeapOccupancyPercent设为 35 是让 G1 更早启动并发标记周期避免堆快满时触发 Full GC 造成吞吐毛刺。Kafka 的num.network.threads和num.io.threads默认也可以如果机器 CPU 核数多可以把 io 线程从默认 8 调到 16。但要记住io.threads 处理的是磁盘读写和网络处理堆内存越大不代表线程越多越好适可而止。5. 压测工具、常见故障与避坑实录5.1 用官方 perf 工具摸清吞吐上限Kafka 自带的生产者消费者压测脚本非常好用不用额外装工具。先测生产者吞吐/opt/kafka/bin/kafka-producer-perf-test.sh \ --topic perf-test \ --num-records 1000000 \ --record-size 500 \ --throughput -1 \ --producer-props bootstrap.servers192.168.1.11:9092 \ acks1 linger.ms10 batch.size65536 compression.typelz4--throughput -1表示不限速跑完会输出 records/sec、MB/sec 和 p50/p95/p99 延迟。注意单分区和多分区要分别测单分区结果用来估算分区数多分区结果用来验证整体能力。消费端压测类似/opt/kafka/bin/kafka-consumer-perf-test.sh \ --bootstrap-server 192.168.1.11:9092 \ --topic perf-test \ --messages 500000 \ --threads 1 \ --print-metrics压测不是跑一次就完事。我建议至少测三组单分区、目标分区数、目标分区数加生产端调优参数。这样你能清楚看到每个环节的贡献到底有多大后面出问题时也方便定位瓶颈。压测的时候还要关注一个细节消息大小不同结果差异很大。100B 的小消息瓶颈在网络包和请求数上1MB 的大消息瓶颈在磁盘顺序写速度上。所以压测消息大小要贴近真实业务否则测出来的吞吐数据没有参考价值。5.2 常见故障排障思路与工具速查我在 RHEL 7 上调试 Kafka 集群时遇到过几类高频问题整理成一张速查表现象常见原因排查手段写入吞吐上不去分区数太少 / 生产者未调参查 topic 分区数kafka-producer-perf-test 对比周期性吞吐毛刺脏页刷盘 / GC 停顿iostat 看磁盘 utiljstat 看 GC 日志消费延迟持续增加消费者数小于分区数 / poll 内业务慢数一下消费者线程数看 lag 指标ISR 反复收缩网络抖动 / 副本同步跟不上查 broker 日志检查带宽和磁盘 IOrebalance 时间过长分区数过多 / 消费组内成员频繁变动看 rebalance 日志控制分区总数磁盘写满后拒绝写入retention 太小或容量规划不足df 看空间检查 log.retention.hours排查工具平时就要备好。iostat -x 1看磁盘 IO 有没有打满vmstat 1看 CPU 和内存行为jstat -gcutil pid 1000看 JVM GC 频率和停顿。问题比较大时用jstack piddump 线程栈看是被锁等待卡住还是在做长 GC。Kafka 自带工具里kafka-log-dirs.sh可以看各目录磁盘使用分布kafka-replica-verification.sh可以校验副本同步是否健康。有一个经验遇到“吞吐突然下降”的问题先别怀疑 Kafka 配置被改过先看系统层。RHEL 7 的磁盘调度策略、内核参数、甚至时钟同步都会影响 Kafka。比如 NTP 没配置好时钟跳变会导致消息时间戳异常、副本同步判断错乱问题非常隐蔽。新集群一定要先配好 chrony 或 ntpd。5.3 我踩过的几个分区配置坑第一个坑也是新手最容易踩的topic 分区数默认是 1消费端怎么扩容都没有。我帮人排查过一次消费吞吐上不去的故障打开 topic 描述一看分区数只有 1消费者开了一堆线程全在抢同一个分区吞吐当然是锁死的。正确做法是一开始就做好分区规划就算 topic 只有测试性质也建议至少建 3 个分区后面扩容容易产生数据重分布的开销。第二个坑是关于副本数和 acks 的组合。有一次我为追求极致可靠性把 topic 副本设为 3、min.insync.replicas 也设成 3结果一台 broker 做常规重启时整个 topic 所有分区的写入全部被拒。后来才意识到min.insync.replicas3 意味着三个副本必须同时在 ISR任何一台离线都会卡住写入。改成 min.insync.replicas2 之后单台重启不再影响业务可靠性也没有损失。第三个坑是分区数“贪多”。我合作过的一个团队把所有 topic 都设成 64 分区理由是可扩展性好。结果 topic 数量积累到几十个后broker 上副本数量膨胀到几千个每次触发 rebalance 都要经历漫长的分区重新分配消费组停机时间从几秒变成几分钟。分区数不是越大越好够用加上有安全余量就是最好的状态。第四个坑是数据倾斜导致“有分区闲着有分区忙死”。这是我在一个埋点数据采集场景里踩到的。当时按 App ID 做 key 分区结果几个头部 App 的流量占总量 80% 以上对应的分区写入一直在满负载其他分区空转。后来给 key 加了下游分发维度字段热点被打散整体吞吐才真正跑起来。这个问题在设计路由时就要预判不要等到压测发现热分区才处理。最后一个提醒压测和生产是两回事。我见过测试环境跑得很好、一上生产就打回原形的情况原因往往是测试环境用了低副本数、无压缩、acks0和生产完全不一致。分区规划、生产消费参数、系统层调优必须保持环境一致压测结果才有参考意义。根据我的经验分区机制不是配置完一次就一劳永逸的东西。业务增长、消息大小变化、消费模式调整都会让原先合理的分区设计慢慢变得不匹配。建议每隔半年左右趁业务低峰期重新做一次压测对照当时的吞吐目标和延迟要求再决定是不是要调分区数、副本数或者生产消费参数。把这件事当成持续优化而不是一次性部署任务Kafka 集群才能在你手里长期保持稳定的高性能。