Kafka在Debian上的性能测试如何进行

在 Debian 上进行 Kafka 性能测试

一环境准备

安装 Java 与 Kafka
- 安装 OpenJDK 11：sudo apt update && sudo apt install openjdk-11-jdk -y
- 下载并解压 Kafka（示例版本 3.6.1）： wget https://downloads.apache.org/kafka/3.6.1/kafka_2.13-3.6.1.tgz tar -xzf kafka_2.13-3.6.1.tgz && mv kafka_2.13-3.6.1 /opt/kafka
启动 Zookeeper 与 Broker（单节点演示）
- /opt/kafka/bin/zookeeper-server-start.sh /opt/kafka/config/zookeeper.properties &
- /opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties &
快速连通性验证
- /opt/kafka/bin/kafka-topics.sh --bootstrap-server localhost:9092 --list
可选使用 Docker 快速起测（便于隔离环境）
- docker pull wurstmeister/kafka:3.0.0
- docker run -e KAFKA_BROKER_ID=1
  -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092
  -e KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181
  -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092
  -d --name kafka3 wurstmeister/kafka:3.0.0

二基准测试步骤

创建测试主题（建议多分区以匹配并发）
- /opt/kafka/bin/kafka-topics.sh --bootstrap-server localhost:9092
  –create --topic perf-test --partitions 8 --replication-factor 1
生产者压测
- 小消息、无压缩、不限速基线 /opt/kafka/bin/kafka-producer-perf-test.sh
  –topic perf-test --num-records 10000000 --record-size 100
  –throughput -1
  –producer-props bootstrap.servers=localhost:9092
  acks=1 batch.size=16384 linger.ms=0 compression.type=none
- 1KB 消息、LZ4 压缩、适度攒批 /opt/kafka/bin/kafka-producer-perf-test.sh
  –topic perf-test --num-records 10000000 --record-size 1024
  –throughput -1
  –producer-props bootstrap.servers=localhost:9092
  acks=1 batch.size=65536 linger.ms=10 compression.type=lz4
消费者压测
- 单线程 /opt/kafka/bin/kafka-consumer-perf-test.sh
  –bootstrap-server localhost:9092 --topic perf-test --messages 10000000
  –threads 1 --print-metrics
- 多线程 /opt/kafka/bin/kafka-consumer-perf-test.sh
  –bootstrap-server localhost:9092 --topic perf-test --messages 10000000
  –threads 8 --print-metrics
常用参数提示
- 生产者：acks（吞吐/持久性权衡）、batch.size、linger.ms、compression.type、buffer.memory
- 消费者：–threads（并发度）、–fetch-size（单次拉取字节）、–group（消费者组）

三监控与结果解读

关键指标
- 生产者：吞吐量（records/s、MB/s）、平均/最大延迟、请求耗时分布
- 消费者：吞吐量（MB/s、records/s）、重平衡时间、fetch 耗时、消费者滞后（Consumer Lag）
监控手段
- JMX：使用 JConsole/VisualVM/jmxtrans 直连 Broker 的 JMX 端口观察请求处理率、请求队列、网络/磁盘、GC 等
- Prometheus + Grafana：通过 JMX Exporter 暴露指标并可视化
- 辅助工具：Kafdrop（Topic/消费者组可视化）、Kafka Offset Monitor（轻量查看滞后）
结果示例与判读
- 生产者示例输出：100000 records sent, 25000.0 records/sec (24.41 MB/sec), 15.2 ms avg latency, 293.0 ms max latency
  - 含义：吞吐约 25k 条/秒，平均延迟 15.2 ms，最大 293 ms；随时间稳定说明系统趋于稳定
- 消费者示例输出：data.consumed.in.MB=1024.00, MB.sec=17.07, data.consumed.in.nMsg=1048576, nMsg.sec=17476.27, rebalance.time.ms=20, fetch.time.ms=60000
  - 含义：消费速率 17.07 MB/s（约 1.75 万条/秒），重平衡 20 ms，fetch 时间接近测试时长表示持续拉取

四测试场景与参数建议

吞吐优先（高吞吐配置）
- acks=1，batch.size=131072，linger.ms=50，compression.type=lz4，buffer.memory=67108864
低延迟优先（快速确认）
- acks=1，batch.size=8192，linger.ms=0，compression.type=none
端到端延迟
- 生产端写入带时间戳（如 System.currentTimeMillis()），消费端计算当前时间差作为延迟分布
扩展测试
- 逐步增加分区数、并发生产者/消费者数量，观察吞吐是否近似线性扩展
- 变更副本数（replication.factor）观察可用性/持久性与吞吐的权衡
稳定性与瓶颈定位
- 长时间运行（如 ≥1 小时）观察是否出现重平衡风暴、错误率上升、磁盘/网络饱和
- 常见瓶颈：CPU（压缩/网络栈）、磁盘 I/O（顺序写/刷盘策略）、网络（带宽/包大小）、JVM GC（堆大小与停顿）

最新问答