kafka性能调优解密（三）-- Consumer端

Consumer篇

1  fetch.message.max.bytes

1.1 参数描述

1.2 原理分析

1. 个broker 创建10个分区的topic

2. 同时启动Producer与Consumer，一起测试

3. 测试Consumer scoket.receiver.buffer.bytes取值为256k 或者2M， 这两者在不同fetch.message.max.bytes的区别

10G网卡下，10分区，2k数据，发送1000000, ack都为1, N个Producer与N个Consumer一起跑, Consumer每次从队列开始读取数据，10个线程， bufferMemory为32M, Producer默认send buf为128k：

10分区，4k数据，发送1000000, ack都为1, N个Producer与N个Consumer一起跑, Consumer每次从队列开始读取数据，10个线程， bufferMemory为32M, Producer默认send buf为128k:

可以看出无论是2k或者4k数据，fetch.size在1M~8M之间，Consumer性能都是在峰值范围

结论：

1. 需要根据业务最大消息来配置，比如业务最大4M， 这个参数至少配置4M

2. 实测证明，在内存足够的情况下，也不是越大越好。从目前来看1M~8M性能都稳定在峰值附近

2 num.consumer.fetchers

2.1 参数描述

2.2 原理分析

 该参数是用于指定Consumer端用于fetcht数据的线程数(fetch threads)，如下图：

Consumer跟根据这个线程个数和Topic的分区数，均匀地分布在这些fetch threads上。增大这些线程能起到一定的提升性能，但是多于分区个数后，就会有线程空闲。

2.3 实测分析

结论：

1. 从性能上看，10个Consumer线程配10个Fetch 线程，性能最优

2. 10个Fetch线程后面就会有空闲的线程分配不到partition

3  offsets.storage

3.1 参数描述

3.2 原理分析

kafka会记录offset到zk中。但是，zk client api对zk的频繁写入是一个低效的操作。0.8.2 kafka引入了native offset storage，将offset管理从zk移出，并且可以做到水平扩展。其原理就是利用了kafka的compacted topic，offset以consumer group,topic与partion的组合作为key直接提交到compacted topic中。同时Kafka又在内存中维护了的三元组来维护最新的offset信息，consumer来取最新offset信息的时候直接内存里拿即可。当然，kafka允许你快速的checkpoint最新的offset信息到磁盘上。
3.3 实测分析

从上面的数据来看，存储在zookeeper与存储在kafka，性能峰值相差不

结论：

1.在broker节点数不是很多并且对zk节点写入不大的情况下，这个选项对性能影响不是很大，但以后社区会推用存储在kafka，为了避免以后修改，建议值为kafka

尾声

   性能相关的核心参数详解到处就结束了，希望对大家业务应用有帮助。对于应用PUMA或者kafka作为消息总线的用户，应该在实施过程关注过这样的问题：具体业务不同可靠模式下，对于特定硬件及网络，需要多少资源，才能达到业务需要的吞吐量。这个PUMA经过大量实践验证及理论分析，证明可以通过简单测试及公式计算就可以完成业务资源部署评估，相关进一步信息欢迎联系PUMA或持续关注后续的解密，谢谢~

【版权声明】本文为华为云社区原创内容，未经允许不得转载，如需转载请发送邮件至hwclouds.bbs@huawei.com；如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。