Kafka 2.0重磅发布,新特性独家解读
Posted 汇天科技
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kafka 2.0重磅发布,新特性独家解读相关的知识,希望对你有一定的参考价值。
汇天科技导读:近日, Apache Kafka 项目的 2.0.0 版本正式发布了!距离 1.0 版本的发布,相距还不到一年。
这一年不论是社区还是 Confluent 内部对于到底 Kafka 要向哪里发展都有很多讨论,这次版本的发布,更新了许多新特性,本文对其中几个新特性进行了解读。
在这一次的 2.0.0 版本中,更多相关的属性被加了进来,比如 KIP-268、KIP-279、KIP-283 等等。
1.KIP-268:简化 Kafka Streams 升级过程
Kafka Streams 利用 Consumer Rebalance 协议里面的元数据字符串编码诸如任务分配、全局查询、版本升级相关的信息。然而,当编码版本本身改变的时候,就需要进行离线升级。
KIP-268 利用 version prob 可以使得旧版本的任务分配者告知其他高版本的成员暂时使用旧版本的 Rebalance 元数据编码,这样就可以让用户依然能够通过 rolling bounce 在线升级 Kafka Streams 的版本。
而当所有参与的成员全部升级完毕之后,最后一次 rebalance 会自动切换回新版本的元数据编码。
2.KIP-279:修补多次 Kafka 分区主本迁移时的日志分歧问题
在升级 Kafka 版本或者做定期系统维护的时候,用户往往需要进行连续的多次 Kafka 分区迁移。在这次发布中我们修补了一个在此过程中可能会出现的一个会导致日志分歧发生的边缘情况。具体方案就是将此前版本中已经加入的主本 epoch 信息扩散到OffsetForLeaderEpochResponse。
如此所有主副本就可以清晰知道自己到底处于当前分区备份的哪一个阶段,从而杜绝因为消息不对等而可能导致的日志分歧。
3.KIP-283:降低信息格式向下转换时的内存消耗
在一个多客户端组群的环境下,客户端与服务器端的版本不匹配是常见现象。
早在 0.10.0 版本中,Kafka 已经加入了允许不同版本客户端与服务器交互的功能,即高版本的 Kafka 客户端依然可以与低版本的服务器进行数据传导,反之亦然。
然而当低版本的消费者客户端和高版本的服务器进行交互时,服务器有时需要将数据向下转换(format down-conversion)成为低版本客户端可以认知的格式后才能发回给消费者。
向下转换有两个缺点:
1、丢失了 Kafka 数据零拷贝(zero-copy)的性能优势;
2、向下转换需要额外的大量内存,在极端情况下甚至会导致内存溢出。
前者无法避免,但是后者依然可以改进:在即将发布的 2.0 版本中,我们使用了一种新的基于分块(chunking)的向下转换算法,使得需要同时占据的内存需求大幅缩减。
这使得高低版本的客户端与服务器之间的交互变得更加有效。
总 结
关于 2.0.0 版本,我们其实还有很多新的发布特性,比如新的 Kafka Streams Scala API 帮助 Scala 用户更好的利用 Scala typing system 进行编程,Kafka Connect REST extension plugin 对于认证和访问控制的支持等等。
关于更多细节,欢迎大家阅读相关公告:
https://www.apache.org/dist/kafka/2.0.0/RELEASE_NOTES.html
汇天科技立足自主研发、为传统及创新企业提供基于本地及云平台的企业智能化、信息化解决方案,重要组件包括ERP、WMS、CRM、MES、SCM以及电子商务等。支撑企业战略发展,加速企业进行工业4.0信息化改造,助力传统行业向智能化转型,帮助企业整合资源、调度供需、提升效率、降低运营成本,并最终向“智能工厂”,“智能生产”,“智慧销售”,“数据驱动商业模式”的目标迈进。
以上是关于Kafka 2.0重磅发布,新特性独家解读的主要内容,如果未能解决你的问题,请参考以下文章
重磅!Apache Flink 1.16 发布在即!众多新特性全面解读!
官方解读:TensorFlow 2.0中即将到来的所有新特性