kakfa
前言
因为迁移了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，观察是否有延迟变化、是否发生错误或者异常。
实验结果：
下线broker之后，该broker上面的leader分区无法访问，生产者开始刷出大量报错，约2分钟之后，所有生产者均开始重新恢复发送。消费者吞吐量开始降低后来恢复，启动kafka节点，整个集群可以马上恢复。
生产者延迟有所增加，延迟在570ms。
20000000 records sent, 54047.334656 records/sec (52.78 MB/sec), 565.70 ms avg latency, 39974.00 ms max latency, 782 ms 50th, 1363 ms 95th, 2384 ms 99th, 4039 ms 99.9th.
20000000 records sent, 52023.858141 records/sec (50.80 MB/sec), 588.22 ms avg latency, 39985.00 ms max latency, 48 ms 50th, 1178 ms 95th, 3483 ms 99th, 5302 ms 99.9th.
kafka集群皆为12c24g机器，2T ssd磁盘，压测过程中CPU约在30%-40%，系统负载在3-4。
结论
此次压测结果符合预期，生产已经对kafka完成切换，流量也已经切换到此kafka集群。
kafka作为分布式的消息系统，在集群可用性上还是做得比较完善的。在副本数充足的情况下发生节点故障，只会对生产和消费的速率产生一些影响，总体系统仍然是可用的。
压测瓶颈基本在网络带宽，只要带宽够用，那么kafka吞吐量是基本不用考虑了，只需要优化生产消费端就可以了。
本文如果有不对的地方，欢迎大家批评指正，共同学习。