关于消费端group大量提交offset写入__consumer_offsets导致broker cpu负载不均匀问题的处理

写在前面

       与数据盘和内存相比，其实Kafka对计算处理能力的要求是相对较低的，不过它在一定程度上还是会影响整体的性能。

       随着整体业务数据量的提高(consumer端消费消息数量大致在500万-600万条/s)，我们观察到各broker的cpu使用率也在不断提升，这种情况下一般会考虑去优化线上业务关于消息的生产、消费机制或是横向扩充集群broker节点数量。

       但是在日常维护工作中，我们发现到由于研发人员经常会因为下面一些问题增大kafka集群cpu不必要的浪费和开销。

1.生产端为了优化网络和磁盘空间，会对消息进行压缩。

      服务器需要对消息进行批量解压，设置偏移量，然后重新进行批量压缩，再保存到磁盘上。虽然压缩传输会提高集群整体吞吐量，但是随之而来的是cpu开销的大大提高，所以在集群接入数据量较大或是消费量很高的情况下，生产端不建议对消息开启压缩传输。

2.消费端同一groupID同时消费多个topic

__consumer_offsets是以groupID为单位，负责记录同一消费组内各consumer针对所消费topic所提交的offsets信息，这种大批量的频繁I/O操作其实对cpu的损耗也是非常高的，如果客户端使用同一groupID同时去消费众多业务topic，由于该groupID的offsets信息是随机分配到__consumer_offsets的某一个分区上，所以就会造成该分区所在broker节点cpu高于其他节点的现象。

关于__consumer_offsets的相关描述

      0.10版本之后的Kafka已将所有消费组各consumer提交的位移offset信息保存在kafka内部的topic中，即__consumer_offsets ，且这个topic是由kafka自动创建的，默认50个。__consumer_offsets中的消息保存了每个consumer group某一时刻提交的offset信息。格式大概如下:

 

关于LogSegment 

       在分区日志文件中，会有很多类型的文件，比如：.index、.timestamp、.log、.snapshot等，其中，文件名一致的文件集合就称为 LogSement，partition被分为多个segment文件进行存储。分区有利于topic的水平扩展与读写的负载均衡，而segment则有利于消息的快速定位和日志数据的清理。

        在命名规则上第一个segment文件名都是0，后续segment文件名是上一个segment文件最后一条消息的offset值，由于偏移量是一个 64 位的长整形数，固定是20位数字，如果长度未达到，用 0 进行填补，索引文件和日志文件都由该作为文件名命名规则。

.log文件: segment 日志文件

.index文件: segment offset索引文件，记录的是某条消息的offset和对应的物理位置

[root@form-kafka-01 __consumer_offsets-36]# ${KAFKA_HOME}/bin/kafka-dump-log.sh --files ./00000000042330624877.index |head -n 10
Dumping ./00000000042330624877.index
offset: 42330624918 position: 4167
offset: 42330624956 position: 8517
offset: 42330624989 position: 12621
offset: 42330625023 position: 16817
offset: 42330625057 position: 21043
offset: 42330625094 position: 25514
offset: 42330625125 position: 29648
offset: 42330625161 position: 33782
offset: 42330625192 position: 37947

.snapshot文件:segment 快照文件

.timeindex文件:segment timestamp索引文件

leader-epoch-checkpoint:用于副本备份机制，保存了每一任leader开始写入消息时的offset 会定时更新，follower被选为leader时会根据这个确定哪些消息可用

 

关于log.retention.bytes和log.segment.bytes参数
log.segment.bytes:控制每一个segment集合中.log日志文件的大小，超出该大小则针对其进行轮转，新数据将追加到新的日志segment文件中（-1表示没有限制） 

log.retention.bytes:日志数据存储的最大字节数。超过这个时间会根据log.cleanup.policy(delete|compact)设定的日志清理策略来处理数据。

[root@form-kafka-01 config]# egrep  "(log.retention.bytes|log.segment.bytes)" server.properties  |grep -v "#"
log.retention.bytes=1073741824
log.segment.bytes=1073741824

问题描述

      日常工作中，发现集群某一个broker的cpu平均使用率高于其他节点大约20个百分点，具体如下

问题节点cpu使用情况:

部分其他节点cpu使用状况:

问题发现

__consumer_offsets第19个分区相应segment分段日志文件的大小增长非常快,通过查看数据清理相关log也可以发现分段日志文件达到log.retention.bytes所设置的阈值大小100m的间隔也是非常短的，详细如下

所以猜测可能是提交offsets至该__consumer_offsets分区的某些group短时间提交太过频发所致

问题解决

既然consumer group将offsets提交记录数据写入到__consumer_offset该topic中，所以我们可以通过bin/kafka-console-consumer.sh来做统计分析。

[root@formal-midw-05 kafka]# source /etc/profile && ${KAFKA_HOME}/bin/kafka-console-consumer.sh \
--topic __consumer_offsets --partition 19  --bootstrap-server  192.168.1.1:9092  \ 
--formatter "kafka.coordinator.group.GroupMetadataManager\$OffsetsMessageFormatter" \
 >> /tmp/19.txt

发现该group_bigdata_consumer190912在大约20s内提交offset达到200多万次，相较于其他group，可以发现其提交次数太过频繁。

[root@form-kafka-03 tmp]# awk -F"," '{print $1}' /tmp/19.txt|sed 's/\[//' | sort | uniq -c |sort  -nk1
567 group_report_consumer200201
2335501 group_bigdata_consumer190912

进一步查取该消费组消费情况，发现如文章开头所说的情况，该groupID同时消费了10几个topic，造成针对偏移量的commit频率过高，所以需要通知研发人员进行整改，不同业务topic定义不同groupID去消费，我们这边暂时将__consumer_offsets-19分区手动迁移至其他cpu使用率较低的集群节点。