kafka如何通过centos进行性能测试

在 CentOS 上对 Kafka 进行性能测试

一 环境准备与基线检查

• 准备 Kafka 集群与客户端工具：确保 Kafka 已安装 且各节点配置一致；在 CentOS 上准备好 Kafka 安装目录的 bin/ 工具（如 kafka-topics.sh、kafka-producer-perf-test.sh、kafka-consumer-perf-test.sh）。
• 网络与防火墙：开放 9092（或实际使用的端口）；多机压测时确保客户端到 Broker、Broker 之间网络稳定、带宽充足。
• 存储与系统：优先使用 SSD/NVMe；检查磁盘 IOPS/吞吐 与 文件系统；合理设置 ulimit -n（文件句柄）。
• 基线健康：用 kafka-topics.sh 检查 Topic 的 Partition/ReplicationFactor/ISR 正常；用 kafka-consumer-groups.sh 观察 Consumer Lag 为 0 或接近 0 的稳态。
• 认证与安全：若启用 SASL/Kerberos/SSL，准备客户端配置文件（如 kafka-client.properties），并在命令中通过 –command-config 指定。

二 使用 Kafka 自带脚本进行基准测试

• 创建测试 Topic（示例：10 分区、3 副本）
  • 命令：
    • 新版：/usr/local/service/kafka/bin/kafka-topics.sh --create --topic test_topic_001 --partitions 10 --replication-factor 3 --bootstrap-server broker1:9092,broker2:9092,broker3:9092 --command-config /usr/local/service/kafka/config/kafka-client-properties.conf
    • 旧版（ZooKeeper）：/usr/local/service/kafka/bin/kafka-topics.sh --create --topic test_topic_001 --partitions 10 --replication-factor 3 --zookeeper zk1:2181,zk2:2181,zk3:2181
• 生产者压测（示例）
  • 命令：
    • /usr/local/service/kafka/bin/kafka-producer-perf-test.sh --topic test_topic_001 --num-records 50000000 --record-size 300 --throughput -1 --producer-props bootstrap.servers=broker1:9092,broker2:9092,broker3:9092 --producer.config /usr/local/service/kafka/config/kafka-client-properties.conf acks=1
  • 常用关键参数：
    • acks：1/0/all（吞吐 vs 可靠性权衡）
    • batch.size / linger.ms：增大可提升吞吐（如 batch.size=16384~131072，linger.ms=10~50）
    • compression.type：none/snappy/lz4/zstd（通常 lz4/zstd 在吞吐与 CPU 间较优）
    • buffer.memory：如 67108864
• 消费者压测（示例）
  • 命令：
    • /usr/local/service/kafka/bin/kafka-consumer-perf-test.sh --bootstrap-server broker1:9092,broker2:9092,broker3:9092 --topic test_topic_001 --messages 50000000 --threads 1 --consumer.config /usr/local/service/kafka/config/kafka-client-properties.conf --print-metrics
  • 常用关键参数：
    • fetch-size：1048576 或更高（单次拉取更大）
    • threads：并发消费线程数（建议 ≤ 分区数）
• 结果判读要点
  • 生产者输出示例：
    • 50000000 records sent, 645103.022953 records/sec (184.57 MB/sec), 149.40 ms avg latency, 969.00 ms max latency, 5/607/750/853 ms (p50/p95/p99/p99.9)
  • 消费者输出示例：
    • start.time, end.time, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg, nMsg.sec, rebalance.time.ms, fetch.time.ms, fetch.MB.sec, fetch.nMsg.sec
    • 例如：448.07 MB/s、1566121.66 nMsg/s，rebalance.time.ms 反映再均衡开销。

三 测试场景设计与执行顺序

• 单变量法：一次只调整一个变量（如 消息大小、分区数、ack、batch.size/linger.ms、压缩、线程数），便于归因。
• 消息大小 vs 吞吐：固定分区/副本/线程，分别测试 100/200/400/800/1000/2000/5000 字节 的吞吐（records/s 与 MB/s 的变化趋势）。
• 分区数 vs 并行度：固定其他条件，测试 1~9 个分区 的吞吐，观察并行度提升带来的上限与拐点。
• 吞吐与延迟权衡：
  • 高吞吐：acks=1，batch.size=131072，linger.ms=50，compression.type=lz4，throughput=-1
  • 低延迟：acks=1，batch.size=8192，linger.ms=0，compression.type=none
• 稳定性与再均衡：多轮长时间运行（如 10~30 分钟），观察 rebalance.time.ms、Lag 是否持续增长、错误/超时率。
• 认证与安全场景：在命令中引入 –command-config 与 –producer.config/–consumer.config，覆盖 SASL/Kerberos/SSL 的真实链路。

四 关键指标与瓶颈定位

• 生产者关键指标
  • 吞吐：records/s、MB/s；延迟：avg/max/p95/p99/p99.9；错误/超时率；批处理率（每批消息数）。
• 消费者关键指标
  • 吞吐：MB.sec、nMsg.sec；rebalance.time.ms（再均衡开销）；fetch.time.ms；Consumer Lag（滞后）。
• Broker 侧观察
  • 请求处理率、请求队列大小、网络吞吐、磁盘 IO 使用率/await、GC 暂停时间、ISR 收缩情况。
• 常见瓶颈与对策
  • CPU：增加 Broker/客户端并行度，使用高效压缩（如 lz4/zstd），优化 JVM 参数。
  • 内存：适度增大 buffer.memory，避免频繁 GC；控制消息堆积。
  • 磁盘 I/O：使用 SSD/NVMe，分散日志目录，合理段大小与刷盘策略。
  • 网络：提升带宽，增大批次与压缩减少网络包数。
  • 分区与并行度：分区数不足会限制吞吐；消费者线程数不宜超过分区数。

五 自动化与报告输出

• CSV 报告：生产者支持 CSV Reporter，便于后续用 Excel/Python/Prometheus 分析趋势与对比。
• 监控联动：压测同时采集 Broker/JVM/OS 指标（如节点监控、GC 日志、网络/磁盘监控），与脚本输出对齐时间戳进行分析。
• 第三方压测工具（可选）：在复杂场景或需要分布式施压时，可补充 JMeter（Kafka 插件）、Tsung、Gatling（Kafka 插件） 进行补充验证。