欢迎光临
我们一直在努力

kafka压测就是这么简单

前言

因为迁移了kafka集群,为了确保新环境正常,需要来做一些压力测试。这次压力测试重点会关注一些异常情况下,kafka收发消息的状况。

关于kafka集群的安装可参考上一篇文章。

kafka可能故障及结论

部分broker集群挂掉

若topic创建的时候设置了replication,那么一般来说,挂掉n-1 个节点都是没关系的。挂掉的broker对原来的消息收发几乎不产生任何影响。具体模拟步骤见本文kafka故障模拟。

整个broker集群挂掉

如果整个集群都连接不上了,肯定是避免不了丢消息。重发次数到了设定的值,或者发送请求超时了都会导致生产者丢弃该条消息,发送下一条消息。重试次数增多、发送请求超时设定长点可以减少“丢失”,但是只是相对的,实际上生产者到达超时时间或者重发次数之后还是会丢弃消息。若集群能够快速恢复,那么重试次数增多,发送请求超时时间增加是有意义的,可以相对使得生产者丢失的消息数目少一些。

磁盘故障

磁盘空间满,磁盘无法写入都可以划分为磁盘故障。磁盘空间满,删除策略与设置中的kafka删除策略有关系,不在本文的研究范围,下一篇文章会专门研究删除策略。

当某个broker上的磁盘发生故障时,分区leader在该broker上的分区都无法进行访问,broker server进程被阻塞。在磁盘故障没有被修复之前,整个kafka集群是不可用的。如果磁盘上的数据能及时恢复,并且磁盘重新进行工作的话,出现磁盘故障的broker就能够重新恢复服务。生产环境,需要做好监控,如果某个broker由于磁盘故障而不能服务,需要尽快下线该broker,触发分区复制,确保整个集群可用。

kafka压测过程

流量压测

使用kafka自带脚本进行压测,生产数据脚本是kafka-producer-perf-test.sh,消费数据脚本是:kafka-consumer-perf-test.sh。模拟大量的生产消费,看看在突发的大量数据的收发压力下,生产和消费是否会受影响。

生产者发送数据使用命令:kafka-producer-perf-test.sh ,命令具体为:

$ sh kafka-producer-perf-test.sh --topic kafka2-test --num-records 20000000 --record-size 1024 --throughput 500000 --producer-props bootstrap.servers=xxxx:9092
--topic topic名称
--num-records 总共需要发送的消息数
--record-size 每个记录的字节数
--throughput 每秒钟发送的记录数
--producer-props bootstrap.servers=localhost:9092 

消费者接受数据使用命令:kafka-consumer-perf-test.sh:

sh kafka-consumer-perf-test.sh --broker-list=xxx:9092 --topic kafka2-test   --show-detailed-stats --group kafka2-test-group --messages 20000000 --fetch-size 10000
--broker-list 指定kafka的链接信息
--topic 指定topic的名称
--fetch-size 指定每次fetch的数据的大小
--messages 总共要消费的消息个数

开启两个生产者,每个生产者生产2亿条消息,开始3个消费者,每个消费者消费2亿条消息。

实验结果:

生产者延迟:平均380ms,过程中生产消费都没有报错,服务器负载正常。

20000000 records sent, 80025.928401 records/sec (78.15 MB/sec), 381.76 ms avg latency, 6178.00 ms max latency, 349 ms 50th, 1122 ms 95th, 2031 ms 99th, 3209 ms 99.9th.





20000000 records sent, 80953.306133 records/sec (79.06 MB/sec), 377.17 ms avg latency, 6259.00 ms max latency, 283 ms 50th, 1449 ms 95th, 3402 ms 99th, 6028 ms 99.9th.

恢复测试

本次测试kafka为5节点,kafka2-test副本数为3个,按照逻辑来讲坏掉两个broker是不影响集群及数据的。

实验过程:

按照流量测试步骤,进行消息收发,过程中下线broker,观察是否有延迟变化、是否发生错误或者异常。

实验结果:

生产者延迟有所增加,延迟在570ms。

1

2

3

赞(2) 打赏
转载请注明来源:IT技术资讯 » kafka压测就是这么简单

评论 抢沙发

评论前必须登录!

 

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏