我们之前的Kafka值依赖于Zookeeper注册中心来启动的，往里面注册我们节点信息
Kafka是什么时候不依赖Zookeeper节点了
在Kafka2.8.0开始就可以不依赖Zookeeper了
可以用KRaft模式代替Zookeeper管理Kafka集群
KRaft Controller和KRaft Leader的关系
两者关系
- Leader 是 Controller 的选举结果：KRaft Controller 负责 Kafka 集群的管理，如主题管理、分区分配、副本管理等重要任务。在 KRaft 架构下，Controller 节点是从所有 Broker 节点中通过 KRaft 选举机制选出的，当选的这个 “Controller Broker” 节点内部存在一个 Leader 角色， 这个 Leader 负责在 Controller 节点内部以及与其他 Broker 节点之间协调和同步集群元数据等关键信息 也就是说，KRaft Leader 是在 KRaft Controller 选举过程中确定的，用于主导 Controller 相关工作的执行以及与其他节点交互。
- 数据交互：从数据流转角度看，如图片中展示的，KRaft Controller 会从 KRaft Leader 拉取数据，这是因为 KRaft Leader 维护着最新的集群元数据状态等信息，其他 Controller 需要通过从 Leader 拉取数据来保证自身拥有的集群元数据的一致性和及时性，进而正常执行集群管理职责
Controller 与 Leader 的协作关系
- 元数据同步：Controller 会将集群的元数据信息同步给各个分区的 Leader，使 Leader 能够根据最新的元数据来处理客户端的请求。例如，当分区的副本数量发生变化时，Controller 会将新的副本信息通知给 Leader，以便 Leader 进行数据同步等操作。
- 故障处理：当 Leader 出现故障时，Controller 会触发新的 Leader 选举流程，并确保新的 Leader 能够尽快接管工作，保证数据的可用性和一致性。同时，Controller 也会与新的 Leader 协作，更新集群元数据，让其他 Broker 和客户端能够及时获取到最新的状态信息
人话
我们会选出一个Broker作为管理集群的Controller，它有一个单分区的内部主题_cluster_metadata
存储元数据信息
然后还会选几个备用Broker，里面有存储元数据信息的单分区的内部主题_cluster_metadata的副本
所以并不是每一个Borker都是Controller
为什么用KRaft代替Zookeeper管理kafka集群元数据之Broker扩展差
Zookeeper管理集群流程
Kafka中会有一个Broker节点被选为控制器Controller，去管理整个集群
如果有一个Broker节点出现故障
那么Controller将负责为故障Broker节点上的分区重新选出新的Leader副本
Kafka的Broker节点都默认接收受控关机
受控关机的好处：尽量减少对客户端服务的中断
假设我们要关闭Broker0
我们会向Broker0发送一个SIG_TERM信号
然后在Broker0关闭之前，我们要向控制器Controller发送一个ControllerShutDownRequet
然后控制器Controller完成分区的重新选主和ISR列表收缩工作
然后Broker0同步阻塞，等待控制器Controller的回复
收缩
然后这个收缩成{2,3}
这里的蓝色表示ISR信息还没有持久化到Zookeeper集群中
然后我们的Controller会在这两个副本中选择一个Partition-的Leader副本
最后把ISR列表信息以及Leader副本信息持久化到Zookeeper集群中
ISR列表为红色，说明已经持久化到Zookeeper集群中了
发送LeaderAndlsrRequest请求
收到该请求的Broker节点将从LeaderAndlsrRequest请求中解析出Leader和ISR列表信息
Kafka1.1.0之前，必须在一个Broker节点明确回复收到数据之后，控制器才会向下一个Broker节点发送LeaderAndlsrRequest请求
Broker从请求中解析出Leader等元数据信息之后，并且把数据存储在本地之后，它才会给Controller一个响应，告知Controller元数据信息是否写入成功
只有Controller收到响应成功之后，他才会向下一个节点例如Broker-3发送LeaderAndlsrRequest请求
Kafka1.0之前，所有的同步元数据操作都是单线程同步阻塞进行的
甚至在关闭之前，Controller一次只会移动一个Leader分区
整个过程都是同步阻塞进行的
当这个节点都迁移完之后
我们的Controller才会向Broker-0节点发送ControlledShutdownResponse响应，Broker-0才会关闭自身服务
总结
- 1个控制器需要向ZK单线程更新写入每个分区的最新元数据
- 关闭一个Broker服务因为这个单线程写入模式，可能会导致耗时很长
- 分区在重新选举Leader的时候，会暂停对外提供读写服务
KRaft模式中Kafka的Controller节点的日志同步过程
在KRaft中将Kafka工作产生的日志都放到了一个单分区的内部主题_cluster_metadata中
这个主题中存储的数据是原来Zookeeper集群管理Kafka的时候，在Zookeeper的zNode节点中存储的元数据
PS：这个主题是一个单分区主题
只有一个分区的好处是，可以保证数据的全局有限性
因为一旦Controller产生的日志顺序出现错乱后果是相当严重
因此这是一个Kafka的内部单分区主题
但是这个主题是可以有多个副本的
其中Leader副本存储的是Active Controller节点直接写入的数据
相当于：你配置了多少个Controller角色，这个_cluster_metadata主题就可以自动生成多少个分区的副本
写入数据
例如我们用命令创建主题或者修改分区的时候，Kafka的后台会向Active状态的Controller节点发送元数据信息
并且我们的元数据写入的时候我们还会有任期编号，例如这个蓝色的1
这个编号的目的：表示这条消息是在哪个任期产生的
复制数据
我们的KRaft采用的是拉模式来复制日志
然后我们的日志进行异步提交
提交日志
然后Leader节点会告诉Follower节点，让他们也向日志提交相应的内容
移动高水位
蓝色那条线移动了
KRaft的提交是多数原则，而不是ISR机制
records 的 commit 依据是 quorum 而不是 ISR”，Kafka 传统副本复制中，消息的提交（commit）依赖 ISR（In - Sync Replica，同步副本集）机制。
ISR 是指与 Leader 副本保持同步的 Follower 副本集合，当 Leader 接收到消息并写入本地日志后，只要 ISR 中的多数副本确认收到消息，该消息就可以被标记为已提交
而在 KRaft 中，records 的提交依据是 quorum（法定人数）原则。quorum 指的是在一个分布式系统中，为了达成共识或者完成某个操作所需要的最少节点数量。在 KRaft 的场景下，当满足 quorum 数量的节点确认收到并持久化了 records，这些 records 就会被提交。这与 Kafka 传统副本复制的 ISR 机制在确认消息提交的方式上有所不同，quorum 机制更强调分布式系统中的多数节点的认可，以实现数据的一致性和可靠性
KRaft是多数副本机制，ISR是多数ISR机制（ISR中不一定是全部副本，例如我们副本有5个，ISR中有3个，我们是以ISR中多数确认为主而不是多数副本确认为主，ISR中副本数不等于总副本数）
- ISR：消息提交并不一定基于多数节点认可。只要 Leader 副本收到 ISR 中所有副本的 ACK 确认（即使 ISR 成员可能少于副本总数的一半 ），就可将消息标记为已提交。 例如，若一个分区有 5 个副本，ISR 集合中有 3 个副本，只要这 3 个副本都确认收到消息，消息就提交，不要求是副本总数的多数。
- quorum：严格遵循多数节点认可原则。在一个有 n 个节点的分布式系统中，通常需要超过 n/2 的节点认可才能完成相关操作（如消息提交 ）。例如，在 5 个节点的系统中，需要至少 3 个节点认可
Raft和KRaft有什么不同？
在Kafka2.8.0开始就可以不依赖Zookeeper了
可以用KRaft代替Zookeeper管理Kafka集群
Raft算法使用推模式
KRaft算法使用拉模式
在KRaft管理模式中，可以部署奇数个Controller节点
并且有且只有一个Controller节点是Leader节点，也就是Active状态
只有Active状态的Leader节点才可以对外提供服务
其他的节点都是Follower节点
这些Follower状态的Controller节点都是从Active状态的Leader节点拉取元数据，并备份到本地的KRaft log文件中
Kraft的拉模式和Raft的推模式具体有哪些不同呢？各有什么优缺点
在元数据不大的情况下，推模式不是元数据备份的实时性更好吗？为什么要改造成拉模式呢？
因为一开始Kafka的架构就是每个Partition的分区副本都是Follower从Leader副本同步数据
为了遵循一开始的使用架构Kafka才对Raft日志的复制部分进行了改造，改造成了拉模式
其他不同
任期时间
Raft模式中的Leader的任期时间是term
而在KRaft中，Leader的任期时间是epoch
新的状态节点
这个Observer节点不会参与Leader选举
它只是负责发现并从Leader节点中拉取元数据信息
每个Broker节点都充当Observer
控制器节点就充当Leader和Follower
Broker节点会按照需求从Leader节点中拉取本地不存在的元数据信息
全文总结-Zookeeper管理和Raft和KRaft管理的区别
Zookeeper中Broker受控关机时间长
Kafka1.1.0之前是单线程同步阻塞执行
之后是异步非阻塞执行
- 1个控制器需要向ZK单线程更新写入每个分区的最新元数据
- 关闭一个Broker服务因为这个单线程写入模式，可能会导致耗时很长
- 分区在重新选举Leader的时候，会暂停对外提供读写服务
KRaft和Zookeeper的管理元数据区别
在KRaft中将Kafka工作产生的日志都放到了一个单分区的内部主题_cluster_metadata中
这个主题中存储的数据是原来Zookeeper集群管理Kafka的时候，在Zookeeper的zNode节点中存储的元数据
KRaft和Zookeeper的日志提交区别
Zookeeper机制下，我们使用的是ISR机制
KRaft模式下，我们使用的是多数投票机制
KRaft和Zookeeper的备用Controller机制
Zookeeper 管理 Kafka 中的 Controller（只有一个Controller）
- 选举恢复机制：如前面所说，Kafka 依靠 Zookeeper 进行 Controller 选举，当当前 Controller 节点故障时，Zookeeper 通过删除 “/controller” 节点触发新的选举流程，其他 Broker 竞争成为新的 Controller。这个过程中没有专门预先设定好的备用 Controller 节点，所有非 Controller 的 Broker 都有机会参与选举。
- 潜在问题：在选举期间，可能会有短暂的集群管理空白期，并且如果有大量 Broker 同时竞争 Controller，可能会导致选举过程不稳定或产生 “脑裂” 等问题，影响 Kafka 集群的正常运行。
KRaft 中的 Controller（有一个Active Controller和多个备用Controller）
- 备用机制：KRaft 中有类似备用 Controller 的概念。在 KRaft 协议中，会有一个 Leader 作为主要的 Controller 负责管理和协调工作，同时存在多个 Follower 节点可以在 Leader 出现故障时快速切换成为新的 Leader（即新的 Controller）。 这些 Follower 节点会实时同步 Leader 的状态和数据，相当于备用的 Controller，能够在故障发生时迅速接管工作，减少集群管理的中断时间。
- 优势：这种机制相比 Zookeeper 管理 Kafka 的 Controller 选举方式，故障切换速度更快，因为备用节点已经在持续同步数据和状态，不需要像 Zookeeper 管理 Kafka 那样重新进行选举流程，从而提高了集群的稳定性和可靠性
KRaft和Raft的区别
Raft模式下，我们是Leader向Follower推数据来进行日志同步
KRaft模式下，我们是Follower向Leader拉数据来进行日志同步
KRaft中有个新角色，是和Zookeeper管理集群的时候一样的角色，也就是Observer
Observer按照需求从Leader节点中拉取本地不存在的元数据信息
Observer 的存在可以帮助集群在不增加选举投票负担的情况下，扩展获取元数据的能力，提升系统的读性能
参考文章：bilibli码上加薪
