一、Kafka机器数量计算
Kafka机器数量（经验公式）= 2 *（峰值生产速度 * 副本数 / 100）+ 1
先拿到峰值生产速度，再根据设定的副本数，就能预估出需要部署Kafka的数量。
1）峰值生产速度
峰值生产速度可以压测得到。
2）副本数
副本数默认是1个，在企业里面2-3个都有，2个居多。
副本多可以提高可靠性，但是会降低网络传输效率。
比如我们的峰值生产速度是50M/s。副本数为2。
Kafka机器数量 = 2 *（50 * 2 / 100）+ 1 = 3台
二、Kafka分区数计算
（1）创建一个只有1个分区的topic
（2）测试这个topic的producer吞吐量和consumer吞吐量。
（3）假设他们的值分别是Tp和Tc，单位可以是MB/s。
（4）然后假设总的目标吞吐量是Tt，那么分区数 = Tt / min（Tp，Tc）
例如：producer吞吐量 = 20m/s；consumer吞吐量 = 50m/s，期望吞吐量100m/s；
分区数 = 100 / 20 = 5分区
分区数一般设置为：3-10个
一、性能评估
1.14.1 单broker性能评估
我们做单broker性能评估的目的包括以下几方面：
1)为我们进行资源申请评估提供依据；
2)让我们更了解集群的读写能力及瓶颈在哪里，针对瓶颈进行优化；
3)为我们限流阈值设置提供依据；
4)为我们评估什么时候应该扩容提供依据；
1.14.2 topic分区性能评估
1)为我们创建topic时，评估应该指定多少分区合理提供依据；
2)为我们topic的分区扩容评估提供依据；
1.14.3 单磁盘性能评估
1)为我们了解磁盘的真正读写能力，为我们选择更合适Kafka的磁盘类型提供依据；
2)为我们做磁盘流量告警阈值设置提供依据；
1.14.4 集群规模限制摸底
1）我们需要了解单个集群规模的上限或者是元数据规模的上限，探索相关信息对集群性能和稳定性的影响；
2）根据摸底情况，评估集群节点规模的合理范围，及时预测风险，进行超大集群的拆分等工作；
二、压力测试
1.测试目的
本次性能测试在正式环境下单台服务器上Kafka处理MQ消息能力进行压力测试。测试包括对Kafka写入MQ消息和消费MQ消息进行压力测试，根据10w、100w和1000w级别的消息处理结果，评估Kafka的处理性能是否满足项目需求。（该项目期望Kafka能够处理上亿级别的MQ消息）
2.测试范围及方法
2.1测试范围概述
测试使用Kafka自带的测试脚本，通过命令对Kafka发起写入MQ消息和Kafka消费MQ消息的请求。模拟不同数量级的MQ消息写入和MQ消息消费场景，根据Kafka的处理结果，评估Kafka是否满足处理亿级以上的消息的能力。
2.2性能测试场景设计
2.2.1Kafka写入消息压力测试
测试场景 | MQ消息数 | 每秒写入消息数 | 记录大小(单位:字节Byte) |
Kafka消息写入测试 | 10W | 2000条 | 1000 |
100W | 5000条 | 1000 | |
1000W | 5000条 | 1000 |
2.2.2Kafka消费消息压力测试
测试场景 | 消费MQ消息数 |
Kafka消息消费测试 | 10W |
100W | |
1000W |
2.3测试方法简要描述
Kafka 官方自带压力测试脚本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。Kafka 压测时，可以查看到哪个地方出现了瓶颈（CPU，内存，网络 IO）。一般都是网络 IO达到瓶颈
2.3.1测试目的
验证带台服务器上Kafka写入消息和消费消息的能力，根据测试结果评估当前Kafka集群模式是否满足上亿级别的消息处理能力。
2.3.2测试方法
在服务器上使用Kafka自带的测试脚本，分别模拟10w、100w和1000w的消息写入请求，查看Kafka处理不同数量级的消息数时的处理能力，包括每秒生成消息数、吞吐量、消息延迟时间。Kafka消息吸入创建的topic命名为test_perf，使用命令发起消费该topic的请求，查看Kafka消费不同数量级别的消息时的处理能力。
压测命令信息：
测试项 | 压测消息数（单位:W） | 测试命令 |
写入MQ消息 | 10 | ./kafka-producer-perf-test.sh --topic test_perf --num-records 100000 --record-size 1000 --throughput 2000 --producer-props bootstrap.servers=10.150.30.60:9092 |
100 | /kafka-producer-perf-test.sh --topic test_perf --num-records 1000000 --record-size 2000 --throughput 5000 --producer-props bootstrap.servers=10.150.30.60:9092 | |
1000 | ./kafka-producer-perf-test.sh --topic test_perf --num-records 10000000 --record-size 2000 --throughput 5000 --producer-props bootstrap.servers=10.150.30.60:9092 | |
消费MQ消息 | 10 | ./kafka-consumer-perf-test.sh --zookeeper localhost:2181 --topic test_perf --fetch-size 1048576 --messages 1000000 --threads 1 |
100 | ./kafka-consumer-perf-test.sh --zookeeper localhost:2181 --topic test_perf --fetch-size 1048576 --messages 10000000 --threads 1 |
kafka-producer-perf-test.sh 脚本命令的参数解析（以100w写入消息为例）：
--topic topic名称，本例为test_perf
--num-records 总共需要发送的消息数，本例为100000
--record-size 每个记录的字节数，本例为1000
--throughput 每秒钟发送的记录数，本例为5000
--producer-props bootstrap.servers=localhost:9092 （发送端的配置信息，本次测试取集群服务器中的一台作为发送端,可在kafka的config目录，以该项目为例：/usr/local/kafka/config；查看server.properties中配置的zookeeper.connect的值，默认端口：9092）
3.测试环境
3.1测试环境机器配置表
4.测试结果
4.1测试结果说明
本次测试针对Kafka消息处理的能力 进行压力测试，对Kafka集群服务器中的一台进行MQ消息服务的压力测试，关注Kafka消息写入的延迟时间是否满足需求。对Kafka集群服务器中的一台进行MQ消息处理的压力测试，验证Kafka的消息处理能力。
4.2测试结果
4.2.1写入MQ消息
压测结果截图
写入100w消息压测结果
699884 records sent, 139976.8 records/sec (13.35 MB/sec), 1345.6 ms avg latency, 2210.0 ms max latency.
713247 records sent, 141545.3 records/sec (13.50 MB/sec), 1577.4 ms avg latency, 3596.0 ms max latency.
773619 records sent, 153862.2 records/sec (14.67 MB/sec), 2326.8 ms avg latency, 4051.0 ms max latency.
773961 records sent, 154206.2 records/sec (15.71 MB/sec), 1964.1 ms avg latency, 2917.0 ms max latency.
776970 records sent, 154559.4 records/sec (15.74 MB/sec), 1960.2 ms avg latency, 2922.0 ms max latency.
MQ消息写入测试结果解析：
本例中写入100w条MQ消息为例，每秒平均向kafka写入了4.77MB的数据，大概是4999.875条消息/秒，每次写入的平均延迟为1毫秒，最大的延迟为647毫秒，1ms内占99%。
4.2.2消费MQ消息
压测结果截图
消费10w消息压测结果
消费100w消息压测结果
消费1000w消息压测结果
kafka-consumer-perf-test.sh 脚本命令的参数为：
--zookeeper 指定zookeeper的链接信息，本例为localhost:2181 ；
--topic 指定topic的名称，本例为test_perf，即4.2.1中写入的消息；
--fetch-size 指定每次fetch的数据的大小，本例为1048576，也就是1M
--messages 总共要消费的消息个数，本例为1000000，100w
以本例中消费100w条MQ消息为例总共消费了953.66M的数据，每秒消费数据大小为177.19M，总共消费了10000004条消息，每秒消费185804.53条消息。
吞吐量受网络带宽和fetch-size的影响
start.time, end.time, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg, nMsg.sec
2021-08-03 21:22:57:671, 2021-08-03 21:23:41:938, 514.7169, 11.6276, 5397198, 121923.7355
5.结果分析
根据4.2.测试结果，可以看出在单台服务器上，写入MQ消息设置5000条/秒时，消息写入及时，95%的消息延迟时间小于等于1ms，在可接受范围内；Kafka消费MQ消息时，1000W待处理消息的处理能力在每秒20w条以上，处理结果理想。
根据Kafka处理10w、100w和1000w级的消息时的处理能力，可以评估出Kafka集群服务，是否有能力处理上亿级别的消息。
本次测试是在正式环境集群服务中的单台服务器上进行，基本不需要考虑网络带宽的影响。所以单台服务器的测试结果，对评估集群服务是否满足上线后实际应用的需求，很有参考价值。
原文链接：
Kafka性能测试内容
kafka的测试主要分为producer端的吞吐量，consumer端的吞吐量，以及判断影响两者的因素。在实际测试环境中，需根据具体情况调整测试的数据量与参数。
性能测试工具：
- kafka-producer-perf-test.sh (生产端)
- kafka-consumer-perf-test.sh (消费端)
性能测试环境：
三台同样的虚拟机作为kafka broker，IP地址为192.168.1.81-192.168.1.83，配置如下：
CPU 内存 磁盘 | |
4core 16G 100G |
一、Producer端性能测试
a. Partition分区与速率的关系
方法：建立两个topic, 两个topic除了partition数量不一致外其他参数完全一致，使用kafka-producer-perf-test.sh进行测试。
过程：
首先建立两个topic，分别为test_part1与test_part2:
kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test_part1 --partitions 1 --replication-factor 1
kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test_part2 --partitions 5 --replication-factor 1
test_part1进行测试跑批：
kafka-producer-perf-test.sh --topic test_part1 --num-records 2000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092
运行结果：
2000000 records sent, 136211.945788 records/sec (25.98 MB/sec), 1002.59 ms avg latency, 2559.00 ms max latency, 801 ms 50th, 2271 ms 95th, 2538 ms 99th, 2553 ms 99.9th.
test_part2进行测试跑批：
kafka-producer-perf-test.sh --topic test_part2 --num-records 2000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092
运行结果：
2000000 records sent, 187529.301453 records/sec (35.77 MB/sec), 520.00 ms avg latency, 2196.00 ms max latency, 336 ms 50th, 1922 ms 95th, 2159 ms 99th, 2190 ms 99.9th.
结论：Producer端传输效率和partition数成正比。
b. Replication副本数与速率的关系
方法：首先建立两个topic, 两个topic除了replication数量不一致外其他参数完全一致，使用kafka-producer-perf-test.sh进行测试。
过程：
首先建立两个topic，分别为test_rep1与test_rep2:
kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test_rep1 --partitions 1 --replication-factor 1
kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test_rep2 --partitions 1 --replication-factor 3
test_rep1进行跑批测试：
kafka-producer-perf-test.sh --topic test_rep1 --num-records 2000000 --record-size
运行结果：
2000000 records sent, 217438.573603 records/sec (41.47 MB/sec), 610.43 ms avg latency, 1387.00 ms max latency, 497 ms 50th, 1284 ms 95th, 1341 ms 99th, 1386 ms 99.9th.
test_rep2进行跑批测试：
kafka-producer-perf-test.sh --topic test_rep2 --num-records 2000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092
运行结果：
2000000 records sent, 103423.311614 records/sec (19.73 MB/sec), 1353.03 ms avg latency, 4050.00 ms max latency, 1213 ms 50th, 3042 ms 95th, 3998 ms 99th, 4047 ms 99.9th
结论：Producer端传输效率和replication数量成反比。
C. 传输的数据记录大小与速率的关系
方法：向一个topic写入大小不同的数据记录，检验是否对速率有影响。
过程：
首先建立一个test topic：
kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test --partitions 3 --replication-factor 3
使用小数据块跑批：
kafka-producer-perf-test.sh --topic test --num-records 1000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092
运行结果：
1000000 records sent, 149231.457991 records/sec (28.46 MB/sec), 814.24 ms avg latency, 1334.00 ms max latency, 810 ms 50th, 1290 ms 95th, 1327 ms 99th, 1333 ms 99.9th.
使用大数据块跑批：
kafka-producer-perf-test.sh --topic test --num-records 1000000 --record-size 2048 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092
运行结果：
1000000 records sent, 22161.155926 records/sec (43.28 MB/sec), 637.75 ms avg latency, 1598.00 ms max latency, 576 ms 50th, 959 ms 95th, 1547 ms 99th, 1580 ms 99.9th.
结论：Producer端传输数量和单条记录大小成正比。
二、Customer端性能测试
由于kafka-consumer-perf-test.sh返回结果并不像producer端那么简洁易懂，这里解释一下，这个命令会返回类似以下的结果：
2019-11-18 13:47:53:297, 2019-11-18 13:47:55:078, 190.7349, 107.0943, 1000000, 561482.3133
总共六个参数：
第一个是开始时间；
第二个是结束时间；
第三个是本次消费了多少MB数据；
第四个是本次消费的速率MB/S；
第五个是总的消费数据条数；
第六个是每秒消费数据条数。
a. Partition与速率的关系
方法：首先建立两个topic, 两个topic除了partition数量不一致外其他参数完全一致，使用kafka-consumer-perf-test.sh进行测试。
过程：
建立topic，这里沿用Customer端测试过程中建立的test_part1和test_part2.
test_part1进行跑批测试：
kafka-consumer-perf-test.sh --topic test_part1 --messages 1000000 --threads 1 --num-fetch-threads 1 --zookeeper 192.168.1.81:2181
运行结果：
2018-12-18 13:47:53:297, 2018-12-18 13:47:55:078, 190.7349, 107.0943, 1000000, 561482.3133
test_part2进行跑批测试：
kafka-consumer-perf-test.sh --topic test_part2 --messages 1000000 --threads 1 --num-fetch-threads 1 --zookeeper 192.168.1.81:2181
运行结果：
2018-12-18 13:51:43:887, 2018-12-18 13:51:45:619, 190.7349, 110.1241, 1000000, 577367.2055
结论：Customer端消费效率和partitions数成正比（但影响不大）。
b. Threads线程与速率的关系
方法：在一个topic中消费相同的数据，使用不同的threads，比较速率大小。
过程：建立Topic，这里沿用Customer端测试过程中建立过的test。
使用一个线程消费时：
kafka-consumer-perf-test.sh --topic test --messages 500000 --threads 1 --num-fetch-threads 1 --zookeeper 192.168.1.81:2181
运行结果：
2018-12-18 14:11:32:106, 2018-12-18 14:11:32:951, 95.3671, 112.8604, 500000, 591715.9763
使用三个线程消费时：
kafka-consumer-perf-test.sh --topic test --messages 500000 --threads 3 --num-fetch-threads 1 --zookeeper 192.168.1.81:2181
运行结果：
2018-12-18 14:12:54:716, 2018-12-18 14:12:54:718, 95.3671, 47683.5270, 500000, 250000000.0000
使用六个线程消费时：
kafka-consumer-perf-test.sh --topic test --messages 500000 --threads 6 --num-fetch-threads 1 --zookeeper 192.168.1.81:2181
运行结果：
2018-12-18 14:14:12:935, 2018-12-18 14:14:12:938, 95.3671, 31789.0180, 500000, 166666666.6667
结论：Cumsomer端消费速率和thread成正比，但是达到一定数量(parttion数量)以后趋于平稳，再增加也不会继续变大。
Kafka性能测试结论
由于每个kafka集群环境差异都很大，本文不代表所有情况。
但是一个通常的kafka生产集群以下特性是应该达到的：
1.单个consumer的消费速率必须远大于单个producer的生产速率。
2.单个broker数据生产效率不应小于50M/s，否则增加JVM内存，并增加缓冲区大小。
