开发者社区> 稀奇古怪> 正文

Kafka集群磁盘使用率瞬超85%,幕后元凶竟是它?

简介:
+关注继续查看

Kafka是一种快速、可扩展的,设计内在就是分布式的、分区的和可复制的提交日志服务。作为一种高吞吐量的分布式发布订阅消息系统,Kafka被广泛的应用于海量日志的收集、存储。网上有大量Kafka架构、原理介绍的文章,本文不再重复赘述,重点谈谈Consumer Offset默认保存机制。

 

Topic作为一类消息的逻辑集合,Kafka集群为其维护了一个分区的日志,其结构如图:

 

20170428101059865.jpg

 

Topic每个分区是一个有序的、信息不断追加的序列。分区中的每个消息都分配了一个连续的ID号,称为偏移量(offset),用于唯一标识每个消息在分区中的位置。消费者根据自身保存的offset值确定各分区消费的位置。在0.8版本之前,Kafka一直将consumer的 offset信息记录在ZooKeeper中。

 

20170428101107207.jpg

Kafka的ZooKeeper存储架构图

 

如图,在offsets的子节点中保存了不同的topic的offset 信息。Consumer在消费topic中的信息时需要不断的更新ZooKeeper中的offset信息。

 

众所周知,由于ZooKeeper并不适合大批量的频繁写入操作,从0.8.2版本开始Kafka开始支持将consumer的位移信息保存在Kafka内部的topic中(从0.9.0版本开始默认将offset存储到系统topic中),虽然此举解决了ZooKeeper频繁写入的性能瓶颈,但却引入了新的问题。

 

以下是一个真实的案例:

 

磁盘使用率异常

 

某日Kafka集群的pc-xxx01主机的文件系统使用率超过80%,触发告警。通过分析发现,topic __consumer_offset 相关log占用大量的磁盘空间。

 

20170428101120548.jpg

图1

 

20170428101129265.jpg

图2

 

如图1、2所示,pc-xxx01主机data3目录的磁盘使用率超过85%,其中__consumer_offset对应的24号分区的日志占用了952G,占总使用量的41%。

 

__consumer_offset的作用

 

20170428101137954.jpg

图3

 

如图3所示,通过消费__consumer_offsets 分区24的数据可以发现,该topic保存的消息格式为[consumer group,topic name,partition]::[offsetmetadata[offset value,nometadata],committime value,expiratintime value],即一条消息包含消费组、topic、分区、offset值、提交时间、过期时间等信息。此topic正是kafka用来保存consumer offset的系统topic(根据实验验证该topic的消息以consumer group为key进行hash,相同consumer group的offset信息会被插入同一个partition)。

 

__consumer_offsets数据产生的频率

 

Consumer消费消息之后会向offset manager 发送offsetCommitrequest请求,offset manager 负责将对应的consumer group、topic、partition、offset等信息插入__consumer_offsets topic。系统默认每60s为consumer提交一次offsetcommit请求(由auto.commit.interval.ms, auto.commit.enable两个参数决定)。应用可以采用同步commit的方式进行数据消费(即consumer每处理一条消息触发一次commit操作),这可能导致频繁发送offsetCommitrequest请求的现象发生。

 

__consumer_offsets 数据保留策略

 

20170428101147423.jpg

图4

 

如图4所示,当前__consumer_offsets 24号分区保留了16年10月到现在的所有消息日志,总量达到952G。

 

20170428101157489.jpg

 

20170428101204444.jpg

 

20170428101210217.jpg

 

当前__consumer_offsets 的清理策略为compact,日志保留周期为24小时,但是系统默认的log.cleaner.enable为false,导致kafka不会对超过保留周期的数据进行压缩处理,topic保留了系统上线以来的所有历史数据。

 

不合理的同步提交方式

 

通过前期分析发现,__consumer_offsets 数据量暴增的24分区的数据主要来自于对log_xxx_plat_xx这个topic的消费组。通过获取应用相关代码分析发现,该topic相关consumer 采用了同步commit方式进行数据消费。

 

20170428101217586.jpg

 

20170428101226942.jpg

 

以上是官方文档给出了consumer同步commit消费信息的两种示例代码。第一种方式,只要消费一条消息,就会产生一条commit记录,数据量庞大;第二种方式,对同步commit做了精细化处理,每次批量数据消费,只会对被消费topic各分区中最后一条消息进行commit。如果一个topic包含10个分区,每次消费单个分区需要处理10条消息,采用第一种方式将产生100条commit记录,而第二中方式只会产生10条commit记录,差距巨大。经开发确认,相关应用正是采用了第一种方式进行同步commit。

 

系统topic分区大小异常的原因

 

通过以上分析,当前__connsumer_offsets部分分区数据量异常的问题是由于以下两方面原因共同造成:

 

  1. __connsumer_offsets默认清理策略设置不当,导致过期历史数据无法正常清理。

  2. 部分应用消费方式不当,导致产生大量commit信息。

 

针对该问题,我们后续优化策略如下,取得了不错的成效。

 

  1. 要求应用优化代码,减少commit信息的产生,应用进行代码改造之后commit信息日增加量由原先的37G减少到1.5G。

  2. 调整topic 清理策略,将系统log.cleaner.enable设置为true,重起broker节点触发日志清理。

 

优化之后__consumer_offsets 数据量由原先的900G下降到2G。

原文发布时间为:2017-04-28

本文来自云栖社区合作伙伴DBAplus

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
使用 Kafka + Spark Streaming + Cassandra 构建数据实时处理引擎
Apache Kafka 是一个可扩展,高性能,低延迟的平台,允许我们像消息系统一样读取和写入数据。我们可以很容易地在 Java 中使用 Kafka。 Spark Streaming 是 Apache Spark 的一部分,是一个可扩展、高吞吐、容错的实时流处理引擎。
2970 0
使用EMR-Kafka Connect进行数据迁移
流式处理中经常会遇到Kafka与其他系统进行数据同步或者Kafka集群间数据迁移的情景。使用EMR Kafka Connect可以方便快速的实现数据同步或者数据迁移。本文介绍使用EMR Kafka Connect的REST API接口在Kafka集群间进行数据迁移。
13491 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 29 章 监控磁盘使用
第 29 章 监控磁盘使用 目录 29.1. 判断磁盘用量 29.2. 磁盘满失败 本章讨论如何监控PostgreSQL数据库系统的磁盘使用情况。 本文转自PostgreSQL中文社区,原文链接:第 29 章 监控磁盘使用
741 0
Kafka——使用java api进行pub & sub
       之前用过老的api,但是最近在写消费的时候,发现之前老的api很多方法都out了,又去官网看了下最新的0.10.x的api. 1,producer org.apache.
930 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 29 章 监控磁盘使用_29.1. 判断磁盘用量
29.1. 判断磁盘用量 每个表都有一个主要的堆磁盘文件,大多数数据都存储在其中。如果一个表有着可能会很宽(尺寸大)的列, 则另外还有一个TOAST文件与这个表相关联, 它用于存储因为太宽而不能存储在主表里面的值(参阅第 66.2 节)。
899 0
使用JMX监控Kafka
JMX监控Kafka
10585 0
+关注
119
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载