问题过程

我司需要接收很多外部数据，数据源的形式很多，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没做过全面的了解，只是学会了怎么用，大概了解了一下它是什么。而很多基本的机制都没有概念。使用一个开源工具时，对它做一次全面的了解还是很重要的，虽然每个工具都深入研究底层代码不现实，但是系统性的了解一遍这些工具有什么机制，确实花不了多少时间。

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

任重而道远啊..