文章目录
补充：关于参数解读，请看这个链接
一、如何选择合适的分区数
怎么选择合适的分区数，下面用四个小主题来说明：
1.1 性能测试工具（这里用kafka脚本去测试）
这里用kafka的kafka-producer-perf-test.sh和kafka-consumer-perl-test.sh
1）生产者举例：向一个只有一个分区和一个副本的主题topic-1中发送100W条信息，并且每条信息大小为1MB，生产者对应的acks参数为1
bin/kafka-producer-perf-test.sh --topic topic-1 --num-records 1000000 --record-size 1024
--producer-props bootstrap.servers=localhost:9092 acks=1
2）生产者脚本参数说明
--topic 指定主题名字，参数是主题名字
--num-records 指定发送消息的总条数，参数是数字
--record-size 用来指定每条消息的总条数，参数是数字
--throughput 用来进行限流控制，当设定的值小于0时不限流，当设定的值大于0时，当发送的吞吐量大于该值时就会被阻塞一段时间（参数可以加例如100）
--print-metrics 指定之后就会打印很多测试信息，不用加参数
(打印参数部分说明：50th 、95th、99th表示处理百分之50、95、99消息的耗时)
3）消费者脚本
bin/kafka-consumer-perf-test.sh --topic topic-1 --messages 1000000 --broker-list localhost:9092 start.time ,
end.time , data.cosumed.in.MB , MB.sec , data.consumed.in.nMsg , nMsg.sec ,rebalance.time.ms, fetch.time.ms,
fetc.MB.sec , fetch.nMsg.sec
4）消费者参数说明
start.time 起始运行时间
end.time 结束运行时间
data.consumed.in.MB 消费的消息总量，单位为MB
nMsg.sec 按消息个数计算的吞吐量
rebalance.time 再平衡时间，单位为ms
fetch.time.ms 拉取消息的持续时间，单位为ms
fetch.MB.sec 每秒拉取消息的字节大小，单位为MB/s
fetch.nMsg.sec 每秒拉取消息的个数
(补充：fetch.time.ms=end.time-start.time-rebalance.time.ms)
1.2 分区数越多吞吐量就越高吗
1）背景：
分区是Kafka中最小的并行操作单元，对于生产者而言，每一个分区的数据写入是完全可以并行化的
2）测试原理
我们使用性能测试工具来实际测试一下。首先分别创建分区数为1、20、50、100、200、500、1000的主题，对应的主题名称分别为topic-1、topic-20、topic-50、topic-100、topic-200、topic-500、topic-1000，所有主题的副本因子都设置为1。
3）测试环境
本次案例中使用的测试环境为一个由3台普通云主机组成的3节点的Kafka集群，每台云主机的内存大小为8GB、磁盘大小为40GB、4核CPU的主频为2600MHz。JVM版本为1.8.0_112，Linux系统版本为2.6.32-504.23.4.el6.x86_64。使用kafka-producer-perf-test.sh脚本分别向这些主题中发送100万条消息体大小为1KB的消息
4）测试脚本命令
5）测试结果
生产者数据
消费者数据
6）总结：
也就是说并不是分区越多越好，会受到磁盘、文件系统、I/O调度策略相关
1.3 分区数的上限(跟文件描述相关)
- 查看系统的默认文件描述符数量
ulimit -n
ulimit -Sn 软链接数量
ulimit -Hn 硬链接数量 （硬链接是指设置后不能修改的文件描述符数量）
- 查看当前Kafka进程所占用的文件描述符的个数(单个主题，多增一个分区就多一个文件描述符的消耗)
[root@node1 kafka_2.11-2.0.0]# jps -l
31796 kafka.Kafka
[root@node1 kafka_2.11-2.0.0]# ls /proc/31796/fd | wc -l
194
- 提高文件描述符的上限
法一：针对当前用户
ulimit -n 65535
法二：
在/etc/security/limits.conf文件中设置，需要重启后才生效，针对所有用户，在shell这层只上的
#nofile -max number of open file descriptors
root soft nofile 65535
root hard nofile 65535
1.4 考量因素
- 因素
1）硬件资源影响
2）消息大小
3）消息压缩方式
4）消息发送是同步还是异步
4）消息确认类型(acks)
5）副本因子
6）应用逻辑处理速度
7）分区数量
- 怎么选分区数的简单评测方法：
1）那个分区数高就选哪个
2）若要求分区有序性到底消费者，就设置分区数为1
3）考虑到文件描述符的数量限制
4）基础选择可以为broker节点的倍数，例如3个broker，可以设置分区数为3、6、9等