Apache Kafka 移除 ZK Proposals( 二 )


在 Proposed 架构中,三个控制器节点取代了 Zookeeper 的 3 个节点 。控制器节点和 broker 节点在不同的 JVM 中运行 。控制器节点为元数据分区选举一个 leader 节点,用橙色标识 。相较于控制器向各个 broker 推送元数据更新,在 Proposed 中,各个 broker 从 leader 中拉取元数据更新 。这就是箭头指向控制器的原因 。
注意,控制器进程与 broker 进程是逻辑隔离的,它们不必做物理隔离 。在某些情况下,将部分或者全部控制器进程与 broker 进程部署在一个节点上,有其存在的意义 。这和 Zookeeper 进程和 Kafka broker 部署在同一个节点上(目前小型集群的部署方式)类似 。通常,各种各样的部署方式都可能出现,包括在同一个 JVM 中运行 。
控制器 Quorum
控制器节点由管理元数据日志的 Raft quorum(Raft 选举机制)组成 。该日志包括每次变更集群的元数据相关信息 。目前,一切信息都存储在 Zookeeper 中,比如 topic、partition、ISR、配置等,在新的架构中,这些信息都将存在日志中 。
通过 Raft 算法,控制器节点将在它们之间选举 leader,不需要依赖任何外部系统 。元数据日志的 leader 被称作活动的(active)控制器 。活动控制器处理所有来自 broker 的 RPC 调用 。follower 控制器(相对 leader 控制来说)从活动控制器中复制所有写入的数据,并且当活动控制器故障时,做为热备(hot standbys) 。由于控制器全量追踪最新状态,控制器故障切换将不再需要花很多时间转移最新状态到新的控制器上 。
和 Zookeeper 一样,Raft 需要大多数节点能正常运行,才能正常工作 。因此,3 个节点控制器集群允许一个节点失效 。5 个节点的控制器集群允许两个节点失效,以此类推 。
控制器将按周期将元数据快照写入磁盘 。虽然在概念上和压缩相似,但是代码路径有些许不同,原因是我们从内存中读取状态,而不是从磁盘中重读日志 。
管理 broker 元数据
不同于控制器将更新推送至各个 broker,这些 broker 将通过新的 MetadataFetch API 从活动控制器拉取更新 。
MetadataFetch 与拉取请求类似 。就和拉取请求一样,broker 将记录最近一次拉取的更新的 offset,并且只从活动控制器请求新的更新 。
broker 将拉取到的元数据持久化至磁盘 。这将使得 broker 启动的非常快,即使有成百上千分区,甚至上百万个分区 。(注意,这种持久化是一种优化,如果忽略这种优化可以提高开发效率,那么我们可以在第一个版本中忽略它)
大多数时候,broker 只需要拉取增量状态(deltas),而不是全量状态 。无论如何,如果 broker 的状态与活动控制器的状态差距过大,或者 broker 完全没有缓存元数据,控制器将返回全量元数据镜像,而不是返回一些列的增量数据 。

Apache Kafka 移除 ZK Proposals

文章插图
 
broker 按周期从活动控制器中请求元数据更新 。该请求同时做为心跳发送,控制器以此得知该 broker 是存活状态 。
注意,虽然本节只讨论管理 broker 的元数据,但是管理客户端的元数据对于可伸缩性也很重要 。一旦发送增量元数据更新的基础设施搭建好后,这些基础设施将用于客户端和 broker 。毕竟,一般情形下,客户端的数量会大于 broker 的数量 。随着分区数量的增长,客户端感兴趣的分区也会越多,所以,以增量的方式将元数据更新交付给客户端将变得越来越重要 。我们将在接下来的几个小节中讨论这个问题 。
broker 状态机
目前,broker 在启动以后,马上在 Zookeeper 中注册自己 。注册的过程完成两件事:告诉 broker 它是否被选举为控制器,让其他节点知道如何和它联系 。
在后 Zookeeper 时代的世界里,broker 通过控制器 quorum 注册自己,而不是 Zookeeper 。
当前,一个能够联系 Zookeeper ,但由控制器分区的 broker,能继续为用户的请求提供服务,但不会接收任何元数据更新 。这将导致一些令人困惑、难以应对的情况 。例如,一个 producer 通过 acks=1 继续发送数据给 leader,但实际上该 leader 已经不再是真正的 leader,但是这个失效的 leader 无法接收控制器的 LeaderAndIsrRequest,从而移除 leader 地位 。
在后 ZK 时代的世界里,集群的成员关系集成在元数据更新中 。如果 broker 无法接收元数据更新,将从集群的成员中移除 。虽然该 broker 仍然可能被某个特殊的客户端分区,但如果该 broker 是由控制器分区的,仍将从集群中移除 。
broker 状态
Apache Kafka 移除 ZK Proposals


推荐阅读