1 整体环境说明

1.1 硬件环境

1、 磁盘：SATA磁盘2块，磁盘阵列为RAID1

2、 CPU****：2个4核CPU。具体参数：Intel(R) Xeon(R) CPU E5405 @ 2.00GHz

3、 内存：8G（8*1G）

4、 网卡：1000Mb/s

1.2 软件环境

1、 kafka版本：kafka_2.11-0.11.0.3

2、 kafka集群数量：3

3、 zookeeper版本：zookeeper-3.4.12

4、 zookeeper集群数量：3

5、 zookeeper使用单独的集群，不使用kafka自带zookeeper

2 服务器自身瓶颈测试

由于kafka是的吞吐量特别大，所以先考虑集群服务器的自身瓶颈。如磁盘IO瓶颈。由于kafka做的集群所以需要相互传输数据，所以要考虑网卡瓶颈。

2.1 测试磁盘IO瓶颈

2.1.1 磁盘IO写入瓶颈

1、使用以下命令测试磁盘IO的写入瓶颈

# sync;time -p bash -c "(dd if=/dev/zero of=test.dd bs=1M count=20000)"

解释：在当前目录下创建一个test.dd的文件，写入20000个1M的数据。

2、使用iostat命令监测磁盘io情况。

使用命令

# iostat -x 1

解释：扩展查看io性能，每1秒钟刷新一次。

注意：如果没有iostat。请执行yum install sysstat –y命令进行安装iostat命令

3、结果展示

（1）磁盘写入IO结果

# sync;time -p bash -c "(dd if=/dev/zero of=test.dd bs=1M count=20000)"

记录了20000+0 的读入

记录了20000+0 的写出

20971520000字节(21 GB)已复制，221.314 秒，94.8 MB/秒

real 221.67

user 0.01

sys 21.20

磁盘写入IO为94.8 MB/秒

（2）iostat命令结果

关注wkB/s和%util两个参数

wkB/s：每秒写入设备的数据量（单位：KB）

%util：消耗在I/O请求中的CPU时间百分比（设备带宽利用率）。如果该值接近100%说明设备出现了瓶颈。

2.1.2 磁盘IO读取瓶颈

1、使用以下命令测试磁盘IO的读取瓶颈

# hdparm -tT --direct /dev/sda

解释：hdparm命令是显示与设定硬盘的参数。-t参数为评估硬盘的读取效率(不经过磁盘cache)。-T参数为评估硬盘的读取效率(经过磁盘cache)

注意：如果没有hdparm命令可以直接yum –y install hdparm即可

2、使用iostat命令监测磁盘io情况。

使用命令

# iostat -x 1

3、结果展示

# hdparm -tT --direct /dev/sda

/dev/sda:

 Timing O_DIRECT cached reads: 326 MB in 2.00 seconds = 162.83 MB/sec

 Timing O_DIRECT disk reads: 322 MB in 3.01 seconds = 106.88 MB/sec

解释：经过磁盘cache的磁盘读取为162.83 MB/sec

未经过磁盘cache的磁盘读取为106.88 MB/sec

2.2 磁盘性能总结

以我的服务器SATA磁盘2块，磁盘阵列为RAID1的配置。磁盘写入数据瓶颈为94.8 MB/秒。读取数据瓶颈经过磁盘cache的磁盘读取为162.83 MB/秒，未经过磁盘cache的磁盘读取为106.88 MB/秒。如果kafka集群的写入速度和读取数据的速度达到这个数值，或者iostat的输出结果%util的值接近100%。说明磁盘已经到达一个瓶颈。会影响压测数据的准确性。

2.3 网卡性能总结

我的网卡是千兆网卡，传输数据可以达到1000Mb/s，由于我们使用的单位都为MB/s。所以把Mb换算成MB。1000Mb/s=125MB/s。也就是说传输熟读到达125MB/s的时候是网卡的瓶颈。会影响压测数据的准确性。

3 Kafka测试前期准备

3.1 影响测试结果配置分析

Kafka的性能测试主要测试kafka的吞吐量，kafka吞性能为生产者在向kafka传入消息时的写入量，kafka的吐性能为消费者在kafka集群中消费的能力，也就是读取量。

3.1.1 Borker相关

Kafka的borker是kafka集群的缓存代理，消息中间件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。下面是相关broker的参数分析。

1、num.partiton

topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。

Partition的数量选取也会直接影响到Kafka集群的吞吐性能。例如我们接口如果开了多个线程去消费kafka的数据，当Partition数量相对于流入流出的数据量显得较少，或由于业务逻辑和Partition数量没有匹配好造成个别Partition读写数据量大，大量的读写请求集中落在一台或几台机器上时就会很影响效率。

2、Default.replication.factor

Replication参数为kafka集群副本数。这个参数决定了kafka的高可用性。也决定了kafka的吞吐量。此数据运算和broker个数和broker上的分区数量都有关系。正常broker为3replication设置为1最好。因为3个节点的集群可以宕机一台可以继续工作，而3个replication可以保证宕机两个节点正常工作。所以多replication会造成资源浪费。如果数据不需要持久化和数据不重要并且写入量特别大的话，可以考虑replication为0。

3、num.network.thread

用于接收并处理网络请求的线程数，默认为3。其内部实现是采用Selector模型。启动一个线程作为Acceptor来负责建立连接，再配合启动num.network.threads个线程来轮流负责从Sockets里读取请求，一般无需改动，除非上下游并发请求量过大。

4、写入数据每条大小

'{"indexdiy":"catalina","input_type":"log","message":"[2018-09-26 12:30:13,030] [org.apache.tomcat.util.net.NioSelectorPool] [INFO] [Using a shared selector for servlet write/read]","offset":17600578,"project_tag":"catalina","source":"/opt/tomcat7/logs/catalina.out","type":"log"}'

以上面一条日志为例。此条日志大小为283B。所以我们测试基准为200B和500B。

3.1.2 Consumer相关

Consumer为kafka的消费者，同一个topic消费者越多越快，但是需要注意的是，消费者的数量不能超过topic的分区数量，因为每个topic的每个分区只能被一个消费者消费，多出来的消费者会无信息可消费。导致资源浪费。

3.2 测试命令详解

1、创建topic命令

# ./kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test -7

--replication-factor：指定副本个数
--partitions：指定分区个数
--topic：指定topic名

2、查看topic命令

# ./kafka-topics.sh --zookeeper 10.10.4.11:2181 --list

3、查看指定topic的详细内容

# ./kafka-topics.sh --zookeeper 10.10.4.11:2181 --topic test_property --describe

5、 写入数据

# ./kafka-producer-perf-test.sh --num-records 10000000 --topic test-ref-9 --record-size 500 --throughput 100000 --producer-props bootstrap.servers=10.10.4.11:9092,10.10.4.12:9092,10.10.4.13:9092

--num-records：记录的条数
--topic：指定topic的名字
--record-size：一条记录大小。
--throughput：吞吐数量
--producer-props bootstrap.servers=IP:9092,IP:9092,IP:9092：指定kafka集群

注意：-- throughput参数为写入数量，如果结果接近此数量，建议*10再测试一次。因为和此结果相近说明kafka没有到达瓶颈。

6、消费数据

# ./kafka-consumer-perf-test.sh --messages 10000000 --threads 3 --zookeeper localhost:2181 --num-fetch-threads 3 --topic test-ref-8

--messages：指定消费条目数
--threads：指定线程数
--num-fetch-threads 3：指定消费人数

注意：执行以上命令在kafka****家目录下的/bin****下执行命令

4 Kafka写入性能测试

在测试kafka写入性能测试的时候一边检测系统的cpu使用情况、内存使用情况和磁盘IO情况。

4.1 测试kafka的partition参数

4.1.1 创建不同partition的topic并写入数据1000万条数据。

1、 创建一个副本，partition分别为1、3、6、12的topic分别为test-0、test-1、test-2、test-3

2、 向topic内写入1000万条500B的数据，一次写入100万条，replication为1。并且开启另一个窗口使用iostat命令实时监控磁盘IO情况。

4.1.2 测试结果

1、写入数据如下表

3、 磁盘IO情况

由于磁盘IO瓶颈在94.8 MB/秒得出的数据只有partition为1的情况下在60MB/秒。所以大多数情况下%util处于一个100%的状态。在partition为1的情况下是隔两秒会出现%util值为100%。

4.2 kafka的partition参数总结

由于压力测试没有到达kafka的瓶颈，而是到达了服务器的瓶颈。所以以上数据仅供参考。如想测试更准确的数据。需要性能更好的磁盘来做测试。

在其他数据相同，而partition不同的时候。结论是partition越多写入速度越快。但是partition数量越多会照成kafka集群可用性越差。所以建议，在实际生产环境。有多少个broker，partition数就为多少。这样可以保证kafka集群的高可用性。可以保证n-1/2个节点宕机而不影响kafka集群使用。

4.3 测试Kafka的replication参数

4.3.1 创建不同replication的topic并写入数据1000万条数据。

1、创建一个副本，replication分别为2和3的topic为test-4、test-5。和之前创建的test-1。一起做测试

2、向topic内写入1000万条500B的数据，一次写入100万条，partition为3（因为我的broker是3个）。并且开启另一个窗口使用iostat命令实时监控磁盘IO情况。

4.3.2 测试结果

1、写入数据如下表

2、磁盘IO情况

由于磁盘IO瓶颈在94.8 MB/秒得出的数据只有replication为3的情况下在70MB/秒。所以大多数情况下%util处于一个100%的状态。在replication为3的情况下也是一直%util值为100%。

4.4 kafka的replication参数总结

由于压力测试没有到达kafka的瓶颈，而是到达了服务器的瓶颈。所以以上数据仅供参考。如想测试更准确的数据。需要性能更好的磁盘来做测试。

在其他数据相同，而replication不同的时候。结论是replication越少写入速度越快。但是replication数量越少会照成kafka集群可用性越差。所以建议，在实际生产环境。Kafka集群broker为3的时候replication为1，可以保证一台节点宕机集群可用。其他架构需继续深入研究。

4.5 测试Kafka的network.thread参数

1、 修改配置文件network.thread的参数为1，重启kafka进行对test-1进行写入测试。

2、 和之前test-1的数据进行对比。

4.5.1 测试结果

1、写入数据如下

2、磁盘IO情况

磁盘已经到达瓶颈。

4.6 Kafka的network.thread参数总结

从结果可看出kafka的network.thread参数越多写入速度越快。但是增加的非常不明显。除非写入速度要求极高的情况，或者机器性能足够好。其他情况建议使用默认值3即可。

4.7 测试kafka的单条数据大小参数

1、 修改命令--record-size参数。

2、 同往test-1里写入进行测试

4.7.1 测试结果

1、写入数据如下

2、磁盘IO情况

磁盘已经到达瓶颈。

4.8 Kafka的单条数据大小参数总结

从结果显示证明如果写入kafka的数据量单条越小，传输速度越快。正常我们的日志大约在300B每条，最大为500B每条。所以我们按照最大的数据量进行传输来测试写入量。

5 Kafka写入数据测试整体总结

在kafka写入数据的时候，主要参数在于partition的数量、replication的数量及单条数据的大小。对于线程数对写入速度并不是特别影响。在测试的时候观察cpu使用情况和内存使用情况。Kafka在有写入的时候对于本身的内存要求不大，jvm设置为1G就可以，但是kafka机制是kafka先写入系统页缓存内，所以需要的内存比较大。不建议和使用内存较大的应用部署在一台机器上，如elasticsearch。如果服务器内存较大，建议kafka使用4G左右jvm。Kafka对cpu要求不是特别大。一般两核以上就可以。

6 Kafka读取性能测试

在测试kafka读取性能测试的时候一边检测系统的cpu使用情况、内存使用情况和磁盘IO情况。

注意事项：写入数据后等一段时间再进行测试，因为可能有些数据还在内存中，所以看不出磁盘IO的瓶颈。

6.1 测试kafka的partition参数

1、由于之前已经写入1000万数据，可以直接在test-0、test-1、test-2、test-3的topic 并且Consumer为3、线程为3。直接读取这些数据进行测试。

6.1.1 测试结果

1、读取数据如下表

2、磁盘IO情况

磁盘IO有时会到达瓶颈，但是次数不多。

6.2 Kafka的partition参数总结

压测结果证明partition越多速度越快，实际情况我们建议和之前一样。有多少个broker，partition数就为多少。这样可以保证kafka集群的高可用性。可以保证n-1/2个节点宕机而不影响kafka集群使用。详细情况kafka写入测试的partition总结。

6.3 测试Kafka的consumer参数

以test1为测试topic。分别使用1、3、6个consumer来进行读取测试。

6.3.1 测试结果

1、写入数据如下表

2、磁盘IO情况

磁盘IO有时会到达瓶颈，但是次数不多。

3、 使用软件KafkaOffsetMonitor监控不同consumer的滞留情况lag为滞留信息条目数

（1）一个consumer三个partition

（2）三个consumer三个partition

（3）三个consumer六个partition

6.4 kafka的consumer参数总结

从测试结果可以看出，consumer这个参数不是越多越好，而是和topic的partition相同时性能最优，如果consumer大于partition的时候，测试开始会报错，内容大意为，有xx个consumer是没有分区可以消费的。这个参数可以根据项目本身去定义。但是不要超过topic的partition数目。但是consumer少会有消息滞留现象。

6.5 测试Kafka的线程参数

通过test-1 topic进行测试。

6.5.1 测试结果

1、 写入数据如下表

2、 磁盘IO

6.6 kafka的线程参数总结

从测试结果来看线程数并不影响kafka的写入速度。

7 Kafka读取性能总结

Kafka写入性能主要在于partition参数和consumer参数。Partition参数和的具体值可以直接参考写入性能总结，这里不再赘述。Consumer的性能测试来看，只要不多于partition的数量都是可以的。如果broker的数量比较多，建议多设置几个。

Kafka读取对于replication无关，因为replication不参与读取，只做容灾备份的。对线程数也没那么大的关系。

读取数据对cpu负载不是特别高，2核以上够用，如果是实时读取数据，对磁盘来说性能要求并不高，因为短时间内，一些数据都是在内存里可以直接取到的。

8 Kafka整体性能总结

对于ELK集群来说，整体性能还是比较好的，一般影响测试结果都是磁盘的瓶颈造成的。对于磁盘来说用SATA磁盘就可以，因为kafka的写入读取机制都是顺序写入、读取的。SATA顺序读写速度大约在53MB/s和SSD的顺序读取都是差不多的。如果做RAID建议做RAID5。

Kafka对于CPU和内存要求不是特别大，一般CPU建议在8核以上，内存建议在8G以上。如果服务器性能好kafka的jvm建议设置4G。

Kafka在我的测试环境下，broker为3的集群情况下。Replication参数为1，partition参数为3，线程数为3，consumer数为3，输入读取的文件大小为500B。整体kafka的写入速度为242665条/秒，传输大小为115.71 MB/秒。读取速度为241390条/秒，传输大小为115MB/秒。

但是以上数据几乎都是遇到了磁盘IO的瓶颈，数据不是特别准确，希望可以有更好的环境，对kafka进行更全面的测试。

最后没有贴上整体数据

吞

吐