【kafka性能测试脚本详解、性能测试、性能分析与性能调优】

guduadmin29小时前

Kafka 性能测试

一、介绍

Apache Kafka 官方提供了两个客户端性能测试脚本，它们的存放位置如下：

生产者性能测试脚本：$KAFKA_HOME/bin/kafka-producer-perf-test.sh

消费者性能测试脚本：$KAFKA_HOME/bin/kafka-consumer-perf-test.sh

kafka-producer-perf-test.sh 支持测试的性能指标包括：吞吐量（throughput）、最大时延（max-latency）、平均时延（avg-latency）；kafka-consumer-perf-test.sh 同样支持吞吐量指标，还提供了一些消费端特有的指标，但没有直接提供时延信息。

二、使用

2.1 kafka-producer-perf-test.sh

此脚本用于测试 Kafka 生产消息的性能，可选参数列表如下，加粗项为常用参数。

暂时无法在飞书文档外展示此内容

参数名	含义
-h, --help	显示使用帮助并退出
参数名	指定生产的消息发往的 topic
-h, --help	指定生产的消息总数
–topic	如果通过 --payload-file 指定了从文件中获取消息内容，那么这个参数的意义是指定文件的消息分隔符，默认值为 \n，即文件的每一行视为一条消息；如果未指定 --payload-file 则此参数不生效
–num-records	限制每秒发送的最大的消息数，设为 -1 表示不限制
–payload-delimeter	直接指定 Producer 配置，格式为 NAME=VALUE，例如 bootstrap.server=127.0.0.1:9092，通过此种方式指定的配置优先级高于 --producer.config
–throughput	指定 Producer 的配置文件，格式参照官方的 config/producer.properties
–producer-props	在测试结束后打印更详尽的指标，默认为 false
–producer-config	指定事务 ID，测试并发事务的性能时需要，只有在 --transaction-duration-ms > 0 时生效，默认值为 performance-producer-default-transactional-id
–print-metrics	在测试结束后打印更详尽的指标，默认为 false
–transactional-id	指定事务 ID，测试并发事务的性能时需要，只有在 --transaction-duration-ms > 0 时生效，默认值为 performance-producer-default-transactional-id
–transactional-duration-ms	指定事务持续的最长时间，超过这段时间后就会调用 commitTransaction 来提交事务，只有指定了 > 0 的值才会开启事务，默认值为 0
–record-size	指定每条消息的大小，单位是字节，和 --payload-file 两个中必须指定一个，但不能同时指定
–payload-file	指定消息的来源文件，只支持 UTF-8 编码的文本文件，文件的消息分隔符通过 --payload-delimeter 指定，和 --record-size 两个中必须指定一个，但不能同时指定

【示例】

bin/kafka-producer-perf-test.sh --topic perf-test --num-records 1000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=127.0.0.1:9092 compression.type=lz4

【输入解释】

发送 1000 条大小为 1KB 的消息到地址为 127.0.0.1:9092 的 broker 上的 perf-test 主题，发送时不限制吞吐量，并使用 lz4 算法压缩消息。

执行示例命令后，控制台输出一行测试结果，如下：

1000 records sent, 3424.657534 records/sec (3.34 MB/sec), 13.61 ms avg latency, 255.00 ms max latency, 13 ms 50th, 20 ms 95th, 255 ms 99th.

【输出解释】

成功消费了 1000 条消息，吞吐量为 3424.657534 条/秒 (或 3.34 MB/秒)，平均时延为 13.61 ms，最大时延为 255.00 ms，50 % 的消息延时在 13 ms 内，95 % 的消息延时在 20 ms 内，99 % 的消息延时在 255 毫秒内。

2.2 kafka-consumer-perf-test.sh

此脚本用于测试 Kafka 消费消息的性能，可选参数列表如下，加粗项为常用参数。

参数名	含义
–bootstrap-server	指定 broker 地址，必选，除非用 --broker-list 代替（不建议）
–topic	指定消费的 topic，必选
–version	输出 Kafka 版本
–consumer.config	指定 Consumer 配置文件
–date-format	指定用于格式化 *.time 的规则，默认为 yyyy-MM-dd HH:mm:ss:SSS
–fetch-size	指定一次请求消费的大小，默认为 1048576 即 1 MB
–from-latest	如果 Consumer 没有已经建立的 offset，则指定从 log 中最新的位点开始消费，而不是从最早的位点开始消费
–group	指定 ConsumerGroup ID，默认为 perf-consumer-40924
–help	显示使用帮助并退出
–hide-header	指定后不输出 header 信息
–messages	指定消费的消息数量，必选
–num-fetch-threads	指定 fetcher 线程的数量
–print-metrics	指定打印 metrics 信息
–reporting-interval	指定打印进度信息的时间间隔，默认为 5000 即 5 秒
–show-detailed-stats	指定每隔一段时间（由 --reporting-interval 指定）输出显示详细的状态信息
–socket-buffer-size	指定 TCP 的 RECV 大小，默认为 2097152 即 2 MB
–threads	指定消费的线程数，默认为 10
–timeout	指定允许的最大超时时间，即每条消息返回的最大时间间隔，默认为 10000 即 10 秒

【示例】

bin/kafka-consumer-perf-test.sh --bootstrap-server 127.0.0.1:9092 --topic perf_test --messages 1000000 --threads 8 --reporting-interval 1000 --show-detailed

【输入解释】

同时开启 8 个消费线程，从 127.0.0.1:9092 的 broker 上的 perf-test 主题中消费 1000 条消息，每隔 1000 ms = 1 s 打印一次消费进度信息。最后两个参数在消费数量很小的场景下没有什么帮助，比如若消费数量只有 1000，命令瞬间就可以执行返回；但当指定的消费数量很大（如示例中为 1000 万）时，需要 10 s 左右才能消费完，此时定时输出一下进度信息就显得很有用了。

执行示例命令后，控制台输出两行信息，其中第一行为表头，接下来的数行为每秒的进度信息，如下：

time, threadId, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg,nMsg.sec, rebalance.time.ms, fetch.time.ms, fetch.MB.sec,fetch.nMsg.sec
2021-03-25 15:57:59:426, 0, 657.2275, 657.2275, 673001,
673001.0000, 1616659078690, -1616659077690, 0.0000, 0.0000

…

【输出解释】

time：当前时间，格式由 --date-format 指定
threadId：线程 ID
data.consumed.in.MB：消费到的数据总大小，单位为 MB
MB.sec：消费 TPS，即每秒消费的消息大小
data.consumed.in.nMsg：消费到的总消息数
nMsg.sec：消费 TPS，即每秒消费的消息条数
rebalance.time.ms：消费者组重平衡的耗时，单位为 ms，0 表示没有发生重平衡
fetch.time.ms：fetch 线程的总耗时，单位为 ms
fetch.MB.sec：fetch 线程每秒钟获取到的消息大小
fetch.nMsg.sec：fetch 线程每秒钟获取到的消息数量
【注意】
若没有指定 --show-detailed，则输出信息中的前两项会有所不同，如下：

start.time, end.time, data.consumed.in.MB, MB.sec, …
- start.time：消费开始的时间，格式由 --date-format 指定
- end.time：消费结束的时间，格式由 --date-format 指定
  测试
  
  producer（生产者）
  
  partitions（分区）
  
  3个分区（partitions）
  
  –replication-factor 4 --partitions 3(test)
  1000 条大小为 1KB 的消息
```
bin/kafka-producer-perf-test.sh --topic test --num-records 1000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=192.168.1.5:9092 compression.type=lz4
```
  1000000 条大小为 1KB 的消息
```
bin/kafka-producer-perf-test.sh --topic test --num-records 1000000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=192.168.1.5:9092 compression.type=lz4
```
  –replication-factor 1 --partitions 3(test13)
  1000000 条大小为 1KB 的消息
  
  4个分区（partitions）
  
  –replication-factor 4 --partitions 4（testpro）
  1000000 条大小为 1KB 的消息
  
  –replication-factor 3 --partitions 4(testpro34)
  1000000 条大小为 1KB 的消息
  
  –replication-factor 1 --partitions 4(testpro14)
  1000000 条大小为 1KB 的消息
  
  5个分区（partitions）
  
  –replication-factor 4 --partitions 5(testpro45)
  1000000 条大小为 1KB 的消息
  
  –replication-factor 3 --partitions 5(testpro35)
  1000000 条大小为 1KB 的消息
  
  2个broker的集群
  
  4个副本3个分区（test）与4个副本5个分区（testpro45）生产1000000条数据对比：
  test吞吐量相对高一点点(高3 mb/sec)，而平均时延、最大时延、即生产各完成百分段时延都是testpro45较低
  
  4个副本3个分区（test）与4个副本4个分区（testpro）生产1000000条数据对比：
  testpro吞吐量高很多(高51 mb/sec)，而平均时延、最大时延、即生产各完成百分段时延都是testpro低
  
  3个副本4个分区（testpro34）与4个副本4个分区（testpro）生产1000000条数据对比：
  testpro吞吐量相对较高(高15 mb/sec)，而平均时延testpro34相对较低，最大时延testpro44相对较低，50%的消息时延testpro34较低，95%之后都是testpro的消息时延较低！
  
  4个副本4个分区（testpro）与4个副本5个分区（testpro45）生产1000000条数据对比：
  testpro吞吐量高很多(高54 mb/sec)，而平均时延、最大时延、即生产各完成百分段时延都是testpro低
  
  在同等条件下，消息数为1000000，分区数由小到大变化，其他参数不变，4个分区时，性能最优。
  
  compression（压缩算法）
  
  在同等条件下，消息数为1000000，压缩算法为gzip、snappy、lz4，其他参数不变，当采用lz4时吞吐量最高，而对于消息时延来说，gzip的平均和最大时延都是最低。
  
  建议只有在producer cpu资源充裕的情况下，才开启压缩，否则会使机器cpu资源耗尽，反而得不偿失;
  如果宽带资源比较紧张，建议开启压缩，可以使用zstd，极大的减少网络资源开销
  
  Consumer（消费者）
  
  compression（压缩算法）
  
  使用不同的压缩算法生产消息
  
  使用不同的解压缩算法消费消息
  
  在同等条件下，消息数为1000000，压缩算法为gzip、snappy、lz4，其他参数不变，当生产和消费消息时采用lz4时性能最优。
  
  threads（线程）
  
  bin/kafka-consumer-perf-test.sh --broker-list 192.168.1.5:9092 --topic test --messages 1000000 --threads 8 compression.type=lz4
```
bin/kafka-consumer-perf-test.sh --broker-list 192.168.1.5:9092 --topic test --messages 1000000 --threads 4
```
  threads 1
  
  获取消息的线程数与实际吞吐率影响不大。
  在增加分区数与消费线程数时，在小于3个分区时，3个分区与3个消费线程性能最优，在其他条件不改变的前提下，再进一步增加分区数与消费程数时，实际吞吐量变化不大。
  
  配置建议
  
  基于kafka的高度可配置的特性，可以应用到不同的业务场景，比如，实时性较强的跟踪用户在页面上的行为动作、实时性不高但可靠性很高的信用卡支付操作的处理等。
  
  可靠性配置：
  
  replication.factor
  
  副本因子，针对topic级别的配置参数是replication.factor，以本次测试为例，有3个broker实例，建议合理的复制系数为1-3，以3为例，也就是每个分区会被3个broker各复制一次，即每个broker保存一个分区，即使在2个broker失效的情况下，仍然可以向topic写入消息或从topic读取消息。总结如下：
  如果复制系数为N，那么在N-1个broker失效的情况下，仍然具备读写能力，因此更高的复制系数会带来更高的可靠性，但另一方面，N个复制系数需要至少N个broker，而且会有N份数据副本(副本包含leader与follower)。
  
  unclean.leader.election.enable
  
  不完全的leader选举，unclean.leader.election.enable在broker级别上进行配置，默认值为true(仅在当前版本为true，后续高版本为false)确保分区可从非 ISR 中选举 leader，官方在kafka高版本发行时，修改了这个默认值，暂时理解为官网的推荐设置，但对于实时性较高的业务，比如实时统计用户访问量的分析，一般会启用这个配置，即设置为true，但对于可靠性较高的业务，比如银行的业务，宁可花费几分钟或几个小时的延时后再处理像信用卡支付的业务，也不会冒险处理错误的消息。因此，按真实的业务场景来设置即为合理。
  
  min.insync.replicas
  
  最少同步副本，min.insync.replicas默认是1，本次测试中采用了3个broker，因此这个值可以设置1-3，当然如果选择3时，即为最少要同步3个副本才可以向分区写入数据，即为真正的提交，需要注意的是如果有1个broker出现问题，无法同步副本，那么剩下的broker就会停止生产者的所有请求，并抛出NotEnouqhReplicasException给生产者，直至问题broker恢复，此时消费者可以正常读取消息。
  
  producer
  
  producer发送确认，生产者可以选择3种不同模式的确认，acks为0时，只要生产者把消息发送出去，即认为已成功写入broker，这种模式下运行速度非常快，吞吐率和带宽利用率非常高，不过采用这种模式风险较高，容易丢失一些消息。一般压力测试都是基于这个模式的。使用实时性较高的系统，也不建议采用该模式。
  
  acks
  
  acks为1时，即为leader收到消息并写入分区数据文件(不一定同步到磁盘)后，提交成功，返回确认响应。
  acks为-1或all时，即leader收到消息后，会等待所有同步副本都收到消息，才会返回确认响应。
  
  acks = 0
  如果设置为零，则生产者将不会等待来自服务器的任何确认，该记录将立即添加到套接字缓冲区并视为已发送。在这种情况下，无法保证服务器已收到记录，并且重试配置将不会生效（因为客户端通常不会知道任何故障），为每条记录返回的偏移量始终设置为-1。
  acks = 1
  这意味着leader会将记录写入其本地日志，但无需等待所有副本服务器的完全确认即可做出回应，在这种情况下，如果leader在确认记录后立即失败，但在将数据复制到所有的副本服务器之前，则记录将会丢失。
  acks = all
  这意味着leader将等待完整的同步副本集以确认记录，这保证了只要至少一个同步副本服务器仍然存活，记录就不会丢失，这是最强有力的保证，这相当于acks= -1的设置。
  可以设置的值为：all, -1, 0, 1
  
  producer
  
  producer失败重试参数，当生产者没有收到成功的响应，重试发送次数，当前版本默认为0，根据实际业务来设置该参数，并非越大越好，也不建议设置为0，生产者收到的错误会包括2种，一种是可恢复性错误，一种是不可恢复性错误，遇到可恢复性的错误时，可以通过重试来解决，不可恢复性错误，只能由开发者手动处理。但由于网络原因造成的无法收到成功响应，此时如果无限次的重试发送，会造成分区内存在重复消息，增加了消费者读取消息时的业务处理的复杂度。因此分析实际业务场景，谨慎设置。
  
  consumer auto.offset.reset
  
  consumer auto.offset.reset，默认值为latest,即在没有offset时，消费者会从分区的末尾开始读取数据，减少读取重复消息的可能性，但可能会错过一些消息。设置为earliest，当出现offset不存在的情况时，从分区的开始位置读取数据，这样会读取大量重复消息，由消费端的业务逻辑来处理重复消息。增加了业务的复杂度。
  
  当kafka中没有初始offset或offset超出范围时将自动重置offset
  earliest:重置为分区中最小的offset;
  latest:重置为分区中最新的offset(消费分区中新产生的数据);
  none:只要有一个分区不存在已提交的offset,就抛出异常;
  
  consumer auto.commit.interval.ms
  
  consumer auto.commit.interval.ms，默认值为5000ms，即5秒提交一次，可以通过该参数来设置提交的频度，一般来说，提交频度越高，越会带来更高的系统开销，可靠性也随之提高。
  
  1、实时类业务
  
  实时类业务，把零延时作为第一考虑因素，比如聊天室、会议室、直播类似系统等，在保证最小延时的基础上，适当设置可靠性相关参数。建议可靠性参数如下：
```
replication.factor:1
unclean.leader.election.enable:true
min.insync.replicas:1
acks:0
retries:0
```
  2、近实时类业务
  
  即可接受一定范围内的延时，比如实时计算用户访问量等类似web监控类业务，在保证最小延时的基础上，适当设置可靠性相关参数。建议可靠性参数如下：
```
replication.factor:2
unclean.leader.election.enable:true
min.insync.replicas:2
acks:1
retries:1/2/3
consumer auto.commit.interval.ms:1000ms
consumer auto.offset.reset:latest
```
  3、非实时类业务
  
  非实时类业务，即可以允许一定时间的延时，从而来保证系统更高的可靠性。以3个broker以例，建议可靠性参数如下：
```
replication.factor:3 
unclean.leader.election.enable:false
min.insync.replicas:2/3
acks:all
retries:MAX_INT
consumer auto.commit.interval.ms:500ms
consumer auto.offset.reset:earliest
```