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 提交/复制,但没有提交的事务。
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
· 上周热点回顾(2.24-3.2)