kafka集群压测与优化

影响kafka集群性能的因数有多个，网络带宽、cpu、内存、磁盘读写速度、副本数、分区数、broker数量、内存缓存等因素都会影响kafka集群的性能

1.优化kafka集群配置

server.properties配置文件优化

num.network.threads=4
num.io.threads=4
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
num.recovery.threads.per.data.dir=1
log.retention.hours=72

num.network.threads：网络线程数，建议设置为CPU核心数的2倍

num.io.threads：磁盘I/O线程数，建议设置为CPU核心数的2倍

num.recovery.threads.per.data.dir：数据目录用来日志恢复的线程数目，配置多线程可加快恢复速度

log.retention.hours：消息保留时间，不适宜保留太长

socket.send.buffer.bytes和socket.receive.buffer.bytes：这两个参数控制Kafka Broker与客户端之间的TCP缓冲区大小，建议将它们设置为128KB或256KB，也可以通过以下的方式计算

假设如果您的网络带宽为1Gbps，消息大小为10KB，磁盘吞吐量为100MB/s，可用内存为8GB，则可以计算出以下缓冲区大小：

socket.send.buffer.bytes：1Gbps / 8 = 125MB/s，因此可以将其设置为1MB

socket.receive.buffer.bytes：100MB/s / 8 = 12.5MB/s，因此可以将其设置为128KB

producer.properties配置文件优化

compression.type=lz4
batch.size=16384
linger.ms=5
buffer.memory=33554432

compression.type：这个参数控制消息的压缩方式，如果您的应用程序发送大量的消息，则可以将其设置为gzip或snappy，以减少网络带宽和磁盘使用，一般设置为lz4，用以提升性能

buffer.memory：默认值是 32MB，可以根据实际情况来调整这个值。如果你的应用程序需要发送大量的消息，可以将 buffer.memory 设置为较大的值，例如 1GB，这样可以确保 Producer 有足够的内存缓存消息，但也会消耗更多的内存资源。如果你的应用程序发送的消息比较少，可以将 buffer.memory 设置为较小的值，例如 64MB，这样可以节省内存资源

batch.size：表示每个批次(batch)的大小，即在 Kafka Producer 发送数据时，会将数据先缓存在内存中，当缓存的数据大小达到 batch.size 时，Producer 才会将这些数据一次性发送出去，默认值为 16KB

linger.ms：表示消息在缓存区中等待发送的时间，即如果数据没有达到 batch.size，但是等待了 linger.ms 时间后，Producer 也会将这些数据发送出去，默认值为 0，即数据必须立即发送

这两个参数的配置对 Kafka Producer 性能和消息延迟都有影响。较小的 batch.size 和较大的 linger.ms 可以降低消息延迟，但可能会降低吞吐量；而较大的 batch.size 和较小的 linger.ms 可以提高吞吐量，但可能会增加消息延迟

这两个参数的一些优化见解

1.如果你的应用程序需要低延迟，可以将 batch.size 设置为较小的值，例如 1KB，并将 linger.ms 设置为 0，这样可以尽快将消息发送出去，但可能会影响吞吐量

2.如果你的应用程序需要高吞吐量，可以将 batch.size 设置为较大的值，例如 64KB，并将 linger.ms 设置为较小的值，例如 5ms，这样可以提高吞吐量，但可能会增加消息延迟

3.如果你的应用程序需要同时兼顾延迟和吞吐量，可以将 batch.size 和 linger.ms 都设置为适当的值，例如 16KB 和 10ms

4.如果你的消息大小比较固定，可以根据消息大小来调整 batch.size 的大小，例如如果消息大小为 1KB，可以将 batch.size 设置为 10KB，这样可以确保每个批次中有足够的消息，但不会浪费太多内存

总的来说还是需要根据数据的实际场景来配置，逐步去调整大小，然后观察并发量和延迟，以达到最优的效果

kafka-server-start.sh 启动项的优化

调整 JVM 参数

KAFKA_HEAP_OPTS="-Xmx4G -Xms4G"

一般HEAP 大小不超过主机内存的50%

副本数的优化，一般配置3个，副本数太少不安全，副本数太多，同步数据会占用性能

分区数的优化，按道理来说分区数越大，写入数据的并发量就越大

kafka集群节点数量优化，节点数越多，性能越强大

2.压测kafka集群

首先得另外搭建一台kafka主机，执行压测脚本必须有kafka服务，最好搭建一个zabbix，监控kafka集群主机，可以更好的看出cpu、磁盘io、内存、网络哪一个到达了瓶颈

搭建zabbix参考：zabbix搭建_Apex Predator的博客-CSDN博客

配置监控主机参考：zabbix监控linux主机_Apex Predator的博客-CSDN博客

 搭建单节点kafka：kafka单节点快速搭建_Apex Predator的博客-CSDN博客

 在kafka集群中分别创建3分区的主题和6分区的主题副本数都设置为3看一下压测情况

bin/kafka-topics.sh --create --bootstrap-server 10.1.60.112:9092 --partitions 3 --replication-factor 3 --topic apex

bin/kafka-topics.sh --create --bootstrap-server 10.1.60.112:9092 --partitions 6 --replication-factor 3 --topic cs 

在新建的单节点上执行生产者的压测命令 

 bin/kafka-producer-perf-test.sh --topic apex --producer-props bootstrap.servers=10.1.60.112:9092,10.1.60.114:9092,10.1.60.115:9092 --record-size 1024 --num-records 1000000 --throughput -1

命令解析

--producer-props：指定 Kafka Producer 的配置参数，其中 bootstrap.servers 表示 Kafka Broker 的地址，多个 Broker 地址用逗号分隔

--record-size：每个请求的大小单位为字节，1024字节，即1kb

--num-records：总共 请求的数目，1000000个请求

--throughput：指定 Producer 的吞吐量，单位是消息数/秒。默认值为 -1，表示尽可能快地发送消息

  bin/kafka-producer-perf-test.sh --topic cs --producer-props bootstrap.servers=10.1.60.112:9092,10.1.60.114:9092,10.1.60.115:9092 --record-size 1024 --num-records 1000000 --throughput -1

 先来说一下上面输出的意思是什么

records sent：每秒发送的请求数

records/sec：平均每秒的流量值

avg latency：最小延迟时间

max latency：最大延迟时间

分析对两个不同分区数据的topic进行压测的数据可以看到，3分区的topic平均每秒并发6万左右，6分区的topic平均每秒并发10万左右，所以说分区数越大并发量就越大

看一下zabbix监控下kafka集群主机的性能消耗

 

可以看到并未达到瓶颈，一般来说测试生产者为单节点，更容易达到网络瓶颈，所以建议使用多台生产者机器同时对kafka压测更能测试出kafka集群的极限

在新建的单节点上执行消费者的压测命令 

bin/kafka-consumer-perf-test.sh --topic apex --broker-list 10.1.60.112:9092,10.1.60.114:9092,10.1.60.115:9092 --fetch-size 10000 --messages 1000000 --threads 1

 命令解析

--fetch-size：指定每个拉取请求（fetch request）拉取的最大字节数，这里为"10000"字节

--messages：指定要消费的消息数量，这里为"1000000"条消息

--threads：指定用于消费消息的线程数，这里为"1"个线程，线程数量也会影响消费性能

 bin/kafka-consumer-perf-test.sh --topic cs --broker-list 10.1.60.112:9092,10.1.60.114:9092,10.1.60.115:9092 --fetch-size 10000 --messages 1000000 --threads 1

 先来说一下上面输出的意思是什么

start.time：测试开始时间

end.time：测试结束时间

data.consumed.in.MB：总的消费数据量，单位为MB

MB.sec：消费数据的速率，单位为MB/s

data.consumed.in.nMsg：消费的消息数量

nMsg.sec：消费消息的速率，单位为条消息/s

rebalance.time.ms：消费者重新平衡所需的时间，单位为毫秒

fetch.time.ms：拉取消息所需的时间，单位为毫秒

fetch.MB.sec：拉取数据的速率，单位为MB/s

fetch.nMsg.sec：拉取消息的速率，单位为条消息/s

通过消费以上两个不同topic可以看出，分区数量大小对消费的并发量也有影响，以上的数据不是kafka集群的性能极限，而是消费者节点的性能极限，若是使用多个消费者可以更好的测出kafka集群的极限性能

消费者节点网络性能接近极限值

 kafka集群网络性能还远远没有达到极限

 

 

本人搭建的kafka集群主机单节点配置为4核cpu12GB内存100GB机械磁盘