Apache Kafka 2.7.0发布,加速移除分布式系统协调服务

分布式发布与订阅系统Apache Kafka社群,发布了2.7.0这个迟来的版本,该版本的几个重点更新,包括持续将Apache Kafka中的ZooKeeper替换掉,加入了新的内部代理API,并且增加新的Core Raft共识算法的实例,现在Apache Kafka中具有单独包含核心共识协议的Core Raft模块。另外,分层存储的工作也持续进行中,以提供无限扩展和更快达到重新平衡的能力。

Zookeeper原本是在Apache Kafka中,扮演协调代理的角色,所有代理服务器启动时,都会连接到Zookeeper进行注册,当代理状态发生变化时,Zookeeper便会存储这些资料,Kafka的代理会通过Zookeeper与其他代理沟通进行同步,也就是说Kafka没有Zookeeper,也就无法顺利运行。

不过,Zookeeper并非Kafka的一部分,因此运行每一个Kafka集群,都必须部署两套系统,这产生了许多问题,包括造成多余资源的耗费,包括更多网络、监控功能以及安全性等资源配置,而Kafka集群规模增加,也就代表Zookeeper必需要跟着扩展,必须使用更多的缓存,且Zookeeper作为外部的元资料存储服务,当元资料越来越多,使得控制器加载时间越来越长,限制了Kafka集群的规模扩展。

因此在2019年的时候,Apache Kafka社群就开始移除Zookeeper的手术工作,要由Kafka本身提供元资料管理功能,而Apache Kafka 2.7.0总共有7个更新,与移除Zookeeper工作有关,包括了KIP-497添加内部代理API,来替换原本的内部同步副本(In-Sync Replica,ISR)。

目前Kafka分区负责程序(Partition Leader)和ISR信息,皆存储在Zookeeper中,控制器与分区负责程序都可以更新此状态,但由于任一方都可以更新状态,也就存在共享信息的机制,而这会使ISR的更新出现延迟,也就代表元资料请求可能会收到旧信息。

Apache Kafka 2.7.0加入了一个新的AlterIsr API,赋给控制器独占能力,更新分区负责程序和ISR的状态,新API的好处是让元资料请求,总能获得最新的状态。官方提到,要删除ZooKeeper,添加此API是重要的一步。

另外,当Kafka Streams应用程序的来源主题被删除时,Kafka Streams现在可以正确发出异常消息。目前,当用户删除正在执行的Kafka Streams来源主题,则嵌入的消费客户端会被正常关闭,这会触发重新平衡,直到Kafka Streams应用程序所有StreamThreads正常退出,应用程序完全关闭,而这过程没有机会回应错误。在Apache Kafka 2.7.0,当用户从正在运行的流媒体应用程序,删除来源主题,该应用程序将丢出MissingSourceTopicException,让用户可以做出反应。

官方提到,因为Kafka集群的规模日益增加,用户需要在Kafka中存储更多的资料,因此他们开始引入分层存储的概念。Kafka的存储现在分为本地端与远程两层,用户可以将资料在本地暂存之后,丢到远程进行较长期的存储,如此,本地端存储层留存资料的时间,将会从数天降到数小时,使用HDFS或S3等存储系统的远程层,就可以将资料留存数天甚至数月的时间。