kafka选择分区数及kafka性能测试
1、简言
如何选择合适的分区，这是我们经常面临的问题，不过针对这个问题，在网上并没有搜到固定的答案。因此，今天在这里主要通过性能测试的工具来告诉如何选择相对应的kafka分区。
2、性能测试工具
kafka本身提供了比较的性能测试工具，我们可以使用它来测试适用于我们机器的kafka分区。
① 生产者性能测试
分别创建三个topic，副本数设置为1。
|
1
2
3
|
bin/kafka-topics.sh --zookeeper zk --create --replication-factor 1 --partitions 15 --topic test1
bin/kafka-topics.sh --zookeeper zk --create --replication-factor 1 --partitions 150 --topic test2
bin/kafka-topics.sh --zookeeper zk --create --replication-factor 1 --partitions 100 --topic test3
|
采用生产者性能测试工具来测试：
- num-records 100万条消息
- record-size 20480 每条消息是20K
- throughput 用来进行限流控制 当设置为0的时候不限流(尽量还是限流，否则很有可能kafka顶不住压力)，所以这里设置为每秒钟30000条消息数
|
1
|
bin/kafka-producer-perf-test.sh --topic topic --num-records 1000000 --record-size 20480 --throughput 30000 --producer-props bootstrap.servers="server01" acks=1
|
我们看实际的效果
15个分区结果
1000000 records sent, 6411.448282 records/sec (125.22 MB/sec), 253.02 ms avg latency, 1680.00 ms max latency, 108 ms 50th, 1026 ms 95th, 1173 ms 99th, 1650 ms 99.9th.
50个分区
1000000 records sent, 6274.549174 records/sec (122.55 MB/sec), 259.04 ms avg latency, 2163.00 ms max latency, 56 ms 50th, 1087 ms 95th, 1334 ms 99th, 2077 ms 99.9th.
100个分区
1000000 records sent, 6417.990912 records/sec (125.35 MB/sec), 253.42 ms avg latency, 2594.00 ms max latency, 38 ms 50th, 1154 ms 95th, 1331 ms 99th, 2537 ms 99.9th.
从中我们可以看出，分区数并不是越多越好，在吞吐量到达一定程度的时候，我们不一定要增大分区数，因为分区数过大，不会提升吞吐量（可以测试一下1000个分区甚至10000个分区，吞吐量会下降，这里就不一一演示），且会造成错误(后面解释)
② 消费者性能测试
|
1
|
bin/kafka-consumer-perf-test.sh --topic test5 --messages 100000 --broker-list "kafka-node1,kafka-node2"
|
消费者测试结果，我们知道kafka出来的数据单元为message，所以我们的messages就是kafka消费的条数
start.time（开始时间）, end.time（结束时间）, data.consumed.in.MB（消费的消息总量，单位为M）, MB.sec(消费吞吐量（MB/S）), data.consumed.in.nMsg（消费的消息总数）, nMsg.sec（按消息个数计算的吞吐量）, rebalance.time.ms（再平衡的时间，单位为ms）, fetch.time.ms（拉取消息的持续时间，单位为ms）, fetch.MB.sec（每秒拉取消息的字节大小，MB/S）, fetch.nMsg.sec（每秒拉取消息的个数） 2019-03-19 20:05:54:470, 2019-03-19 20:06:09:001, 1954.3359, 134.4942, 100062, 6886.1056, 3904, 10627, 183.9029, 9415.8276
这是消费者拉取数据测试的结果，我们也可以多测不同分区的几组数据，获得一个合适的kafka分区数据，来保证我们集群的稳定运行。
当然，如果想要测试其他参数，可以使用下图的方式，同理我们的生产者压测也可以通过此方式知道每个参数的含义
3、分区数决定吞吐量？
分区是kafka中最小的并行操作单元，对生产者而言，每一个分区的数据写入是完全可以并行化的；但是，对消费者而言，kafka只允许单个分区中的消息被一个消费者线程消费，一个消费组的消费并行度完全依赖于所消费的分区数。
如果按照这种方法看来，如果一个主题中的分区数越多，理论上所能达到的吞吐量就越大，那么事实真的如此么？
我们可以使用我们生产者与消费者测试工具进行相应的测试。(可以看根据上面的，多测几组数据)
实际测试过程中，我们可以发现，开始的时候，随着分区的增长，相应的吞吐量也跟着上涨，一旦分区数超过了某个阈值后，整体的吞吐量是不升反降的，也就是说，并不是分区数越多，吞吐量就越大。
因此我们在实际的选择分区过程中，要尽量的多测几组数据，找到一个合适的值，这也告诉我们，在实际生产者过程中，我们自己要去做好测试，而不是去想当然的得出结论。
实践，是检验真理的唯一标准。
并且，一味的增加分区数并不能使我们的吞吐量得到提升，还会因为超过系统的默认值，引起kafka进程崩溃。本人在生产环境中，将kafka分区数设置的过大，曾导致在实时流环境中，kafka进程多次崩溃。迫不得已的修改系统参数。
我们可以试着在一台普通的linux机器上创建包含10000个分区的主题，执行完成后通过jps查看kafka进程是否还存在，一般情况下，会导致kafka进程崩溃，这个时候，我们可以打开kafka的日志服务文件，发现日志服务文件中出现大量的异常。
java.io.IOException: Too many open files
这是一种常见的linux系统错误，通常意味着文件描述符不足。这一般发生在创建线程，创建socket，打开文件的场景下，在linux的系统的默认设置下，它只有1024。
我们可以通过ulimit -n命令查看，当然，我们也可以查看kafka的文件描述符：
当我们kafka进程崩溃后，这里的文件描述符将是0，表明它已经达到了上限。当然，对于大数据集群来说，文件描述符太小也不太合适，我们可以适当增加这个参数的值。但是，我们并不能无限制的去增加kafka的分区数，这是没有必要的。我们只需要通过压测的方式寻找最适合自己kafka的分区数就OK了。
并且，kafka的分区数还会影响系统的可用性。
我们知道，kafka通过多副本机制来实现集群的高可用和高可靠性，每个分区都会有一至多个副本，每个副本存在于不同的broker节点，并且只有leader副本对外提供服务，在kafka集群内部，所有的副本都采用自动化的方式进行管理，并确保所有副本中的数据都能保持一定程度的同步。
当broker发生故障时，leader副本所属宿主的broker节点上的所有分区都将暂时处于不可用的状态，此时，kafka会自动在其他follwer副本中选举出新的leader用于接收客户端的请求。
整个过程由kafka控制器负责，分区在进行leader角色切换的过程中会变得不可用，对于单个分区来说，它是非常短暂的，但是如果集群中的某个broker节点宕机，那么就会有大量的分区需要进行leader角色切换，这个切换的过程中会消耗一笔可观的时间。
分区数越多，也会让kafka的正常启动和关闭的耗时变得越长，与此同时，主题的分区数越多，不仅会增加日志清理的耗时，而且在被删除的过程中也会耗费更多的时间，对旧版的kafka而言，分区数越多，也会增加他们的开销，不过这个问题在新版的生产者和消费者的客户端已经得到解决了。
如果我们的kafka集群数量比较少的话(小几十台)，假设我们有3台broker节点，我们可以设定分区数为3，6，9。当然，最好的办法还是结合我们的压测去判断，尽量选择合适的kafka分区数。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。
原文链接：https://yrxpt.blog.csdn.net/article/details/88853771