01
架构概览
Zookeeper 提供了配置服务、分布式同步、命名服务、Leader 选举和集群管理等功能,在大数据时代的开始很多开源产品都依赖 Zookeeper 来构建,Apache Kafka 也不例外。但是随着 Kafka 功能的演进和应用的场景越来越多:
因此作为 Zookeeper 的替代,Kafka 3.3.1 提供了 KRaft 元数据管理组件。下图来自于 KIP-500 1提案,左右分别是 Zookeeper 模式和 KRaft 模式的部署架构图。
在 Zookeeper (后面简称为 ZK)模式下:
在 KRaft 模式下:
Raft 的原理和实现已经有很多优秀的文章介绍过了,就不在此赘述了。下面着重介绍一下 Kafka 如何基于 KRaft 实现集群的最终一致性协调。
02
最终一致性协调
最终一致性协调分为两部分:Controller 内存数据与 KRaft 的一致性;Broker (分区 / 配置 / ...)状态与期望的一致性。
2.1 Controller
Controller 在生产环境中通常由 3 个节点组成 Quorum,底层使用 KRaft 来进行一致性协调,KRaft 的 Leader 即是 Controller Leader。只有 Leader 会进行请求处理,Follower 只会跟随 Replay KRaft 中的数据,请求处理流程简要如下:
以 CAS(expectValue, newValue) 举例说明上述的流程,假设内存中的初始状态为 1,Broker Client 提交了请求 CAS(1, 2) 到 Controller:
简而言之,Controller 简版的处理时序如下:开始处理请求 A -> Manager 生成响应和 Records -> Records 在 KRaft 多数派确认 -> Manager#replay(Records) -> 返回响应 -> 处理下一条请求...通过上述的处理时序,Controller 就可以做到“内存状态与 KRaft ”和“多节点之间的内存状态”的一致性:
Controller 简版的处理时序在正确性上没什么问题,但在性能上有所瓶颈。假设每次 KRaft 多数派确认需要 2ms,意味着 Controller 处理请求的最大吞吐为 500 req/s。因此 Kafka 的实际处理模型中将最耗时的 KRaft 确认这步从处理时序中移除了。具体流程如下图所示:
相比简版的处理时序:
Controller 处理请求的最大吞吐为:Min(1s / Manager 代码执行 CPU 耗时, KRaft 写入吞吐)。然而先 #replay 到内存再让 KRaft 确认可能会造成内存里面有脏数据,仍旧以 CAS(1, 2) 举例,考虑如下场景:
为了解决这个问题,Kafka 设计了一系列支持 MVCC 的 Timeline 数据结构:TimelineHashMap、TimelineHashSet、TimelineInteger、TimelineLong 和底层的 SnapshotRegistry。Controller 的内存状态都通过 Timeline 数据结构来维护,当出现 Leader 切换时,旧的 Leader 会将 Timeline 数据结构的数据回滚到上一个已经被 KRaft 多数派确认的状态,来保证旧 Leader 内存中不会有脏数据。可能细心的小伙伴会发现,解决了写入的脏数据问题,那是不是可能读到还未被 KRaft 确认的数据呢?Timeline 数据结构也考虑到了这点,例如 TimelineLong 提供了 #get(epoch) 接口,其中 epoch 通常传入的是 KRaft CommitedOffset,以此来保障读到的数据都是 KRaft 确认过的数据。对 Timeline 数据结构有兴趣的小伙伴,可以自行研究一下 server-common 模块下 org.apache.kafka.timeline 这个包的实现。
2.2 Broker
在上一章节我们提到,Controller Follower 会 #replay KRaft 中的数据来构建自己的内存状态。Broker 同理也一样会订阅 KRaft 中的 Records 来构建自己的内存元数据,并且根据这些 Records 来执行特定的变更。以分区管理为例,假设集群有 B1 和 B2 两个节点,用户将分区 P1 从 B1 移动到 B2(简化 ISR 变更的过程):
这时候 B1 和 B2 都可以通过内存元数据提供一致的的 Topic Metadata 查询服务,并且完成了分区 P1 的移动。通过这种方式,很多变更 Controller 无需再主动调用 Broker 的 RPC 来尝试将集群推进到某个状态,也无需处理 RPC 调用中的顺序和幂等重试等问题。转换思路,Controller 通过 KRaft 来下发期望的状态,然后 Broker 去达成状态,这和 K8s 推荐的声明式管理有异曲同工之妙。
03
总结
我们可以看出 KRaft 替换 ZK,并不是元数据存储重新造轮子,而核心是集群协调机制的演进。整个通信协调机制本质上是事件驱动模型,也就是 Metadata as an Event Log,Leader 通过 KRaft 生产权威的事件,Follower 和 Broker 通过监听 KRaft 来获得这些事件,并且顺序处理事件,达到集群状态和期望的最终一致。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。