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

分散式发布与订阅系统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等储存系统的远端层，就可以将资料留存数天甚至数月的时间。