Apache Kafka 3.0.0正式发布,在众多更新中,这个版本最重要的两个重点,是API变更以及对KRaft的改进,而KRaft是Apache Kafka新的内置共识机制,将会取代分布式系统协调服务Apache ZooKeeper。
从Kafka 2.X版本开始,官方就开始启动移除Apache ZooKeeper的计划,ZooKeeper在Kafka中扮演协调代理的角色,当代理服务器启动时,需要向ZooKeeper注册,并由ZooKeeper管理代理的状态,也协助代理之间沟通与信息同步,因此在过去,Kafka需依赖ZooKeeper才能运行。
但是ZooKeeper是独立运行的系统,因此用户在使用Kafka的同时,还必须执行一套ZooKeeper系统,产生的问题除了资源浪费外,由于Zookeeper作为外部元资料存储服务,随着Kafka扩展Zookeeper所存储的元资料越多,加载的时间也越长,进而限制了Kafka集群扩展。
因此官方在近期的次要版本,重点都摆在Kafka Raft元资料模式(KRaft)这个Kafka内置的共识机制,以此作为Zookeeper的替代方案。不同于Zookeeper,KRaft是内置在Kafka中的控制器,能在Kafka集群内部执行,或是在特殊使用场景,移至专门的机器上执行也没问题。
Kafka 3的更新重点之一,也还是放在KRaft改进上,目前KRaft进入预览阶段,尚未完全取代Zookeeper,不过在部分系统运行上,已经逐渐不需要Zookeeper。
在3.0中,KRaft新加入的功能KRaft快照,让KRaft控制器和KRaft代理,来为名为__cluster_metadata的主题分区,产生、复制和加载快照,官方解释,Kafka集群使用该主题,来存储和复制有关集群的元资料信息,诸如代理配置和主题分区分配等,当这些状态随着时间增加变得复杂,Kafka快照能以有效率的方式,存储、加载和复制信息。
为了要让Kafka,能顺利地从Zookeeper切换到KRaft,开发团队重新设计了该工具的元资料记录类型,并让KRaft控制器开始在Zookeeper和KRaft模式下,负责产生Producer ID。而在Kafka Connect上,强化了任务重启功能,且改进Kafka Streams基于时间戳的同步功能,并赋给MirrorMaker2更灵活的配置选项。
除此之外,官方也开始一些清理工作,像是Kafka不再支持消息格式v0与v1,从2017年开始,消息格式v2就一直是默认格式,因此他们决定在Kafka 3中弃用旧版本,官方提到,旧格式已经很少被使用,在Kafka 3中,当用户选择使用旧版本消息格式,将会收到警告,预计Kafka4就会删除。
另外,官方也宣布在Kafka 3弃用Java 8的支持,包括所有Kafka中的Java 8组件,官方提到,Kafka 4将计划移除Java 8的支持,而现在给用户缓冲的时间进行更改。同时,Kafka 3也弃用Scala 2.12,对该语言的支持同样会在下一个主要版本移除。
领取专属 10元无门槛券
私享最新 技术干货