中济建设官方网站,响应式 网站建设,个人logo在线生成免费,市场调研报告1500字我们之前的Kafka值依赖于Zookeeper注册中心来启动的#xff0c;往里面注册我们节点信息
Kafka是什么时候不依赖Zookeeper节点了
在Kafka2.8.0开始就可以不依赖Zookeeper了
可以用KRaft模式代替Zookeeper管理Kafka集群 KRaft Controller和KRaft Leader的关系
两者关系
Lea…我们之前的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依赖 ISRIn - 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码上加薪
