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 提交/复制，但没有提交的事务。