Hadoop-31 ZooKeeper 内部原理 简述Leader选举 ZAB协议 一致性 原创

章节内容

上一节我们完成了:

  • 新建Java的Maven工程
  • 使用Java调用ZK 进行操作
  • 创建节点、删除节点、监听节点等操作

背景介绍

这里是三台公网云服务器,每台 2C4G,搭建一个Hadoop的学习环境,供我学习。
之前已经在 VM 虚拟机上搭建过一次,但是没留下笔记,这次趁着前几天薅羊毛的3台机器,赶紧尝试在公网上搭建体验一下。

  • 2C4G 编号 h121
  • 2C4G 编号 h122
  • 2C2G 编号 h123
    在这里插入图片描述

Leader选举

选举机制

  • 半数机制:集群中半数以上机器存活,集群可用。所以 ZooKeeper 适合奇数台。
  • ZooKeeper 虽然在配置文件中没有指定Master和Slave,但是ZK在工作的时候,会有一个Leader其他的都是Follower

首次启动

假设有五台集群的机器:
在这里插入图片描述

  • 服务1启动,此时只有它一台启动了,它发出去的报文没有任何响应,所以一直是LOOKING状态
  • 服务2启动,它最开始启动的服务1进行通信,互相交换自己的选举结果。由于两者都没有历史数据,所以ID值较大的服务2胜出。但是目前还没有超过半数的服务同意,所以服务1服务2都是LOOKING状态
  • 服务3启动,服务3成了1、2、3的老大,集群中>=2台选了3,所以服务3成了Leader。
  • 服务4启动,服务4应该是1、2、3的老大,但是集群已经选了3为老大,所以4只可以做Follower
  • 服务5启动,同4。

非首次启动

每次选举的时候都会根据自身的事务ID优先选择事务ID大的为 Leader。

ZAB 一致性

ZAB 介绍

ZAB 是 Apache ZooKeeper 的一种使用场景和实现模式。
ZK就是分布式一致性问题的工业解决方案,Paxos算法是底层算法。
ZAB,即 ZooKeeper Atomic Broadcast,是 ZooKeeper 背后的一致性算法,确保了分布式系统中的数据一致性和可靠性。

数据一致性

为什么会出现数据一致性问题?

  • 将数据复制到分布式部署的多台机器中,可以消除单点故障,防止由于部分服务器宕机导致服务不可用。
  • 通过负载均衡,能够让分布在不同地区的数据副本全都对外提供服务,提高系统性能。
  • 但是分布式后,会导致数据不一致的情况出现

比如常见于 主从复制的时候
在这里插入图片描述

主备模式

ZK中,所有客户端写入数据都是写入Leader,由Leader复制到Follower中。
在这里插入图片描述

广播消息

ZAB协议的消息广播过程类似于二阶段提交。
对于客户端的写请求,全部由 Leader 接收,Leader将请求封装成一个事务 Proposal(提议),将其发送给所有Follower。
如果收到超过半数反馈ACK,则执行Commit操作(先提交自己,再发送Commit给其他Follower)。

发送Proposal到Follower
在这里插入图片描述

Leader接收Follower的ACK
在这里插入图片描述
超过半数ACK则进行Commit
在这里插入图片描述

Leader宕机

Leader如果宕机了,ZK集群将无法正常工作,ZAB协议提供了一个高效可靠的Leader选举算法。

  • ZAB协议保证那些已经在Leader提交的事务最终会被所有服务器提交
  • ZAB协议保证丢弃那些只在Leader 提交/复制,但没有提交的事务。
posted @   武子康  阅读(0)  评论(0编辑  收藏  举报  
相关博文:
阅读排行:
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
· 上周热点回顾(2.24-3.2)
点击右上角即可分享
微信分享提示