1. 先说结论：吞吐量卡住，多半不是并发拉满的问题
上个月帮朋友排查一个生产环境的消息队列性能问题，压测工具显示 QPS 卡在 3700 上不去，CPU、内存、磁盘IO看着都还有余量，但消息就是积压。他把消费者线程从 8 个加到 32 个，QPS 反而掉到 2900，还出现了大量重复消费和乱序。折腾了两天，最后根因居然是一行max.poll.records的默认配置和一批消息里混杂着几个大报文。
这个例子很有代表性。很多团队做消息队列调优，第一反应就是“加并发、加分区、加机器”，但消息队列的吞吐量是一个端到端的链路指标，生产端、Broker 存储层、消费端的任何一个环节掉链子，整条链路的吞吐量就卡在那里。盲目加并发不仅解决不了问题，还会引入重复消费、顺序错乱、连接数打满这些新麻烦。
先说清楚一个容易被误解的概念：消息队列的三大作用——异步解耦、削峰填谷、最终一致性——在调优语境下意味着什么。削峰填谷要求队列能扛住瞬时流量高峰，异步解耦要求消息投递足够快，不能成为业务链路上的新瓶颈。所谓吞吐量优化，本质上是让消息从生产者发出，经过 Broker 持久化，再到消费者成功处理并提交位移，这条链路的速率最大化。
这篇文章不打算从零讲消息队列的原理，直接进入调优实战。我会按照“定位瓶颈 → 生产端优化 → Broker 端优化 → 消费端优化 → 连带问题处理”的顺序展开，每一段都会给出可落地的参数配置和踩坑记录。全文以 Kafka 为主要示例，因为它在吞吐量上的可调参数最丰富，但思路基本适用于 RocketMQ、RabbitMQ 等主流队列。
2. 调优前先做一次定量分析，别凭感觉动参数
2.1 建立链路压测基线
动手调任何参数之前，先花半小时把这条消息链路的“体检报告”做出来。我自己会按下面这个清单收集数据，缺一项都不开工：
- 生产端的发送速率、发送耗时 P99、batch 是否频繁超时
- Broker 的 CPU、内存、磁盘IO、页缓存命中率、网络带宽
- 消费端的消费速率、处理耗时 P99、Rebalance 次数
- 消息积压量（consumer lag）的变化趋势
- GC 频率和停顿时间（Broker 和 Consumer 都要看）
- 一条消息的平均大小、最大大小、Topic 的分区数
这些数据不是拍脑袋看的，每个指标都对应着链路中的一个潜在瓶颈。比如生产端发送耗时高，问题可能在网络或 Broker 的写入能力；磁盘IO持续在 90% 以上，说明存储层先顶不住了；消费者耗时高但消费并发低，那就是消费逻辑本身慢了。
判断瓶颈在哪个环节，有一个比较实用的粗筛法：单独压生产端（只发送不关注消费），再单独压消费端（从已积压的消息里消费），哪一段的吞吐量明显低于预期，瓶颈就优先锁定在哪一段。把两段都压完，再跑全链路压测，这时候出现的问题才是真正的协作问题，比如消费位移提交策略和生产端的 batch 参数互相拖累。
2.2 Consumer Lag 是最诚实的信号
很多人一上来就盯着 QPS，其实最该看的是 Consumer Lag 的趋势。Lag 持续增长，说明消费速率低于生产速率，这时候加消费者线程是合理的。Lag 稳定在一个很小的值，说明消费能力已经够用，瓶颈在生产端或 Broker 端，再加消费线程只会让分区分配更碎，降低吞吐。
有一个反直觉的坑：当 Consumer 处理速度跟不上时，max.poll.interval.ms这个参数会触发消费者被踢出消费组，发生 Rebalance。Rebalance 期间整组消费者停止消费，Lag 雪上加霜。我之前遇到的情况是线上默认配置是 5 分钟，消息体里有几个大报文，单条处理时间超过 10 秒，一批 500 条消息处理完超过了 5 分钟，触发了 Rebalance。所以调了max.poll.records和max.poll.interval.ms的组合之后，积压问题才真正解决。
2.3 常见瓶颈一览表
| 瓶颈位置 | 典型表现 | 优先调整方向 |
|---|---|---|
| 生产端 | 发送耗时高、batch 频繁未满发出 | batch.size、linger.ms、压缩算法 |
| 网络链路 | 带宽打满、发送 RT 波动大 | 压缩、减少跨机房发送、合并报文 |
| Broker 存储 | 磁盘IO高、刷盘等待久 | 刷盘策略、页缓存命中率、分区数 |
| 消费端 | Lag 增长、Rebalance 频繁 | max.poll.records、并发模型、幂等处理 |
| JVM | GC 频繁、Full GC 多 | 堆大小、GC 选型、堆外内存管理 |
这张表不是标准答案，但能帮你快速圈定排查范围。定位瓶颈就像看病，诊断错了直接开药，大概率会加重病情——比如明明是生产端 batch 参数不合理，你去把消费者的线程数加了三倍，结果就是消费端频繁 Rebalance，丢消息和重复消费一起冒出来。
3. 生产端调优：批量发送、异步回调、压缩算法三件套
3.1 Batch 参数是吞吐量的第一道闸门
生产端最常见的低吞吐场景是“一条消息发送一次”。在 Kafka 的 Java Client 里，producer.send()其实不会真的立刻把消息发到网络，而是放进一个缓冲区，由后台的 Sender 线程按照 batch 策略打包发送。如果linger.ms=0（默认值），Sender 线程会在消息进入缓冲区后立即尝试发送，这相当于每个 ProducerRecord 都单独走一次网络往返，吞吐量肯定上不去。
合理的配置思路是：让生产端攒够一批消息再发，但等待时间又不能太长，否则增加了消息的投递延迟。我的常用配置参考：
Properties props = new Properties(); // 攒满 32KB 就发，即使没有达到 linger 时间 props.put("batch.size", 32768); // 最多等 10ms，凑不够一批也发出去 props.put("linger.ms", 10); // 发送缓冲区 64MB，避免高吞吐时缓冲区打满阻塞 props.put("buffer.memory", 67108864); // 使用 LZ4 压缩，CPU 开销小，压缩比不错 props.put("compression.type", "lz4"); // acks=1：Leader 写入成功即返回，兼顾可靠性和吞吐 props.put("acks", "1");这里的几个参数是联动的，不是改一个就完事。batch.size决定一批消息的容量上限，linger.ms决定等待时间，buffer.memory决定整个生产端缓冲区的大小。如果buffer.memory太小，发送速度快于网络发送速度时，send()会被阻塞，发送耗时就飙升。我在压测中见过buffer.memory默认 32MB 时，峰值流量下生产端发送超时率接近 15%，调到 64MB 后降到了 0.2% 以下。
一个需要特别注意的细节：batch.size是按字节数算的，不是按消息条数。如果你发送的消息单条有 10KB，一个 32KB 的 batch 只能装下 3 条；如果单条消息只有 200 字节，32KB 可以装下 160 条。所以调参之前先量一下消息的平均大小，不要盲目套别人的参数。
3.2 有重逻辑别放回调里
异步发送的回调函数里如果做了耗时的操作——比如打印日志、写数据库、调用远程接口——会严重拖慢生产端的发送线程。之前碰到一个团队把消息发送结果写入了 ClickHouse 做统计，每次回调都执行一次 INSERT，生产端 QPS 直接掉了一半。这是很常见的问题：发送是异步了，回调逻辑却是同步执行的。
回调函数应该保持轻量。通常我只在回调里做三件事：更新一个内存计数器用于监控、记录失败的消息到本地文件用于重试、或者干脆什么都不做。需要把发送结果同步到下游的业务逻辑，应该通过一个独立的线程池异步处理，而不是在回调里直接执行。
另外，重试机制也要做好约束。Kafka Producer 默认retries=2147483647，这是个大数字，配合retry.backoff.ms=100会导致一批消息反复重试，严重时阻塞后续消息发送。合理做法是设置一个明确的重试上限，比如retries=3，并且配合delivery.timeout.ms=120000防止重试拖太久。
3.3 压缩是“免费”的吞吐量红利
启用压缩之后，发送到 Broker 的数据量变小，网络带宽占用下降，Broker 写入磁盘的数据量也变小，这相当于同时优化了生产链路、网络链路和存储链路。关键是选对压缩算法。
Kafka 默认支持 gzip、snappy、lz4、zstd 四种。我实测的结果是：单条 500 字节到 2KB 的小消息场景，lz4 的 CPU 开销最低，压缩比和吞吐量综合表现最好；消息体以 JSON 文本为主、单条 4KB 以上时，zstd 压缩比更高，但 CPU 消耗也更大；gzip 压缩比最高但速度最慢，高吞吐场景下不建议用。如果生产者所在机器的 CPU 有富余，优先 zstd；CPU 紧张就用 lz4，收益最稳妥。
提示：如果 Topic 里的消息经过压缩后依然很大，那么问题可能不在消息队列本身，而是消息设计——一件商品订单是不是真的需要把整条购物车明细都塞进去？减少消息体体积比调任何参数效果都明显。
4. Broker 端调优：页缓存、顺序写和零拷贝，缺一不可
4.1 把“读消息”变成“读内存”
很多人以为 Broker 的吞吐瓶颈在磁盘，其实大多数场景下，磁盘的顺序读写速度并不差——机械盘顺序写也能到 100MB/s 以上，SSD 就更不用说了。真正容易出问题的是随机读。消息队列的优势设计在于顺序追加写入，以及用操作系统的 Page Cache 做读缓存。
Kafka 写入消息时，不是直接刷到磁盘，而是先写入 Page Cache，由操作系统异步刷盘。消费的时候，如果消息还在 Page Cache 里，直接走内存读取，完全不需要碰磁盘。这就是为什么一个数据量几百 GB 的 Kafka 集群，看起来磁盘IO很低，因为热数据都留在内存里了。
这个机制的调优含义是：不要让 Broker 进程占用的 JVM 堆内存太大，把内存留给操作系统做 Page Cache。有些团队反着来，把 Broker 的堆内存设成 16GB、24GB，内存一大，GC 停顿就频繁，而且留给 Page Cache 的空间就少了，热数据一旦被换出，消费端就要频繁读磁盘，吞吐量断崖式下跌。
我见到的生产环境中，Broker JVM 堆一般设置在 4GB 到 8GB 之间比较合理，剩余的系统内存尽量留给 Page Cache。具体堆大小要看分区数和消息缓存情况，但要铭记一个原则：堆是给代码对象用的，Page Cache 是给数据用的，数据量大的场景下 Page Cache 的优先级更高。
4.2 刷盘策略：数据安全与吞吐量的取舍
Broker 的刷盘策略决定了消息写入后多久落盘。Kafka 的配置项是log.flush.interval.messages（默认最大值）和log.flush.interval.ms（默认最大值），默认情况下依赖操作系统定期刷盘，这种“让 OS 帮你刷”的方式吞吐量最高，但机器断电时可能丢失最近几秒的消息。
如果业务场景要求消息不能丢，就需要同步刷盘。RocketMQ 的同步刷盘配置是FlushDiskType=SYNC_FLUSH，Kafka 里则通过acks=-1配合log.flush.*参数来保障。但同步刷盘有明显的性能代价，实测下来吞吐量下降约 30%-50%，这是可靠性和吞吐量的硬权衡，没有两头都占的方案。
我实际的做法是分场景区别对待：核心交易链路的消息用同步刷盘，接受吞吐量打折；日志、行为埋点这些允许丢几秒的消息走异步刷盘，拿满吞吐量。把不同可靠级业务拆到不同的 Topic/队列，而不是用一个队列所有消息通吃。
4.3 零拷贝：消费端高吞吐的隐藏功臣
消费者拉取消息时，数据从 Broker 到消费者经历的路径越短越好。传统的 IO 流程是：磁盘 → 内核读缓冲区 → 用户态缓冲区 → Socket 发送缓冲区 → 网卡。中间涉及两次用户态和内核态的切换，还有多次内存拷贝。而 Kafka 使用了sendfile系统调用，数据直接从 Page Cache 拷贝到网卡发送缓冲区，绕过了用户态拷贝，这就是“零拷贝”的核心。
这部分的优化主要靠框架本身，不暴露配置参数给使用者，但理解它有助于做出正确的部署决策：消费端尽量消费热数据（还在 Page Cache 里的消息），吞吐量最高；如果消费的是老数据（已经被换出 Page Cache），吞吐量会明显下降，这时不要怀疑消费端配置有问题，而是应该考虑分区数是否够用、数据保留时间是不是太长。
4.4 分区数是吞吐量的乘法因子，但不是越大越好
一个分区在一个消费组内最多被一个消费者线程消费，所以增加分区数可以直接提升消费并行度。但分区数不是越大越好。每个分区在 Broker 端都有对应的文件句柄和索引，分区数过多会导致文件句柄占用过高、分区切换耗时增加、Rebalance 的时间变长。
我通常会按“预期峰值吞吐量 ÷ 单分区消费能力”来估算分区数。假如单个分区的消费能力是 1000 条/秒，预期峰值 20000 条/秒，那么分区数至少 20。再留出 50% 的缓冲，设置成 30 到 32 比较合适。有很多团队把 Topic 分区分成几百个，结果每个分区的 Leader 副本分布不均，部分 Broker 热点严重，吞吐量反而上不去。
5. 消费者端调优：拉取模型、并发模型与位移管理
5.1 max.poll.records：一次拉多少条是门学问
消费者端吞吐量最直接的影响因素是单次拉取的消息数量。Kafka 的max.poll.records默认是 500 条。这个值设置得保守一些，可以减少单批处理时间，降低触发 Rebalance 的风险；如果调大，单次拉取的消息更多，网络往返次数减少，吞吐量通常能提升 20%-30%。
但调大max.poll.records有个隐患——如果消费逻辑较慢，这一批消息处理不完，超过了max.poll.interval.ms（默认 300000 毫秒），消费者会被判定失联并触发 Rebalance。所以我会把max.poll.records和处理耗时放在一起考虑：先实测单条消息的平均处理时间，再计算一批消息的总耗时，确保总耗时低于max.poll.interval.ms的 70% 左右，留出余量。
另外一个配套参数是fetch.min.bytes和fetch.max.wait.ms。默认配置下，Broker 有一条消息就会推给消费者，这样网络往返频繁但每次数据量小，吞吐量不佳。设置fetch.min.bytes=8192后，Broker 会攒够 8KB 数据再返回，fetch.max.wait.ms=500则规定了最多等多久，避免攒不够数据时请求一直悬挂。这两个参数配合起来，可以显著减少拉取请求的次数。
5.2 线程太多反而慢，并发模型要匹配分区数
消费者端的并发模型直白讲就是：一个分区在一个消费组内只能被一个消费者实例消费。如果你的 Topic 只有 6 个分区，那么消费者实例超过 6 个，多出来的实例也分不到分区，白白占用资源。这是很多人加线程后性能反而下降的原因之一——不是线程不够，而是分区不够分。
在单个消费者实例内部，通常使用线程池来并发处理消息。线程数并不是越大越好：线程切换有成本，消息处理如果涉及数据库写入、远程调用，线程过多还会打爆连接池。我的经验是线程数设置为“分区数 × (1 到 2)”比较稳妥。如果一个消费者分配了两个分区，线程池设 4 个线程就够用了；如果线程数太少，单个分区内的消息处理是串行的，吞吐量就受限于单条消息的处理耗时。
这里有一个容易踩的坑：并发处理消息意味着消息的消费顺序无法保证。如果业务要求同一个订单的多个消息严格有序，那么单纯增加消费线程必然导致乱序。这种情况下需要使用分区级别的顺序保证，把同一订单号的消息路由到同一个分区，然后在这个分区内单线程处理或者按 Key 做内存队列。吞吐量和顺序性之间的取舍，必须在设计阶段就想清楚，调优的时候改不出来。
5.3 位移提交的时机与重复消费的根源
消费者处理完一批消息之后提交位移。如果采用“先提交位移，再处理消息”的方式，消息处理期间消费者挂了，这批消息会丢；如果采用“先处理消息，再提交位移”的方式，消息处理完成但还没提交位移时消费者挂了，恢复后会重新拉取这批消息，产生重复消费。
这正是消息队列重复消费问题产生的根本原因。只要是“至少一次”（at least once）语义，重复消费就必然存在——不是 Bug，而是机制本身的产物。RabbitMQ 的 manual ack、Kafka 的 offset commit、RocketMQ 的消费位点记录，原理都一样。
处理重复消费的通用思路是业务侧幂等。三种最常见的做法：
- 数据库唯一约束。给业务表建唯一索引，比如订单号。重复插入时数据库会报冲突，捕获异常后跳过，天然幂等。这个方法最简单可靠，适合处理结果要落库的场景。
- Redis SETNX。用消息的唯一业务 ID 作为 Key，设置过期时间，SETNX 返回成功才处理，否则说明已经处理过。适用于对时效性要求高的场景。
- 业务状态机判断。比如订单状态是“已支付”时，重复收到“支付成功”消息直接忽略。适合业务本身有状态流转的场景。
// 以 Redis SETNX 为例的幂等判重伪代码 String bizKey = "order:paid:" + orderId; boolean firstTime = redis.setIfAbsent(bizKey, "1", Duration.ofMinutes(30)); if (!firstTime) { // 已经处理过这条消息，直接确认 consumer.acknowledge(); return; } try { processOrderPaid(orderId); consumer.acknowledge(); } catch (Exception e) { // 处理失败，删除判重 Key 允许重试 redis.delete(bizKey); throw e; }这里有个细节：如果处理失败，一定要把判重 Key 删掉，否则重试时会被幂等拦截，消息等于被“静默丢弃”。我在实际项目里见过这个坑，测试环境一切正常，上了生产之后重试机制全部失效，排查半天发现是幂等 Key 没有在失败时清理。
6. 别忽略上下游配套：JVM 调优和数据落库的联动优化
6.1 消费者进程的 JVM 调优要点
消息队列客户端本身是 JVM 进程，GC 停顿会直接阻塞消息的处理。消费者端 JVM 调优的核心是避免 Full GC。Full GC 期间整个进程停顿，轻则消息处理变慢，重则触发消费者失联。
我的配置思路是这样：
- 堆内存不要贪大。消费进程的堆设成 2GB-4GB 就足够，重点是控制 GC 停顿时间，不是让堆能装下更多对象。
- 使用 G1 收集器，并且显式设置目标停顿时间。
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+DisableExplicitGC。 - 注意堆外内存。如果消费者使用了 DirectByteBuffer 或者依赖 Netty，堆外内存不受堆大小控制，要单独配置
-XX:MaxDirectMemorySize，否则堆外内存溢出会导致进程崩溃，而这种崩溃 GC 日志里看不出任何异常。
Broker 端的 JVM 调优思路不太一样。前面说过，Broker 堆内存要克制，把内存留给 Page Cache。如果 Broker 的堆设置过大，GC 对象过多，Young GC 频繁，对吞吐量的影响很大。调整堆大小时还要看分区数和消息缓存的数据结构，这部分建议逐步调整，每次变更后跑一次压测对比。
6.2 消息落库：批量插入和索引设计
很多消息队列的业务场景最终要把消息处理结果写入数据库。如果每消费一条消息就执行一条 INSERT，数据库的写入吞吐会很快成为瓶颈，不管前面的队列调得多好，最后都堵在 SQL 上。
解决思路是攒批写入。消费线程处理完一批消息（比如 200 条），组装成一条批量 INSERT 语句插入：
INSERT INTO order_trade_log (order_id, amount, status, update_time) VALUES ('A001', 99.9, 'PAID', NOW()), ('A002', 199.9, 'PAID', NOW()), ('A003', 29.9, 'REFUNDING', NOW());批量插入比逐条插入快得多，因为减少了 SQL 解析、事务提交、网络往返等开销。实测中同样的数据量，批量插入 500 条/批比逐条插入快 10 倍以上。但也要注意控制单批大小，事务太大时锁持有时间过长，反而影响并发性能，一般每批控制在 200-500 行比较合适。
如果做了幂等判重，数据库表要提前建好唯一索引。否则并发量上来后，重复消息可能穿透检查，出现“插入了两条相同订单”的事故。用数据库唯一约束做幂等，埋在底层兜底，远比在应用层写一遍 if-else 可靠。
6.3 调优完成后如何验证效果
参数调整生效后不能只看一两个指标，要按照完整的链路重新压测对比。我自己会整理一张表格记录每次调整的参数、QPS、P99 延迟、Lag 趋势、GC 停顿时间。压测至少持续 15 分钟以上，确保数据稳定。短时间压测数据虚高，不能反映真实运行状态。
| 优化阶段 | QPS | P99 发送延迟 | CG 停顿 | Consumer Lag 趋势 |
|---|---|---|---|---|
| 基线（默认配置） | 3700 | 85ms | 频繁 Young GC | 持续增长 |
| 生产端批量+压缩 | 6100 | 40ms | 正常 | 缓慢增长 |
| 消费端参数调整 | 8200 | 38ms | 正常 | 基本持平 |
| 完整优化后 | 9600 | 41ms | 稳定 | 稳定 |
调优是一个持续迭代的过程，不是今天把参数改完就一劳永逸。流量模型变化、消息体大小变化、分区数调整，都会让原来的参数不再适配。每次大版本迭代或大促前，重新跑一遍压测、重新审视参数，这个习惯比任何一套“最佳实践”都管用。
7. 踩坑经验：我调整参数时犯过的几个典型错误
做吞吐量调优这几年，犯过的错误比成功案例更有参考价值。挑几个典型的写出来，大家少走弯路。
第一个错误是只调生产端参数，忽略了消费者端的位移提交频率。有一阵子我把生产端的 batch 参数优化得很漂亮，发送吞吐量上去了，但消费者每处理一条消息就提交一次位移，单条提交的网络开销让消费端吞吐量反而成了瓶颈。后来把位移提交改成每批消息处理完后提交一次，消费端吞吐量立刻上来了。位移提交的频率要跟消息处理频率匹配，不是越频繁越好——频繁提交带来额外的网络开销和磁盘写入。
第二个错误是盲目加大batch.size。以为 batch 越大吞吐量越高，结果发现大 batch 意味着更长的攒批时间，延迟飙升，而且消息总量不够多的时候，大 batch 根本攒不满，反而因为linger.ms到了上限才发，白白增加了延迟。batch 大小的设置要结合消息产生速率，消息来得慢，batch 再大也是空等。
第三个错误是忽略装饰者模式带来的额外损耗。消费者里做了多层消息处理链，每层都做一次反序列化和对象拷贝，虽然单次消耗只有几毫秒，但乘上几万条消息之后，对吞吐量的影响就非常可观了。优化后我把处理链精简为一次反序列化、一次业务处理、一次结果写出，吞吐量直接提升了 30% 以上。
最后一个想多说一句的坑是关于压测数据的真实性。测试环境的数据量、消息大小、消费逻辑都不能代表生产环境。我在测试环境调出来的完美参数，上生产之后经常“失灵”，因为生产环境的消息大小分布、数据倾斜、Broker 节点数量都不一样。所以重要的参数调整一定要在准生产环境验证，而且要用接近真实的数据模型，否则压测报告只是一张好看的报表。
