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

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