Kafka 2.8.0 正式发布，与ZooKeeper正式分手！

导读：目前 Kafka 已经定位为一个分布式流式处理平台，它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性而被广泛使用。目前越来越多的开源分布式处理系统如 Cloudera、Storm、Spark、Flink 等都支持与 Kafka 集成。

2021年4月19日，Kafka官方发布了2.8.0版本，包含了很多新特性！其中，我觉得最感兴趣的是提到的第一条特性-Kafka用自管理的Quorum代替ZooKeeper管理元数据。

之前Kafka使用ZooKeeper来存储有关分区和代理的元数据，并选择一个代理作为Kafka控制器。目前删除对ZooKeeper的依赖。这将使Kafka够以更具扩展性和更强大的方式管理元数据，从而支持更多分区。它还将简化Kafka的部署和配置。

Kafka 2.8.0 用自管理的Quorum代替ZooKeeper管理元数据，官方称这个为 "Kafka Raft metadata mode"，即KRaft mode

KRaft最大的好处在于移除了ZooKeeper，这样我们无需维护zk集群，只要维护Kafka集群就可以了

请注意，此图有些误导。除控制器外的其他代理可以并且确实与ZooKeeper进行通信。因此，实际上，应该从每个经纪人到ZK划清界限。但是，绘制很多线会使该图难以阅读。

可能有一些刚接触Kafka的小伙伴还不明白这到底代表着什么。

在kafka 2.8.0之前体系架构包括若干 Producer、若干 Broker、若干 Consumer，以及一个 ZooKeeper 集群，如下图所示。其中 ZooKeeper 是 Kafka 用来负责集群元数据的管理、控制器的选举等操作的。Producer 将消息发送到 Broker，Broker 负责将收到的消息存储到磁盘中，而 Consumer 负责从 Broker 订阅并消费消息。

不太理解的小伙伴可以查看下Kafka 2.8.0之前的部署和一些教程发现和新版本的差异还是很大的，你会发现增加了很多的成本，但短期可能会带来很多不便，基于长远的角度思考，这次改动对于Kafka的长远发展利大于弊。

Kafka 的代码库中还有很大一部分是负责在多个集群中安排日志、分配领导权、处理故障等。这使的 Kafka 成为一个可靠和可信的分布式系统。而ZooKeeper就是分布式代码工作的关键。在以往的版本中，ZooKeeper 提供了权威的元数据存储，这些元数据存储了系统中最重要的东西，例如分区可以存在哪里，哪个组件是主导等等等等

但不管怎么样，ZooKeeper 是一个基于一致日志的特殊文件系统/触发器API。而Kafka 是一个建立在一致日志之上的发布/订阅系统。

Kafka 2.8.0包括许多重要的新功能。以下是重要变化

简单点可以理解为：

• 抢先体验，kafka通过自我管理的仲裁来替代ZooKeeper（很快，Apache Kafka将不再需要ZooKeeper。）
• 增加集群描述API
• 在SASL_SSL监听器上支持彼此TLS认证
• JSON请求/响应的debug日志
• 限制broker连接创建率
• Topic识别
• 在Connect REST API中公开任务配置
• 更新 Streams FSM 以澄清ERROR状态的含义
• 扩展 StreamJoined 以允许更多的存储配置
• 更方便的TopologyTestDriver构造
• 引入 Kafka-Streams 专用的未捕获异常处理程序
• 启动和关闭Streams线程的API
• 改进 TimeWindowedDeserializer 和 TimeWindowedSerde 处理窗口大小
• 改善Kafka流中的超时和重试情况

智哥现在用的版本还停留在Kafka 2.2.1，当然这个版本一用就是几年?当然如果2.8.0版本稳定后建议后面的系统架构设计可以考虑下！

如果对具体的更新内容感兴趣，可以直接登陆官网进行查看：

• https://kafka.apache.org/downloads
• https://downloads.apache.org/kafka/2.8.0/RELEASE_NOTES.html
• https://blogs.apache.org/kafka/entry/what-s-new-in-apache5

当然，2.8.0版本还有很多未完善的地方，可能还不适合应用在生产环境。

- END -