消息队列高手课
李玥
美团高级技术专家
52199 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
进阶篇 (21讲)
消息队列高手课
15
15
1.0x
00:00/00:00
登录|注册

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

比较Kafka和RocketMQ的压缩方式
RocketMQ的消息压缩处理方式
批消息压缩和服务端处理
配置开启压缩和选择压缩算法
找到压缩率、压缩速度和解压浪费的平衡
压缩分段大小的影响
数据划分和压缩算法
考虑压缩率和压缩耗时
常用压缩算法:ZIP, GZIP, SNAPPY, LZ4
有损压缩 vs. 无损压缩
资源置换:时间换空间,CPU资源换存储资源
影响因素:数据的压缩率、网络带宽、CPU资源
考虑使用数据压缩的场景
提升网络传输性能
节省存储空间
思考题
Kafka是如何处理消息压缩的
如何选择合适的压缩分段
应该选择什么压缩算法
什么情况适合使用数据压缩
数据压缩
如何使用数据压缩来提升系统性能

该思维导图由 AI 生成,仅供参考

你好,我是李玥。
这节课我们一起来聊一聊数据压缩。我在前面文章中提到过,我曾经在一台配置比较高的服务器上,对 Kafka 做过一个极限的性能压测,想验证一下 Kafka 到底有多快。我使用的种子消息大小为 1KB,只要是并发数量足够多,不开启压缩时,可以打满万兆网卡的全部带宽,TPS 接近 100 万。开启压缩时,TPS 可以达到 2000 万左右,吞吐量提升了大约 20 倍!
算术好的同学可能会立刻反驳我说,2000 万 TPS 乘以 1KB 的消息大小,再把字节 Byte 转换成比特 bit,换算成网络传输的带宽是 200Gb/s,服务器网卡根本达不到这么大的传输带宽!
我们的测试服务器的网卡就是普通的万兆网卡,极限带宽也就是 10Gb/s,压测时候的实际网络流量大概在 7Gb/s 左右。这里面,最重要的原因就是,我在测试的时候开启了 Kafka 的压缩功能。可以看到,对于 Kafka 来说,使用数据压缩,提升了大概几十倍的吞吐量。当然,在实际生产时,不太可能达到这么高的压缩率,但是合理地使用数据压缩,仍然可以做到提升数倍的吞吐量。
所以,数据压缩不仅能节省存储空间,还可以用于提升网络传输性能。这种使用压缩来提升系统性能的方法,不仅限于在消息队列中使用,我们日常开发的应用程序也可以使用。比如,我们的程序要传输大量的数据,或者要在磁盘、数据库中存储比较大的数据,这些情况下,都可以考虑使用数据压缩来提升性能,还能节省网络带宽和存储空间。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Kafka消息压缩处理方式及其对系统性能的影响是本文的核心内容。文章指出数据压缩是提升系统性能的重要方法之一,能节省存储空间、提升网络传输性能。选择是否使用数据压缩时需要考虑场景是否适合,以及压缩对CPU资源和磁盘IO性能的影响。常用的压缩算法有ZIP、GZIP、SNAPPY、LZ4等,选择合适的压缩算法和分段大小能在压缩率、压缩速度和解压浪费之间找到平衡。Kafka在生产者上对每批消息进行压缩,批消息在服务端不解压,消费者在收到消息后再进行解压,这种处理方式能节省网络带宽和服务端的存储空间,提升总体的吞吐量。读者需要综合考虑压缩时间、压缩率和业务情况选择合适的压缩算法和分段策略。最后,读者被鼓励思考RocketMQ的消息压缩处理方式,并与Kafka的方式进行对比,以找到更适合自己系统的处理方式。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《消息队列高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(20)

  • 最新
  • 精选
  • 姜戈
    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; }

    作者回复: 👍👍👍

    2019-09-05
    66
  • z.l
    Kafka每个压缩过的消息集合在 Broker 端写入时都要发生解压缩操作,目的是为了对消息执行各种验证。 好像是这样吧?

    作者回复: 只会解压header,消息体不会解压。

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

    作者回复: 👍👍👍

    2019-09-05
    12
  • 路途
    kafka压缩后它的offset如何计算,假如刚好要回溯的数据就在压缩包中offset如何计算

    作者回复: 正常情况下,客户端每次拉消息都是整批拉取,不会出现你说的情况。如果是指定消费位置来消费,客户端在拉取整批消息之后,再计算一下批内的偏移量,把正确的消息返回给用户代码。

    2019-09-05
    3
    7
  • 青舟
    RocketMQ 在DefaultMQProducerImpl.tryToCompressMessage中判断消息长度大于4Kb就进行压缩,压缩算法是zip(java.util.zip.Deflater) 我注意到在发送时,会判断如果消息是一个批量消息(MessageBatch),就不开启压缩。这是为什么呢?

    作者回复: 因为批消息还不支持压缩

    2019-09-05
    3
    5
  • 现在系统使用的是rabbitmq,在发送数据时候使用的是protobuffer进行序列化,这时候还有必要开启压缩吗?如果开启了压缩会不会效果更好的?

    作者回复: 这个不能一概而论啊,你需要根据我这节课的讲的那些原则自己衡量一下。一般来说,如果消息体比较大,客户端的CPU不是很忙,开启压缩后都会有一定的性能提升。

    2019-09-05
    2
  • 北冥Master
    如果是批消息,服务端不解压,直接返回给消费者端解压---如果批消息很大,一个批次几百上千呢?也是一次性返回给消费者端吗?这样岂不是影响并发消费,从而影响消费速度?

    作者回复: 在发送端,批的大小是有参数控制的,不会过大。

    2019-09-08
    1
  • leslie
    老师提到了压缩:适当扩展一下,这个东西早期数据库备份其实经常会要去使用;个人的感受不是耗资源-是极度耗费资源,压缩比越大CPU越大,服务器做数据库备份压缩时基本上什么事情都做不了,尤其像oracle、sybase这种;sybase的备份策略更人性但是代价的权衡其实当时就、、、、、、 大多数情况下其实我们在做这种事情时不太可能单独什么事情都不做:可能生产环境还是会去选择Rockmq吧,毕竟中间件不像数据库-单独的服务器,cpu的资源使用上相对宽裕,尤其是对于中小型企业,硬件资源没有那么宽裕,Rockmq是个不错的选择,计算机组成原理的课程还是对于数据备份做了一些比较好的讲解,胡老师的课对kafka的压缩机制有讲解;综合下来我应当会选择Rockmq。 几门课程同时在跟-确实发现时间上蛮吃力,为了学习天天的业余生活活在闹钟之中:可能很多东西只能等完课了再进一步梳理;只能用刘超老师的学习法-第一遍先粗学了,第一遍还是希望明白是什么回事,什么场景怎么用;老师的消息队列课程与计算机组成原理、操作系统的关系更大些,同时跟这三门就已经挤压不出时间到kafka上了,完课的时候明白选什么,为什么选算是基本达到学习这门功课的基本目标吧,学习过程中为了明白原来而交叉去学习其它两门课所付出的时间代价其实远超与预期。 感谢老师的分享:期待老师下节课的分享。
    2019-09-05
    1
    37
  • Ryoma
    关于 Kafka Broker 端对于压缩的处理,隔壁课程有不一样的讲解。如果 producer 端与 Broker 选择的压缩算法不一致,此时 Broker 只能先解压缩,然后再重新压缩。
    2020-03-14
    2
    5
  • 张三
    确实想到了霍夫曼编码,还有位图。
    2019-09-06
    3
收起评论
显示
设置
留言
20
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部