KRaft面试思路引导

Kafka实在2.8之后就用KRaft进行集群管理了

Conroller负责选举Leader,同时Controller管理集群元数据状态信息,并将元数据信息同步给各个分区的Leader

和Zookeeper管理一样,会选出一个Broker作为Controller去管理整个集群,但是元数据存储不同了

Zookeeper是树形结构存储,为每个ZNode,每个分区有一个ZNode节点

而KRaft就是用日志存储的,Controller中会有个单分区的内部主题 _cluster_metadata存储元数据信息


Zookeeper本身的限制

Zookeeper写操作串行的限制

Zookeeper 的写操作(如分区选举、Controller 变更)是串行的,成为性能瓶颈,尤其在集群规模大时(如数十万分区)

ZK 模式 下,Kafka 的元数据(如分区选举、Controller 变更)依赖 ZooKeeper 存储,而 ZooKeeper 的所有写操作都是串行化的

ZooKeeper 集群有一个 Leader 节点(通过 ZAB 协议选举),所有写请求(无论来自哪个 Kafka Broker)都必须由 Leader 处理

Zookeeper单线程回调机制

事件触发

当节点发生变化(如 Broker 宕机,节点被删除),ZooKeeper 会生成一个 Watcher 事件 (如 NodeDeleted

事件派发

ZooKeeper 服务端将事件放入单线程队列 ,由 单线程的 EventThread 依次执行回调(通知 Kafka Controller)

Zookeeper模型存储限制

Zookeeper 的存储模型限制了 Kafka 分区数量的扩展(如单 Zookeeper 集群难以支撑百万级分区)

Zookeeper使用树形结构存储元数据,百万个分区就有百万个ZNode节点,会导致内存占用激增

并且Zookeeper必须将所有ZNode加载到内存中,容易OOM+停顿

Zookeeper的单Controller机制

Zookeeper是单Controller机制,Controller选举的时候没有备用方案而是所有的Broker都去参与选举,选举过程不稳定还会有脑裂问题

KRaft 中有类似备用 Controller 的概念,有一个主Controller和多个Controller副本。在 KRaft 协议中,会有一个 Leader 作为主要的 Controller 负责管理和协调工作,同时存在多个 Follower 节点可以在 Leader 出现故障时快速切换成为新的 Leader(即新的 Controller)


KRaft对比Zookeeper的优势

存储方式+并发+Controller副本机制(Kraft的性能更好)

1.日志管理元数据,支持并发写,解决Zookeeper单线程写限制。因为Kafka的Offeset的频繁更新会有大量的写操作,Zookeeper单线程写性能不足

2.Kafka将offset和元数据分开存储,而zookeeper将offset和元数据都存到ZNode中,offset写频繁,元数据读频繁,两者分开存储会提高系统效率

3.Kafka支持执行命令后并发通知,解决Zookeeper单线程回调机制

4.KRaft是一种选举算法,不像Zookeeper有本身系统的限制

KRaft中将Kafka工作产生的日志都放到了一个单分区的内部主题 _cluster_metadata

Zookeeper使用树形结构存储元数据,百万个分区就有百万个ZNode节点,会导致内存占用激增。并且Zookeeper必须将所有ZNode加载到内存中,容易OOM+停顿

5.KRaft是单主Controller+多个Controller副本,在Controller宕机后能迅速用副本恢复。而Zookeeper是单Controller机制,选举过程很慢,同时还会有脑裂问题的出现

6.Follower同步Leader机制从原本的ISR机制变成了少数服从多数投票机制


Raft和KRaft的不同

Raft算法使用推模式同步

KRaft算法使用拉模式同步

新角色Observer

因为KRaft是节点是主动去拉取日志,所以对比之前的Leader和Follower角色,还多出了一个Observer角色去Leader中去拉取日志

其实这个角色只是一个抽象的模型,实际上就是Broker去拉取日志而已


KRaft为什么不用推模式?KRaft和Raft的优缺点

Raft因为是推模式,所以节点同步的实时性会更好,但是没有考虑Follower的性能+消费能力,可能会造成压力

KRaft因为是拉模式,所以节点实时性不强,但是Follower会根据自身情况控制消费速度,减轻自身压力防止系统资源浪费

但是实际上,KRaft因为是适配Kafka的,Kafka本身日志同步就是拉模式,所以KRaft也改成拉模式了


相关推荐
Clf丶忆笙15 分钟前
SpringBoot异步处理@Async深度解析:从基础到高阶实战
spring boot
ŧ榕树先生21 分钟前
查看jdk是否安装并且配置成功?(Android studio安装前的准备)
java·jdk
未来的JAVA高级开发工程师25 分钟前
适配器模式
java
LUCIAZZZ30 分钟前
JVM之内存管理(一)
java·jvm·spring·操作系统·springboot
D_aniel_1 小时前
排序算法-计数排序
java·排序算法·计数排序
极小狐1 小时前
极狐GitLab 通用软件包存储库功能介绍
java·数据库·c#·gitlab·maven
旧故新长1 小时前
Browserless 快速上手
java
java1234_小锋1 小时前
Spring Bean有哪几种配置方式?
java·后端·spring
?abc!1 小时前
缓存(5):常见 缓存数据淘汰算法/缓存清空策略
java·算法·缓存
BioRunYiXue1 小时前
一文了解氨基酸的分类、代谢和应用
人工智能·深度学习·算法·机器学习·分类·数据挖掘·代谢组学