- 补充：关于参数解读，请看这个链接
- 一、如何选择合适的分区数
- 1.1 性能测试工具（这里用kafka脚本去测试）
- 1）生产者举例：向一个只有一个分区和一个副本的主题topic-1中发送100W条信息，并且每条信息大小为1MB，生产者对应的acks参数为1
- 2）生产者脚本参数说明
- 3）消费者脚本
- 4）消费者参数说明
- 1.2 分区数越多吞吐量就越高吗
- 1）背景：
- 2）测试原理
- 3）测试环境
- 4）测试脚本命令
- 5）测试结果
- 6）总结：
- 1.3 分区数的上限(跟文件描述相关)
- 1.4 考量因素
- 二、
- 三、
传送门
一、如何选择合适的分区数1.1 性能测试工具（这里用kafka脚本去测试）怎么选择合适的分区数，下面用四个小主题来说明：
1）生产者举例：向一个只有一个分区和一个副本的主题topic-1中发送100W条信息，并且每条信息大小为1MB，生产者对应的acks参数为1这里用kafka的kafka-producer-perf-test.sh和kafka-consumer-perl-test.sh
bin/kafka-producer-perf-test.sh --topic topic-1 --num-records 1000000 --record-size 1024 --producer-props bootstrap.servers=localhost:9092 acks=12）生产者脚本参数说明
--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.sec4）消费者参数说明
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）背景：
2）测试原理分区是Kafka中最小的并行操作单元，对于生产者而言，每一个分区的数据写入是完全可以并行化的
3）测试环境我们使用性能测试工具来实际测试一下。首先分别创建分区数为1、20、50、100、200、500、1000的主题，对应的主题名称分别为topic-1、topic-20、topic-50、topic-100、topic-200、topic-500、topic-1000，所有主题的副本因子都设置为1。
4）测试脚本命令本次案例中使用的测试环境为一个由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的消息
5）测试结果
生产者数据
6）总结：消费者数据
1.3 分区数的上限(跟文件描述相关)也就是说并不是分区越多越好，会受到磁盘、文件系统、I/O调度策略相关
- 查看系统的默认文件描述符数量
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 655351.4 考量因素
- 因素
1）硬件资源影响 2）消息大小 3）消息压缩方式 4）消息发送是同步还是异步 4）消息确认类型(acks) 5）副本因子 6）应用逻辑处理速度 7）分区数量
- 怎么选分区数的简单评测方法：
1）那个分区数高就选哪个 2）若要求分区有序性到底消费者，就设置分区数为1 3）考虑到文件描述符的数量限制 4）基础选择可以为broker节点的倍数，例如3个broker，可以设置分区数为3、6、9等二、 三、
