Kafka核心技术与实战
胡夕
人人贷计算平台部总监,Apache Kafka Contributor
立即订阅
8408 人已学习
课程目录
已完结 46 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么要学习Kafka?
免费
Kafka入门 (5讲)
01 | 消息引擎系统ABC
02 | 一篇文章带你快速搞定Kafka术语
03 | Kafka只是消息引擎系统吗?
04 | 我应该选择哪种Kafka?
05 | 聊聊Kafka的版本号
Kafka的基本使用 (3讲)
06 | Kafka线上集群部署方案怎么做?
07 | 最最最重要的集群参数配置(上)
08 | 最最最重要的集群参数配置(下)
客户端实践及原理剖析 (14讲)
09 | 生产者消息分区机制原理剖析
10 | 生产者压缩算法面面观
11 | 无消息丢失配置怎么实现?
12 | 客户端都有哪些不常见但是很高级的功能?
13 | Java生产者是如何管理TCP连接的?
14 | 幂等生产者和事务生产者是一回事吗?
15 | 消费者组到底是什么?
16 | 揭开神秘的“位移主题”面纱
17 | 消费者组重平衡能避免吗?
18 | Kafka中位移提交那些事儿
19 | CommitFailedException异常怎么处理?
20 | 多线程开发消费者实例
21 | Java 消费者是如何管理TCP连接的?
22 | 消费者组消费进度监控都怎么实现?
深入Kafka内核 (5讲)
23 | Kafka副本机制详解
24 | 请求是怎么被处理的?
25 | 消费者组重平衡全流程解析
26 | 你一定不能错过的Kafka控制器
27 | 关于高水位和Leader Epoch的讨论
管理与监控 (12讲)
28 | 主题管理知多少?
29 | Kafka动态配置了解下?
30 | 怎么重设消费者组位移?
31 | 常见工具脚本大汇总
32 | KafkaAdminClient:Kafka的运维利器
33 | Kafka认证机制用哪家?
34 | 云环境下的授权该怎么做?
35 | 跨集群备份解决方案MirrorMaker
36 | 你应该怎么监控Kafka?
37 | 主流的Kafka监控框架
38 | 调优Kafka,你做到了吗?
39 | 从0搭建基于Kafka的企业级实时日志流处理平台
高级Kafka应用之流处理 (3讲)
40 | Kafka Streams与其他流处理平台的差异在哪里?
41 | Kafka Streams DSL开发实例
42 | Kafka Streams在金融领域的应用
结束语 (1讲)
结束语 | 以梦为马,莫负韶华!
特别放送 (2讲)
加餐 | 搭建开发环境、阅读源码方法、经典学习资料大揭秘
用户故事 | 黄云:行百里者半九十
Kafka核心技术与实战
登录|注册

10 | 生产者压缩算法面面观

胡夕 2019-06-25
你好,我是胡夕。今天我要和你分享的内容是:生产者压缩算法面面观。
说起压缩(compression),我相信你一定不会感到陌生。它秉承了用时间去换空间的经典 trade-off 思想,具体来说就是用 CPU 时间去换磁盘空间或网络 I/O 传输量,希望以较小的 CPU 开销带来更少的磁盘占用或更少的网络 I/O 传输。在 Kafka 中,压缩也是用来做这件事的。今天我就来跟你分享一下 Kafka 中压缩的那些事儿。

怎么压缩?

Kafka 是如何压缩消息的呢?要弄清楚这个问题,就要从 Kafka 的消息格式说起了。目前 Kafka 共有两大类消息格式,社区分别称之为 V1 版本和 V2 版本。V2 版本是 Kafka 0.11.0.0 中正式引入的。
不论是哪个版本,Kafka 的消息层次都分为两层:消息集合(message set)以及消息(message)。一个消息集合中包含若干条日志项(record item),而日志项才是真正封装消息的地方。Kafka 底层的消息日志由一系列消息集合日志项组成。Kafka 通常不会直接操作具体的一条条消息,它总是在消息集合这个层面上进行写入操作。
那么社区引入 V2 版本的目的是什么呢?V2 版本主要是针对 V1 版本的一些弊端做了修正,和我们今天讨论的主题相关的修正有哪些呢?先介绍一个,就是把消息的公共部分抽取出来放到外层消息集合里面,这样就不用每条消息都保存这些信息了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Kafka核心技术与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(54)

  • huxi_2b 置顶
    刚刚看到4天前京东提的那个jira已经修复了,看来规避了broker端为执行校验而做的解压缩操作,代码也merge进了2.4版本。有兴趣的同学可以看一下:https://issues.apache.org/jira/browse/KAFKA-8106
    2019-06-26
    1
    22
  • 趙衍
    不行吧,校验操作应该也是为了防止在网络传输的过程中出现数据丢失的情况,在Producer端做完校验之后如果在传输的时候出现了错误,那这个校验就没有意义了。
    我有一个问题想请教老师,如果每次传到Broker的消息都要做一次校验,那是不是都要把消息从内核态拷贝到用户态做校验?如果是这样的话那零拷贝机制不是就没有用武之地了?
    2019-06-25
    6
    27
  • 常超
    文中对于消息结构的描述,确实引起了一些混乱,下面试图整理一下,希望对大家有帮助。
    消息(v1叫message,v2叫record)是分批次(batch)读写的,batch是kafka读写(网络传输和文件读写)的基本单位,不同版本,对相同(或者叫相似)的概念,叫法不一样。
    v1(kafka 0.11.0之前):message set, message
    v2(kafka 0.11.0以后):record batch,record
    其中record batch对英语message set,record对应于message。
    一个record batch(message set)可以包含多个record(message)。

    对于每个版本的消息结构的细节,可以参考kafka官方文档的5.3 Message Format 章,里面对消息结构列得非常清楚。
    2019-06-28
    18
  • dream
    老师,对于消息层次、消息集合、消息这三者的概念与关系我有点懵,能不能详细说一下?谢谢!
    2019-06-25
    2
    10
  • Hello world
    做一个笔记
    怎么压缩:
    1、新版本改进将每个消息公共部分取出放在外层消息集合,例如消息的 CRC 值
    2、新老版本的保存压缩消息的方法变化,新版本是对整个消息集合进行压缩
    何时压缩:
    1、正常情况下都是producer压缩,节省带宽,磁盘存储
    2、例外情况 a、broker端和producer端使用的压缩方法不同 b、broker与client交互,消息版本不同
    何时解压缩:
    1、consumer端解压缩
    2、broker端解压缩,用来对消息执行验证

    优化:选择适合自己的压缩算法,是更看重吞吐量还是压缩率。其次尽量server和client保持一致,这样不会损失kafka的zero copy优势
    2019-06-25
    7
  • 南辕北辙
    老师有一点有点迷惑,broker为了多版本消息兼容,意思是一份消息有多个版本存在吗,是这个意思吗?

    作者回复: 同一台broker上可能存在多个版本的消息,但每条消息只会以1个版本的形式保存。

    2019-07-01
    4
  • 风中花
    胡老师您好! 我们已经学历10多节课了! 针对我们得留言和反馈,不知道您有没有给我们一些后续得课程得学习建议和方法?我目前得学习就是您告诉我们得,我必须学会记住。但是看同学们得评论和反馈,我觉得貌似还有很多很多知识啊且不知也不懂,故有此一问!希望老师能给与一点一点学习建议? 感谢老师

    作者回复: 个人觉得学一个东西最重要的还是要用,如果只是参加一些培训课程很难全面的理解。您这么多的留言我一直坚持回复。我也一直是这个观点:用起来,自然问题就来了。

    我学机器学习的经历和您现在学Kafka很像。没有实际使用场景怎么学都觉得深入不了。

    我给您的建议是:把Kafka官网通读几遍然后再实现一个实时日志收集系统(比如把服务器日志实时放入Kafka)。事实上,能把官网全面理解的话已经比很多Kafka使用者要强了。

    2019-06-26
    1
    4
  • Geek_8441fd
    broker端校验可以分两步走。
    第1步,message set 层面,增加一个 crc,这样可以不用解压缩,直接校验压缩后的数据。
    如果校验不成功,说明message set 中有损坏的message;
    这时,再做解压操作,挨个校验message,找出损坏的那一个。

    这样的话,绝大部分情况下,是不用做解压操作的;只有在确实发生错误时,才需要解压。
    请指正。

    作者回复: 嗯嗯,挺好的。我自己也学到了一些。另外校验不仅仅是CRC校验,还有消息级别的检查。

    2019-06-25
    1
    4
  • 我看了三遍老师的课,得到了我要的答案:
    1.如果生产者使用了压缩,broker为了crc校验,会启动解压,这个解压过程不可避免;
    2.v2的broker为了低版本的消费者,会把消息再次解压并进行协议转换。
    所以消费者的兼容成本较大,需要避免这个情况。
    2019-06-25
    1
    4
  • cricket1981
    校验的目的是防止因为网络传输出现问题导致broker端接收了受损的消息,所以应该放在作为serverr broker端进行,而不是在作为client端的producer。改进的方案可以是针对一次传输的整个message set进行CRC检验,而不是针对一条条消息,这能够大大提高校验效率,因为避免了解压缩。
    2019-06-25
    4
  • 南辕北辙
    老师有一点不是很明白,在正常情况下broker端会原样保存起来,但是为了检验需要解压缩。该怎么去理解这个过程呢,broker端解压缩以后还会压缩还原吗?
    这个过程是在用户态执行的吗,总感觉怪怪的

    作者回复: 它只是解压缩读取而已,不会将解压缩之后的数据回写到磁盘。另外就像我置顶的留言那样,目前社区已经接纳了京东小伙伴的修改,貌似可以绕过这部分解压缩了,。

    2019-06-27
    3
  • 代码小生
    原来在 V1 版本中,每条消息都需要执行 CRC 校验,但是CRC在某些情况下会变化,所以crc拿到消息集和中更好,这个逻辑我没有明白呢,既然CRC会变,为了消息的正确性不更应该每条消息都校验吗?为什么说拿到消息集和中一次校验更好呢?

    作者回复: V2依然是做CRC校验的,只不过是在record batch这个层级上做,而不是一条一条消息地做了。如果CRC校验失败,重传batch。也就是说不会以消息作为传输单位进行校验,这样效率太低

    2019-09-18
    2
  • What for
    老师您好,您的课程很棒,又很实用又有原理性的分析!
    我想问一个问题,Producer 发送数据时以批次为单位,那么 batch 与 broker 端的消息集合又是怎么样的对应关系呢?每个消息集合的 record 数量是否固定呢?
    就是说在 Producer 端即使消息并没有达到 batch.size 的数量,linger.ms 也可以让它发送一批数据,那 broker 在低峰期的时候收到一批数据之后是会写入缓存等凑够一定数量组成一个消息集合还是说会立即(或设置超时时间)组成一个消息集合写入磁盘?
    谢谢!

    作者回复: 不是固定数量。
    “在 Producer 端即使消息并没有达到 batch.size 的数量,linger.ms 也可以让它发送一批数据” --- 是的

    取决于linger.ms的值

    2019-08-08
    2
  • 星期八
    老师那再问一下,如果多条消息组成消息集合发送,那是什么条件控制消息发送,如果是一条又是什么条件控制触发发送的呢

    作者回复: 主要是这两个参数:batch.size和linger.ms。如果是生产了一条消息且linger.ms=0,通常producer就会立即发送者一条消息了。

    2019-07-12
    1
    2
  • pain
    怎么样才能保持消息格式统一呢,只要集群中的 kafka 版本一致吗?

    作者回复: 嗯嗯,版本一致肯定是能保证的,不过通常比较难做到。

    2019-06-27
    2
  • Li Shunduo
    假如一个消息集合里有10条消息,并且被压缩,但是消费端配置每次只poll 5条消息。这种情况下,消费端怎么解压缩?矛盾点是 如果只取5条消息,需要broker帮助解压缩;如果取整个消息集合10条消息,会有贷款等资源的浪费?

    作者回复: 目前java consumer的设计是一次取出一批,缓存在客户端内存中,然后再过滤出max.poll.records条消息返给你,也不算太浪费吧,毕竟下次可以直接从缓存中取,不用再发请求了。

    2019-06-25
    1
    2
  • juan
    如果在配置中不指定压缩算法,kafka有默认的压缩算法吗?

    作者回复: 没有

    2019-07-09
    1
  • giantbroom
    我觉得有2个方案可以考虑:
    1. 在Producer和Broker建立连接是,生成一个token,Producer每次发送消息是都带着token,Broker只需验证token的有效性,而不必在解压缩;
    2. Producer在压缩之后,根据压缩后的数据生成jwt token,Broker同样只需验证jwt即可。
    2019-06-26
    1
  • dream
    老师,我对消息层次、消息集合、消息、日志项这些概念与它们之间的关系感觉很懵,
    消息层次都分消息集合以及消息,消息集合中包含日志项,日志项中封装消息,
    那么日志项中封装的是producer发送的消息吗?
    一个日志项中会包含多条消息吗?
    消息集合中消息项封装的的消息与消息层次包含的消息有什么关系呢?
    这两个消息与producer发送的消息有什么关系呢?
    一个消息集合对应是producer发送的一条消息还是多条消息呢?
    最后,老师能不能详细说一下CRC校验,谢谢!

    作者回复: 消息批次RecordBatch里面包含若干条消息(record)。
    你可以认为消息批次和消息集合是等价的,消息和日志项是等价的。
    这样消息层次有两层:外层是消息批次(或消息集合);里层是消息(或日志项)。
    Producer以recordbatch为单位发送消息,对于V2版本一个batch中通常包含多条消息。

    在V2版本中,在batch层面计算CRC值;在V1版本中,每条消息都要计算CRC值。

    2019-06-25
    3
    1
  • 衣申人
    老师,我看源码,broker在接收producer消息并落盘这块貌似没有用零拷贝啊!只有传输给consumer时用了,求解答

    作者回复: 是的,就是你理解的那样。Kafka使用Zero Copy优化将页缓存中的数据直接传输到Socket——这的确是发生在broker到consumer的链路上。这种优化能成行的前提是consumer端能够识别磁盘上的消息格式。

    2019-12-11
收起评论
54
返回
顶部