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也改成拉模式了


相关推荐
李慕婉学姐1 小时前
【开题答辩过程】以《基于JAVA的校园即时配送系统的设计与实现》为例,不知道这个选题怎么做的,不知道这个选题怎么开题答辩的可以进来看看
java·开发语言·数据库
じ☆冷颜〃2 小时前
黎曼几何驱动的算法与系统设计:理论、实践与跨领域应用
笔记·python·深度学习·网络协议·算法·机器学习
数据大魔方2 小时前
【期货量化实战】日内动量策略:顺势而为的短线交易法(Python源码)
开发语言·数据库·python·mysql·算法·github·程序员创富
POLITE32 小时前
Leetcode 23. 合并 K 个升序链表 (Day 12)
算法·leetcode·链表
楚来客2 小时前
AI基础概念之八:Transformer算法通俗解析
人工智能·算法·transformer
Echo_NGC22373 小时前
【神经视频编解码NVC】传统神经视频编解码完全指南:从零读懂 AI 视频压缩的基石
人工智能·深度学习·算法·机器学习·视频编解码
会员果汁3 小时前
leetcode-动态规划-买卖股票
算法·leetcode·动态规划
奋进的芋圆3 小时前
Java 延时任务实现方案详解(适用于 Spring Boot 3)
java·spring boot·redis·rabbitmq
橘颂TA3 小时前
【剑斩OFFER】算法的暴力美学——二进制求和
算法·leetcode·哈希算法·散列表·结构与算法
sxlishaobin3 小时前
设计模式之桥接模式
java·设计模式·桥接模式