一次kafka空间激增排查:kafka的数据压缩、批量发送等

问题过程

我司需要接收很多外部数据,数据源的形式很多,ibmmq, activemq, redis pubsub, 等等都有。为了将这些数据接到内部amq/kafka,之前运行了一大批进程,管理起来十分复杂,因此最近用apache-camel对这些进程作了整合。

上线几个小时之后,kafka磁盘空间开始报警。初步断定是这次上线导致的。

排查流程

主要还是对kafka不熟悉,只是能用而已,因此排查过程走了不少弯路。

由于camel本身文档很不完善,一开始配置参数时也主要靠看源码+猜,所以首先怀疑配置的压缩参数compressionCodec=gzip是否无效。

因此进行了一次简单的测试(别问我为什么一开始不测)。建了一个单分区的测试topic, 然后分别使用gzip和none模式发送相同的数据,观察kafka的log file文件大小变化趋势。发现压缩确实是有效的。

因此又跟直接使用kafka api作了对比,发现差别非常大,即使是压缩之后,使用camel-kafka占用的空间也比使用api大数倍。然后去查了两边源码,发现最底层的代码是完全一致的,所以还是怀疑某些参数配的不对。

之后又注意到一个细节,使用camel时,log的大小跟消息数呈线性关系,比如一条占1字节,10条就占10字节。但使用api的话,1条也占1字节,连续发10条可能才占两字节。

这时候就怀疑kafka是不是有批量发送之类的机制,然后咨询了负责kafka的同事,果然是这个原因,而造成占用空间差别大的原因就是是否同步发的区别,同步发的话就不存在批量发送了。批量发送的话,这一批消息会被压缩在一起,而单条发时,就是每一条分别压缩。我们知道,在文件非常小的时候,使用gzip压缩的效果是很差的,甚至可能压完比源文件还大。然后又做了些测试,确定了是这个问题。这个参数被同事封装在了kafka的client接口里,因此导致我照着之前代码改参数时漏掉了这一个。

一些感悟

其实回想起来,这个问题挺low的,如果对kafka多些了解,是不会有这种问题的。

首先,对kafka没做过全面的了解,只是学会了怎么用,大概了解了一下它是什么。而很多基本的机制都没有概念。使用一个开源工具时,对它做一次全面的了解还是很重要的,虽然每个工具都深入研究底层代码不现实,但是系统性的了解一遍这些工具有什么机制,确实花不了多少时间。

再一个,公司内一般会封装一些访问各种组件的工具包,以提升效率,这些工具包最好也了解一下怎么实现的,否则可能不经意间就掉坑里了。

任重而道远啊..

 wechat
订阅公众号