---
tags:
  - MQ
  - 性能调优
  - Kafka
  - JVM
create time: 2026-05-24 19:52
---

# MQ 性能调优

## 概述

MQ 的性能调优是一个系统工程，涉及 Producer、Broker、Consumer、JVM、操作系统多个层面。本文以 Kafka 为主线，从性能指标出发，逐层拆解调优策略，帮助你建立完整的调优方法论。

## 正文

### 性能指标三角

调优之前先明确目标。MQ 的核心性能指标有三个：

- **吞吐量（Throughput）**：每秒处理的消息数（msgs/sec）或字节数（MB/sec）
- **延迟（Latency）**：消息从发送到被确认/消费的时间，关注 P50、P99、P999
- **可用性（Availability）**：系统可正常服务的时间比例

> [!question]
> 吞吐量和延迟往往是矛盾的——批处理提升吞吐但增加延迟。你的业务场景更看重哪个？为什么？

### Producer 调优

Producer 是性能瓶颈的第一个关口。核心参数和调优思路：

**batch.size**（默认 16KB）：批量发送的消息大小上限。增大可以提升吞吐（减少网络往返），但增加内存占用和首次延迟。生产环境建议设为 64KB-1MB。

**linger.ms**（默认 0）：等待凑满 batch 的时间。默认 0 表示来一条发一条，设为 5-100ms 可以显著提升吞吐。和 batch.size 配合使用——达到任一条件即发送。

**compression.type**（默认 none）：压缩算法。`lz4` 性价比最高（压缩率和速度均衡），`zstd` 压缩率更好但 CPU 开销略高。压缩能显著减少网络带宽和磁盘占用。

**acks**：可靠性级别。
- `acks=0`：不等确认，最快但可能丢消息
- `acks=1`：Leader 确认，平衡选择
- `acks=all`：ISR 全部确认，最安全但最慢

**buffer.memory**（默认 32MB）：Producer 端发送缓冲区大小。高吞吐场景下如果 Broker 响应慢，缓冲区可能打满导致阻塞，可适当增大到 64-128MB。

### Broker 调优

Broker 是整个集群的性能中枢。

**刷盘策略**：Kafka 依赖页缓存和顺序写，刷盘策略直接影响性能。
- `flush.messages` 和 `flush.ms` 控制刷盘频率
- 生产环境建议**关闭主动刷盘**（设为超大值），依赖操作系统的页缓存和后台刷盘，配合多副本保证数据安全

**页缓存**：Kafka 的性能秘诀在于大量利用 OS 页缓存。消息写入先进页缓存，异步刷盘。消费者如果跟得上生产者，直接从页缓存读取，接近内存速度。

**网络线程和 IO 线程**：
- `num.network.threads`：处理网络请求的线程数，建议设为 CPU 核数
- `num.io.threads`：处理磁盘 IO 的线程数，建议设为 CPU 核数的 2 倍
- `num.replica.fetchers`：副本同步线程数，高吞吐场景可增大到 2-4

### Consumer 调优

Consumer 的调优重点在于批量拉取和并发处理。

**fetch.min.bytes**（默认 1）：一次 fetch 请求的最小数据量。增大可以减少网络往返次数，但增加延迟。建议设为 1KB-64KB。

**fetch.max.wait.ms**（默认 500ms）：等待凑满 fetch.min.bytes 的最大时间。配合 fetch.min.bytes 使用，在吞吐和延迟之间找平衡。

**max.poll.records**（默认 500）：单次 poll 返回的最大消息数。如果消费逻辑较重（如写数据库），适当减小避免处理超时。

**并发消费**：单个 Consumer 的吞吐有限，通常通过增加 Consumer 数量（不超过 Partition 数量）来提升并行度。

> [!question]
> Consumer 数量超过 Partition 数量会发生什么？如何在不增加 Partition 的情况下提升消费能力？

### JVM 调优

Kafka Broker 运行在 JVM 上，JVM 调优至关重要。

**堆大小**：不宜过大！Kafka Broker 推荐 4-6GB。堆越大 GC 停顿越长，而且 Kafka 的性能很大程度依赖页缓存——堆占了太多内存，页缓存就被挤压了。

**GC 选择**：
- **G1GC**：成熟稳定，适合 4-8GB 堆。关键参数 `-XX:MaxGCPauseMillis=20`
- **ZGC**：超低停顿（<10ms），适合大堆场景，JDK 15+ 生产可用

**直接内存**：Kafka 的网络传输使用堆外内存（DirectBuffer），需要通过 `-XX:MaxDirectMemorySize` 预留足够空间。

### 操作系统调优

操作系统层面的优化往往被忽视，但影响显著：

- **文件描述符**：Kafka 每个 Partition 对应多个日志段文件，需要大量 fd。建议设置 `ulimit -n 100000` 以上
- **TCP 参数**：增大缓冲区 `net.core.rmem_max=16777216`、`net.core.wmem_max=16777216`，启用 TCP 快速打开
- **vm.swappiness**：设为 1（非 0），避免系统过度 swap 导致 Broker 性能急剧下降
- **磁盘调度算法**：SSD 使用 `none`（noop）或 `mq-deadline`，避免 `cfq` 的高开销

### 基准测试工具

调优前后都要用数据说话。常用工具：

- **kafka-producer-perf-test**：Producer 吞吐和延迟测试
- **kafka-consumer-perf-test**：Consumer 吞吐测试
- **JMeter**：支持自定义场景的压测框架

### 性能瓶颈定位决策树

```mermaid
graph TD
    Start["性能不达标"] --> CheckWhere{"瓶颈在哪?"}
    CheckWhere -->|"Producer 端"| P["Producer 调优"]
    CheckWhere -->|"Broker 端"| B["Broker 调优"]
    CheckWhere -->|"Consumer 端"| C["Consumer 调优"]
    P --> P1["增大 batch.size"]
    P --> P2["增大 linger.ms"]
    P --> P3["开启压缩"]
    P --> P4["acks=1"]
    B --> B1["关闭主动刷盘"]
    B --> B2["增大网络/IO线程"]
    B --> B3["JVM 调优"]
    B --> B4["OS 参数调优"]
    C --> C1["增大 fetch.min.bytes"]
    C --> C2["增加并发消费者"]
    C --> C3["增大 max.poll.records"]
```

### Go 性能测试示例

```go
package main

import (
	"fmt"
	"sync/atomic"
	"time"

	"github.com/IBM/sarama"
)

func main() {
	config := sarama.NewConfig()
	config.Producer.RequiredAcks = sarama.WaitForLocal
	config.Producer.Compression = sarama.CompressionLZ4  // 开启压缩
	config.Producer.Flush.Bytes = 64 * 1024              // batch.size 64KB
	config.Producer.Flush.Frequency = 10 * time.Millisecond // linger.ms 10

	producer, _ := sarama.NewAsyncProducer([]string{"localhost:9092"}, config)
	defer producer.Close()

	var count int64
	msg := &sarama.ProducerMessage{
		Topic: "benchmark",
		Value: sarama.StringEncoder("test message payload"),
	}

	// 10 个 goroutine 并发发送
	for i := 0; i < 10; i++ {
		go func() {
			for {
				producer.Input() <- msg
				atomic.AddInt64(&count, 1)
			}
		}()
	}

	// 每秒输出吞吐量
	ticker := time.NewTicker(time.Second)
	for range ticker.C {
		n := atomic.SwapInt64(&count, 0)
		fmt.Printf("Throughput: %d msgs/sec\n", n)
	}
}
```

这段代码展示了 Sarama 异步 Producer 的基准测试：开启 LZ4 压缩、64KB 批量、10ms 等待时间，10 个 goroutine 并发发送，每秒统计吞吐量。通过调整参数组合对比不同配置下的性能表现。

## 关联笔记

- [[39-MQ-容器化与-K8s-部署]]
- [[41-MQ-测试策略]]
- [[42-MQ-认证与授权]]