19 | 数据压缩：时间换空间的游戏

RocketMq(rockmq-all 4.4.1-SNAPSHOT): 默认压缩大于4K的消息（可配置），压缩算法是zip，默认级别5（可配置），同样也是客户端做解压缩工作，服务端只存储；对于批量消息的压缩，目前并不支持。 摘取DefaultMQProducerImpl.java 部分源码： private boolean tryToCompressMessage(final Message msg) { if (msg instanceof MessageBatch) { //batch dose not support compressing right now return false; } byte[] body = msg.getBody(); if (body != null) { if (body.length >= this.defaultMQProducer.getCompressMsgBodyOverHowmuch()) { try { byte[] data = UtilAll.compress(body, zipCompressLevel); if (data != null) { msg.setBody(data); return true; } } catch (IOException e) { log.error("tryToCompressMessage exception", e); log.warn(msg.toString()); } } } return false; }

Kafka每个压缩过的消息集合在 Broker 端写入时都要发生解压缩操作，目的是为了对消息执行各种验证。 好像是这样吧？

一直学习算法都是空间换时间，但是在消息中间件和一些IO密集型的应用中还会有CPU计算资源换网络带宽/磁盘IO，刚刚看了下RocketMQ源码，在DefaultMQPullConsumerlmpl.pullSyncImpl中会调用PullAPIWrapper.processPullResult，在这里会为压缩的消息进行解压缩。Producer端没找到压缩的源码，只是在checkMessage中会对消息体的长度进行限制，超过4K(网上查的)会抛出来MQClientException，猜测应该也是会压缩。也就是RocketMQ的压缩机制也是Producer压缩，Broker传输，Consumer解压缩，不同的是kaffka的压缩是基于一批一批消息的，对于CPU空闲较多的场景下会有更大的吞吐提升。

kafka压缩后它的offset如何计算，假如刚好要回溯的数据就在压缩包中offset如何计算

RocketMQ 在DefaultMQProducerImpl.tryToCompressMessage中判断消息长度大于4Kb就进行压缩，压缩算法是zip（java.util.zip.Deflater） 我注意到在发送时，会判断如果消息是一个批量消息（MessageBatch），就不开启压缩。这是为什么呢？

现在系统使用的是rabbitmq，在发送数据时候使用的是protobuffer进行序列化，这时候还有必要开启压缩吗？如果开启了压缩会不会效果更好的？

如果是批消息，服务端不解压，直接返回给消费者端解压---如果批消息很大，一个批次几百上千呢？也是一次性返回给消费者端吗？这样岂不是影响并发消费，从而影响消费速度？

老师提到了压缩：适当扩展一下，这个东西早期数据库备份其实经常会要去使用；个人的感受不是耗资源-是极度耗费资源，压缩比越大CPU越大，服务器做数据库备份压缩时基本上什么事情都做不了，尤其像oracle、sybase这种；sybase的备份策略更人性但是代价的权衡其实当时就、、、、、、 大多数情况下其实我们在做这种事情时不太可能单独什么事情都不做：可能生产环境还是会去选择Rockmq吧，毕竟中间件不像数据库-单独的服务器，cpu的资源使用上相对宽裕，尤其是对于中小型企业，硬件资源没有那么宽裕，Rockmq是个不错的选择，计算机组成原理的课程还是对于数据备份做了一些比较好的讲解，胡老师的课对kafka的压缩机制有讲解；综合下来我应当会选择Rockmq。 几门课程同时在跟-确实发现时间上蛮吃力，为了学习天天的业余生活活在闹钟之中：可能很多东西只能等完课了再进一步梳理；只能用刘超老师的学习法-第一遍先粗学了，第一遍还是希望明白是什么回事，什么场景怎么用；老师的消息队列课程与计算机组成原理、操作系统的关系更大些，同时跟这三门就已经挤压不出时间到kafka上了，完课的时候明白选什么，为什么选算是基本达到学习这门功课的基本目标吧，学习过程中为了明白原来而交叉去学习其它两门课所付出的时间代价其实远超与预期。 感谢老师的分享：期待老师下节课的分享。

关于 Kafka Broker 端对于压缩的处理，隔壁课程有不一样的讲解。如果 producer 端与 Broker 选择的压缩算法不一致，此时 Broker 只能先解压缩，然后再重新压缩。

确实想到了霍夫曼编码，还有位图。