先从结论说起：不管你是不是资深Kafka玩家，只要你在RHEL 7上搭过集群、压过吞吐，最后多半都会面对同一个灵魂拷问——“分区数到底该设多少？是不是越多越好？”说实话，这个问题没有标准答案，但有一套可以复用的思路。本文就用一个三节点Kafka集群为例，从分区机制的原理讲到RHEL 7上的完整部署和调优，把吞吐量提升这件事拆开揉碎讲清楚，适合正在做日志采集、消息中台或者流式计算底座的运维和架构同学参考。
1. 从业务痛点出发：为什么吞吐成了瓶颈
1.1 最典型的吞吐瓶颈场景
先还原一下最常见的生产场景。你有一套基于Kafka的消息系统，上游是几十台业务服务器，每台每秒往Kafka里塞上千条JSON日志；下游是Spark或Flink任务，实时消费这些数据做指标计算。白天业务高峰时，Topic的写入速率突然从2MB/s涨到20MB/s，然后Kafka集群开始不对劲：Producer端消息堆积、发送超时，Consumer端消费延迟从秒级涨到分钟级，监控面板上Broker的CPU和磁盘IO都拉满了。
这时候大部分人的第一反应是加机器——加Broker、加磁盘，但很多时候机器加了，吞吐提升却有限。问题恰恰出在“分区机制”上：你只是增加了节点数量，却没有合理利用分区带来的并行能力。Kafka的吞吐，本质上不是靠堆机器堆出来的，而是靠分区数、副本分布、生产端批量策略、消费端拉取策略一起算出来的。
1.2 为什么是RHEL 7 + Kafka这个组合
RHEL 7在数据中心里的存量依然很大，很多企业的核心业务系统还跑在7.x上。它虽然没有RHEL 8/9那么新，但胜在稳定，尤其是配合Kafka 2.x版本的搭配非常成熟——网上能查到的踩坑记录、参数调优案例，大部分都是基于这个组合。Kafka本身是JVM应用，对操作系统依赖相对简单，RHEL 7自带的systemd、sysctl机制够用，不会像某些新内核版本一样额外引入一堆兼容问题。
这套组合适合所有“存量服务器是RHEL 7、想低成本升级消息系统能力”的团队。不需要换操作系统，不需要引入太重的基础设施改造，只要把Kafka集群的分区设计和参数调优做得足够细，就能在不动业务代码的前提下把吞吐量提上去。
1.3 总体设计思路：分区是唯一的杠杆
我见过很多团队把“提升吞吐量”简单理解为“加broker、加内存、换SSD”，这些是有效手段，但优先级应该靠后。排在第一位的是分区设计，因为分区决定了Kafka并行处理的上限。一个Topic如果只有3个分区，哪怕你后面挂了10个Broker，这个Topic最多也只能被3个Consumer线程并行消费；写入端虽然可以打散到多个Broker，但单个分区的写入还是串行的，单分区写入带宽就是瓶颈。
所以在动任何参数之前，先明确这个思路：分区分区，分的是“并行度”，而不是“存储空间”。并行度上去了，吞吐量才有可能跟着上去。RHEL 7上的系统参数调优和Kafka自身参数调优，都是为了“让分区的并行能力被充分释放”而服务的。
2. 分区机制的底层逻辑：吞吐量到底从哪来
2.1 分区如何决定并行度上限
Kafka的存储模型是“一个Topic分成多个Partition，每个Partition内部有序，整体无序”。这句话值得反复咀嚼：Partition是Kafka并行处理的“最小调度单元”。
从写入方向看，Producer发消息时，Kafka会通过分区器决定消息进哪个分区。你可以指定key，也有默认的黏性分区策略（Sticky Partitioning）——它会先把一批消息攒到一个分区里，然后切换，这种策略能显著减少网络往返次数。从消费方向看，一个Consumer Group里的Consumer数量如果超过分区数，多出来的Consumer会闲置；反之，一个Consumer可以同时消费多个分区。也就是说，Consumer端的并行度绝不可能超过分区数，分区数就是这个Topic并行处理能力的上限。
举个生活化的例子：分区就像是高速公路的车道数。车道越多，同一时间能并排跑的车就越多。但如果你把收费站（Consumer）只开一个口，车道再多也是堵在出口；反过来，你开十个收费口但只有两条车道，那也是白搭。分区设计要同时照顾“入口”和“出口”两端的并行能力。
2.2 分区数量设计的核心计算公式
每个团队的业务不一样，分区数没有统一标准，但可以按这个思路算：
第一步，估算单分区吞吐基准。拿一条1KB左右的消息来说，一次普通的Linux服务器上，单分区在Producer端走batch写入、Consumer端顺序读取时，实测峰值大概在10~20MB/s附近——这取决于磁盘和网卡，SSD会更高。这里取一个保守值：10MB/s。
第二步，估算目标吞吐量。比如你的业务高峰期需要支撑每秒处理2万条消息，每条1KB，那就是约20MB/s的写入量。
第三步，计算分区数下限。目标吞吐20MB/s ÷ 单分区吞吐10MB/s = 2个分区，听起来2个就够了？这是最大误区。生产环境必须留余量，一般乘以2到3倍，同时还要考虑Consumer的并发数和下游处理能力。所以这时候分区数至少给到6~8个比较稳妥。
第四步，还要算一下全集群的分区总数。Kafka官方建议集群总分区数（所有Topic的分区加起来）最好不要超过“Broker数 × 单Broker可承载分区数”的约束。比如3个Broker，每台Broker管理日志文件、副本同步都有开销，经验上单Broker承载几百个到上千个分区是没问题的，但超过几千个时Broker上争抢线程和内存的压力会非常明显。
注意：分区数不是越大越好。每个分区对应一组日志文件、索引文件，还有ISR同步的通信开销。分区数过多会让Broker进程维护成本上升，文件句柄被占满，垃圾回收压力变大，Consumer重平衡的时间也会变长。这就像车道画的太密但每辆车都很慢，整体通行效率反而下降。
2.3 分区与副本的组合策略
分区解决了并行问题，副本则解决可靠性问题。两者不能混为一谈，但设计时要一起考虑。
生产环境一般把副本因子设置为2或3。副本数为2时，Leader和Follower各一份，允许一台Broker宕机而不丢数据；副本数为3时，安全性更足，但同步成本也更高——每条消息都要多复制两份。分区增多后，副本同步的通信压力也会按比例增长，因为每个分区的Follower都要向Leader拉取数据。
在设计时要尽量让Leader副本均匀分布在所有Broker上。Kafka的副本分配算法已经考虑了这一点，但如果你手动用kafka-topics.sh指定过副本数或者对已有Topic增删过分区，建议定期检查分区的Leader分布，避免个别Broker成为热点。
2.4 分区重平衡与数据倾斜
分区设计得再好，运行一段时间后也可能出现“倾斜”。最常见的情况是：
- 生产端指定了key，而某个key的消息量特别大，导致这一个分区的数据量远超其他分区；
- 新增Broker后，已有的分区不会自动迁移到新Broker上，数据仍然集中在老节点；
- 某个Consumer处理逻辑偏慢，拖慢了它负责的那几个分区。
这些问题不是Kafka本身能自动解决的，需要在设计阶段就规划好key的散列策略，以及定期用kafka-reassign-partitions.sh做一次分区的再平衡。后面第5章的排查部分会专门讲这个。
3. RHEL 7 环境下的集群部署与分区配置实操
3.1 环境准备与基础软件选型
模拟一个3节点的RHEL 7集群。三个节点的配置建议如下：8核CPU起步、16GB内存、2块数据盘（系统盘和数据盘分离，数据盘单独挂载，推荐SSD，机械盘至少也要万转以上）。网络千兆起步，万兆更佳。这个配置不算豪华，但作为Kafka集群至少能支撑每秒几十MB的吞吐量。
软件选型方面：JDK必须用8，因为Kafka 2.x版本都是基于JDK 8编译的，用OpenJDK 8即可。ZooKeeper建议用3.5.x或3.4.x，虽然Kafka 2.8之后引入了KRaft模式可以不依赖ZooKeeper，但生产环境用KRaft在RHEL 7上的案例还不够多，我更推荐稳妥的ZooKeeper方式。Kafka本身用2.7.x或2.8.x这类较新的稳定版，和RHEL 7兼容性良好。
3.2 Kafka服务器核心配置项
进入解压后的Kafka目录，编辑config/server.properties，这是整个集群最核心的配置文件。下面这份配置是基于3节点集群整理的可直接参考版本，关键项的说明我写在注释里：
# 每个Broker唯一标识，三台机器分别设置0、1、2 broker.id=0 # 监听地址，内网IP和端口 listeners=PLAINTEXT://192.168.10.10:9092 advertised.listeners=PLAINTEXT://192.168.10.10:9092 # 数据存储目录，多块盘用逗号分隔 log.dirs=/data1/kafka-logs,/data2/kafka-logs # ZooKeeper集群地址 zookeeper.connect=192.168.10.10:2181,192.168.10.11:2181,192.168.10.12:2181 # 分区相关的默认设置 num.partitions=8 default.replication.factor=2 min.insync.replicas=1 # 网络与IO线程 num.network.threads=8 num.io.threads=8 queued.max.requests=1024 # 日志段大小与保留策略 log.segment.bytes=1073741824 log.retention.hours=72 log.retention.check.interval.ms=300000 # 自动创建Topic，生产环境建议关闭 auto.create.topics.enable=false这里面最需要理解的是几个“为什么”：
为什么log.dirs要配多个目录？Kafka的日志是顺序追加写的，多块磁盘可以并行写不同分区的日志文件，从根上提升IO吞吐。如果只有一块盘，这个参数就没什么意义，直到你加盘之后才能发挥分区并行IO的收益。
为什么num.io.threads=8？这个参数控制Broker处理请求的线程数，本质是CPU核心数的利用。8核机器给到8是合理的，太大反而会导致上下文切换开销增加。网络线程同理，负责处理客户端连接和请求转发，两者相互配合。
为什么num.partitions=8？这是新建Topic时的默认分区数，官方默认是1，生产环境一定要改大。但也不要拍脑袋设几十个，根据第2章的计算逻辑，8个分区在3节点集群上意味着每个Broker平均要管理约2.7个分区的Leader和2.7个Follower副本，属于非常舒适的负载区间。
为什么min.insync.replicas=1？这个参数控制“至少多少个副本同步成功才认为消息提交成功”。设置1意味着Producer用acks=all时，只要Leader落盘就算成功——写入高可用等级降低了但吞吐高。如果追求数据安全，这个值设2，配acks=all；但要注意如果只有2个副本且一个Broker宕机，写入就会失败。生产环境常用2副本+min.insync.replicas=1的折中方案。
三台Broker的配置除broker.id和listeners地址外完全一致，建议其他参数也保持一致，避免集群内行为不一致。
3.3 RHEL 7系统层面的关键调整
Kafka本身调得再好，RHEL 7的系统参数拖后腿一样白搭。这一步太容易被忽略，我把它单独列出来讲。
修改文件描述符限制。Kafka的每个分区对应多组文件句柄，分区一多，默认1024的限制瞬间就打满了。在/etc/security/limits.conf里加：
kafka soft nofile 100000 kafka hard nofile 100000调整内核参数。RHEL 7的默认内核网络缓冲区偏小，高吞吐网络下容易丢包或延迟。在/etc/sysctl.conf里追加：
vm.swappiness=10 vm.dirty_ratio=60 vm.dirty_background_ratio=5vm.swappiness调低是为了防止内存频繁换页，影响Kafka的页缓存命中率。Kafka读消息主要是靠操作系统页缓存，一旦发生swap，性能断崖式下跌。vm.dirty_ratio控制脏页写盘的时机，调高一些可以让数据先在页缓存里攒一攒再批量落盘，配合Kafka的顺序写入特性，写盘效率更高。
磁盘挂载参数调整。数据盘挂载时建议加上noatime和nobarrier（如果是ext4）。noatime避免每次读写更新访问时间戳，减少不必要的写IO；nobarrier在断电场景下有小概率文件系统不一致风险，但对Kafka这种有副本机制的应用来说，性能收益更值得，生产上我是在RHEL 7+ext4的组合下用过的。如果用的是xfs，不要加nobarrier。
3.4 使用systemd托管Kafka进程
RHEL 7自带systemd，直接用systemd来管理Kafka比用start-kafka.sh脚本更符合运维习惯。新建/etc/systemd/system/kafka.service：
[Unit] Description=Apache Kafka After=network.target Requires=zookeeper.service [Service] Type=simple User=kafka Group=kafka ExecStart=/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties ExecStop=/opt/kafka/bin/kafka-server-stop.sh Restart=on-failure LimitNOFILE=100000 [Install] WantedBy=multi-user.target需要注意ExecStop：kafka-server-stop.sh会读取脚本里的PID文件来停进程，如果路径不一致可能停不掉。我踩过这个坑，建议在start脚本环境变量里显式指定路径，或者直接用systemd的ExecStop=/bin/kill -s TERM $MAINPID。
启动顺序上要先启动ZooKeeper再启动Kafka，用Requires=zookeeper.service声明依赖关系，再配合Restart=on-failure，比手动维护简单得多。
3.5 创建Topic并验证分区效果
集群节点和zookeeper都启动后，用kafka-topics.sh创建测试Topic：
bin/kafka-topics.sh --create \ --bootstrap-server 192.168.10.10:9092 \ --topic test-throughput \ --partitions 8 \ --replication-factor 2创建后可以查看Topic的分区分布：
bin/kafka-topics.sh --describe \ --bootstrap-server 192.168.10.10:9092 \ --topic test-throughput重点看Leader这一列，正常情况手工创建时8个分区的Leader应该均匀分散在3台Broker上（即使不均匀，Kafka的副本分配算法已经把副本打散了，只是Leader最初都在创建时的第一个副本所在机器上，可能需要结合分区再平衡来修）。然后再用kafka-producer-perf-test.sh快速压一下：
bin/kafka-producer-perf-test.sh \ --topic test-throughput \ --num-records 500000 \ --record-size 1024 \ --throughput 20000 \ --producer-props bootstrap.servers=192.168.10.10:9092 acks=1这个压测命令会打印每秒写入的消息数、吞吐量（MB/s）和平均延迟。几百毫秒内就能看出集群的真实写入能力，这是验证分区配置最直接的手段。
4. 面向吞吐量的核心参数调优
4.1 生产端参数：让写入从“小碎步”变成“大步走”
Kafka吞吐量调优最先见效的地方在Producer端。下面这几个参数只要合理设置，写入性能通常能有倍数级的提升。
batch.size与linger.ms是黄金搭档。batch.size默认16KB，linger.ms默认0。默认情况下，Producer端的消息攒到16KB就发，但这个“攒”的过程是有时间窗口的——如果linger.ms为0，哪怕消息只有1KB也马上发出去，这样batch永远攒不满，批量效果也就没了，反而是网络请求数量暴增。我的建议是linger.ms设置为5~20ms，batch.size可以调到32KB~64KB。简单粗暴的理解：给Producer一点耐心，让它多攒几条再走，网卡和Broker都会感谢你。
acks参数决定“可靠性换吞吐”的程度。acks=0不等待确认，吞吐最高但可能丢消息；acks=1只要Leader写入就确认，是实用选择；acks=all等所有ISR副本都写入，最安全但吞吐最低。生产环境如果追求吞吐且能容忍极端情况下的少量消息丢失，用acks=1；对账系统这种一条不能丢的，老老实实acks=all。
compression.type要敢用。这个参数默认是none。如果业务消息是JSON文本，开启lz4或snappy压缩后，线上压测常见的是能压掉50%~80%的体积，网卡和磁盘的压力都会显著降低。CPU的损耗在8核机器上几乎可以忽略。建议直接设成lz4。
完整的生产端配置参考：
acks=1 linger.ms=10 batch.size=32768 buffer.memory=67108864 compression.type=lz4 max.in.flight.requests.per.connection=5另外注意max.in.flight.requests.per.connection——它控制客户端在不等待前一条消息确认的情况下最多发送多少条请求。默认是5，但在acks=all时如果设置大于1，可能会导致乱序。如果业务对顺序要求极端，这个值要设回1；否则5是更好的并发选择。
4.2 Broker端参数：别让服务器侧成为隐藏瓶颈
Broker端参数在server.properties里已经设过一部分。这里再补充两个容易被忽略的点。
num.replica.fetchers默认值是1。它的作用是控制每个Broker上有多少个“Fetch线程”去拉取其他Broker上的Follower副本数据。集群Topic多、分区多的时候，1个线程根本不够用，副本同步会追不上Leader，进而引发ISR收缩、Producer延迟飙高。建议改到4~6，但不要超过CPU核心数。
log.flush.interval.messages与log.flush.interval.ms。这两个参数控制日志多久刷一次盘。Kafka官方建议不要手动调得太激进，默认值已经足够。但很多人会为了追求“不丢数据”把flush间隔调到毫秒级，结果写入吞吐暴跌。实际上，Kafka的可靠性不靠刷盘来保证，而是靠副本机制。只要副本同步正常，Broker宕机不会丢消息——刷盘太频繁纯粹是牺牲吞吐换心理安慰。
unclean.leader.election.enable默认是false，保持默认。它控制当Leader宕机后，ISR里没有副本存活时是否允许“非同步副本”成为Leader。设为true可以提高可用性但可能丢数据。数据流处理场景下宁可短暂不可用，也不能用丢失数据的成本换吞吐，所以保持false。
4.3 消费端参数：拉得狠不如拉得准
消费端的吞吐优化常常被忽视，因为大家默认“消费端只是读数据，应该不是瓶颈”——这句话错得离谱。消费端拉取策略不合理，Producer写得再快，数据还是压在Kafka里，端到端的延迟照样下不来。
fetch.min.bytes与fetch.max.wait.ms。默认情况下Consumer每次拉取请求都尽量快点返回数据，但这样会造成请求密集但单次返回数据少。建议设置fetch.min.bytes=1MB以上，fetch.max.wait.ms=500~1000。意思是：每次拉取请求至少等攒到1MB或者最多等1秒才返回。这能显著降低网络请求次数，提高消费吞吐。
max.partition.fetch.bytes控制单次拉取中每个分区最多返回多少数据，默认1MB。分区多的时候这个值可以适当降低，避免单次响应太大把Consumer进程内存打爆；分区少的时候则可以调大。
enable.auto.commit与auto.offset.reset。数据流处理场景建议把auto.commit设为false，用代码在数据处理完成后手动提交offset。自动提交虽然在吞吐上省事，但它提交的时机是“每过一段时间提交当前消费位置”，如果Consumer在处理消息时崩溃，你无法控制哪些消息算“处理完成”哪些算“还没处理”，重启后可能丢数据或重复处理。手动提交可以让吞吐和可靠性之间的平衡落在自己手里。
4.4 压测方法与验收基准
调优是否有效，不看感觉，看数据。我用的是Kafka自带的两个压测工具加Prometheus监控组合，简单有效。
写入端基准：直接用kafka-producer-perf-test.sh，按3.5节的方式跑。分别测“默认参数”和“调优后参数”两种配置，记录两个数：吞吐量（records/sec）和平均延迟（ms）。调优后的配置在同一台机器上通常能是默认配置的2~5倍——如果没达到，先检查是不是网络、磁盘IO已经跑满了。
消费端基准：用kafka-consumer-perf-test.sh：
bin/kafka-consumer-perf-test.sh \ --bootstrap-server 192.168.10.10:9092 \ --topic test-throughput \ --messages 500000 \ --threads 3如果能稳定消费掉生产端压出来的所有消息且延迟可控，说明消费端并行度足够。如果消费速率跟不上生产速率，优先查分区数是否小于Consumer线程数，再看fetch参数。
最终验收标准要考虑端到端：从Producer发出到Consumer处理完成的整体延迟（而不是单段延迟），以及“堆积积压量”——用kafka-consumer-groups.sh查看消费者组的Lag：
bin/kafka-consumer-groups.sh \ --bootstrap-server 192.168.10.10:9092 \ --describe --group test-groupLag稳定在0或很小的范围内，说明吞吐和消费能力匹配，整个链路才是真正活起来了。
5. 常见问题与排查技巧实录
5.1 分区倾斜：数据都往一个分区跑
症状：监控面板上Broker之间磁盘使用率差距特别大，个别分区所在磁盘快满了，其他Broker还很闲。写入吞吐在某个分区上卡住。
原因：第一种是生产端指定了key，且这个key对应的数据量特别大（比如用户ID为1的某个大客户产生的日志占了全部日志的30%）。第二种是消息key为null，但默认分区器在消息未达到batch阈值时会随机选分区，运行一段时间后分布可能不均衡。
解决思路：如果业务允许，给key加一个“盐”（比如key + 随机后缀），让数据分散；如果业务上必须保证相同key落到同一分区，那这种倾斜本身就是业务特性导致，要考虑的是对这个大key单独拆分Topic或增加Consumer并行度。如果整个Topic的分区分布严重不均，用kafka-reassign-partitions.sh将分区重新分配。
5.2 Consumer重平衡风暴：消费端反复Rebalance
症状：日志里反复出现Rebalance完成的消息，Consumer吞吐忽高忽低，部分分区在短时间内频繁被不同Consumer接管，客户端大量报错。
原因：最常见的是某个Consumer处理消息耗时太长，超过了max.poll.interval.ms（默认5分钟）的阈值，被判定为“挂掉”，触发了Rebalance。分区数过多、单次poll返回数据量过大同样会让单次处理时间飙长。
解决思路：不要上来就调大max.poll.interval.ms（那只是掩盖问题），先看Runnable状态下的处理时间是不是合理。如果处理逻辑确实耗时，先调小max.partition.fetch.bytes控制单次拉取数据量，或者增加Consumer实例数（前提是分区数允许）。另外把session.timeout.ms和heartbeat.interval.ms的比值保持在3:1左右，避免心跳超时造成的误判。
5.3 ISR收缩：副本落后太多被踢出
症状：kafka-topics.sh --describe查看Topic时，Isr那一列的副本数比Replicas少，且频繁变化。比如Replicas是[0,1,2]，但Isr只有[0,1]。
原因：Follower副本的拉取速度跟不上Leader的写入速度。可能是上一段说的num.replica.fetchers太小，也可能是Follower所在Broker的磁盘IO本来就是瓶颈，还可能是跨机房的网络延迟太高。
解决思路：优先调整num.replica.fetchers，从默认1提到4~6。如果磁盘是机械盘，考虑升SSD或者减少该Broker上的分区数。注意：ISR收缩后如果持续恶化，配合min.insync.replicas=1，生产端不会感知到，但数据冗余度已经下降，这时候必须处理，等到Leader挂了才处理就晚了。
5.4 文件句柄与JVM堆的隐性坑
症状：Broker进程运行一段时间后，突然无法接收新的连接，日志里报“Too many open files”，但看CPU和内存都不高。
原因：分区数太多，每个分区至少占用Leader和Follower两端的文件句柄，几百分区就上千个句柄。你limits.conf里设置了100000，但systemd的LimitNOFILE和成一个进程时同样要加，否则系统层面设了也没用。
解决思路：上面3.4节的systemd配置里其实已经写了LimitNOFILE=100000，这一步相当重要。JVM堆的大小方面，Kafka官方不推荐把堆设太大——默认1G即可，因为Kafka的内存管理依赖操作系统的页缓存而不是JVM堆。如果你把JVM堆设到8G，反而会降低页缓存的可用内存，吞吐不升反降。这个认知我觉得还是要看具体场景，但如果机器内存有限，建议宁可多留些内存给页缓存。
5.5 操作系统层面的延迟陷阱
症状：压测时吞吐忽高忽低，某个时间段内延迟猛增，但没有明显的大批量业务写入。
原因：可能是RHEL 7的定期文件系统清理任务（比如logrotate）或者备份脚本在高峰期跑了起来，占用了磁盘IO和CPU。也可能是vm.swappiness没调低，系统开始进行swap交换。
解决思路：在RHEL 7上用systemd-timer或者cron的方式错峰执行这些任务。同时用iostat -x 1观察磁盘的util指标，如果长时间超过80%，那么无论Kafka侧怎么调优，硬件瓶颈始终在那。另外，用dmesg查看是否出现了swap相关日志，确认vm.swappiness生效。
6. 个人实操总结与扩展思考
这套方案在我维护过的生产集群上反复检验过，有几个体会不吐不快。分区设计不是一劳永逸的工作，集群规模变化、业务量增长后一定要回头重新审视分区数。3节点集群升级到6节点后，如果分区数还是老样子，新增Broker的并行潜力就没有被释放。重建Topic并在业务低峰期切换，虽然稍微麻烦，但收益往往非常显著。
最后再分享一个小技巧：Kafka的监控不要只看Broker层的指标，一定要看分区层的指标。Kafka的JMX扩展里提供了非常细致的分区级别的kafka.server:type=FetcherStats,name=BytesPerSec、kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec等指标。很多吞吐量的问题，在“某个分区”这个粒度上才能看到真相——某个分区持续吃不满、或者持续过热，定义了整个集群的真正上限，而不是所有分区的平均值。这个视角帮我排过太多次障了，也希望你能用上。
