关于消费端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使用率较低的集群节点。

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

kafka comsumer消费消息后不commit offset的情况分析
kakfa用offset来记录某消费者消费到的位置,由于kafka是个分布式结构,数据被存放在多个partition上,那么要为每个partition单独记录一个offset,该offset保存在一个 ...
Kafka：Consumer手动提交offset
在上一篇博客中介绍了使用Consumer订阅多个Topic或者多个Partition: Kafka:Consumer订阅在上一篇博客的测试样例中,Consumer都是自动提交offset,这是通过下 ...
python kafka offset自动提交_Spring-Kafka —— 实现批量消费和手动提交offset
spring-kafka的官方文档介绍,可以知道自1.1版本之后, @KafkaListener开始支持批量消费,只需要设置batchListener参数为true 把application.yml中 ...
【Kafka】Flink 消费 kafka 部分分区一直不提交 offset
文章目录 1.概述 1.1 查看消费组 1.2 检测topic 1.3 内置topic 1.4 flink数据监控 1.5 提交offset指标 M.扩展 1.概述一个环境,突然发现,Flink消费 ...
RocketMQ：消费端的消息消息队列负载均衡与重新发布机制源码解析
文章目录前言流程解析总结前言在上一篇博客中我们了解到,PullMessageService线程主要是负责从pullRequestQueue中获得拉取消息请求并进行请求处理的. PullMes ...
如何保存消费端的消费位置
什么是offset 前面在讲解partition的时候,提到过offset, 每个topic可以划分多个分区(每个Topic至少有一个分区),同一topic下的不同分区包含的消息是不同的.每个消息在被 ...
springboot配置手动提交_kafka教程-springboot消费者-手动提交offset
介绍自动提交 offset 十分简介便利,但由于其是基于时间提交的,开发人员难以把握offset 提交的时机. 因此 Kafka 还提供了手动提交 offset 的 API. 手动提交 offse ...
解决Kafka消费端错误：o.s.kafka.listener.LoggingErrorHandler : Error while processing: null
简单记录下使用kafka遇到的问题,万一也会有小伙伴遇到了呢. 程序端使用springboot服务消费kafka,某天出现消息大量堆积,经过定位到错误日志如下: 2020-05-12 10:22:36 ...
kafka自动提交offset失败：Auto offset commit failed
今天在服务日志中观察数据的消费情况时,发现了一个如下的警告,而且每隔几秒就会出现一次,虽然只是个警告, Auto offset commit failed for group order_group: ...
mq补偿机制java代码_RocketMQ源码分析之消息消费机制-消费端消息负载均衡机制与重新分布 - Java 技术驿站-Java 技术驿站...
1.消息消费需要解决的问题首先再次重复啰嗦一下RocketMQ消息消费的一些基本元素的关系主题 ---> 消息队列(MessageQueue) 1 对多主题 ----> 消息生产者, ...

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

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

最新文章

热门文章