大数据入门：Zookeeper结构体系

Zookeeper作为大数据技术生态当中的一个分布式服务框架，也可以算是Hadoop的一个重要子项目，最初作为MapReduce的协调服务组件而存在，后来独立出来，负责整个集群的协调服务，在大数据生态当中地位关键。今天的大数据入门分享，我们就来讲讲Zookeeper结构体系。

关于Zookeeper所提供的服务，总的来说是为了解决分布式应用当中常常遇到的数据管理问题，比如说统一命名服务、配置管理、集群管理、分布式锁等。而从实际应用来说，Zookeeper的主要作用，集中在文件系统和监听通知机制上。

1、ZooKeeper的角色划分

一个ZooKeeper集群是由多个服务器组成，每个节点都有各自的角色，不同角色的节点在集群中负责不同的任务，作为一个整体对外提供稳定、可靠的服务。

Leader：

处理事务请求，更新系统状态；负责进行投票的发起和决议。

Follower：

处理客户端非事务请求并向客户端返回结果，将写事务请求转发给Leader；参与选举投票，并同步Leader的状态。

Observer：

接收客户端读请求，将客户端写请求转发给Leader；不参与投票过程，只同步Leader的状态；目的是为了扩展系统，提高读取速度。

Client：

请求发起方。

2、ZooKeeper选举

ZooKeeper的选举主要有两种场景——

集群初始化：部署ZooKeeper集群过程中，各个节点陆续加入集群，各个节点为争leader头衔进行投票选举。

集群运行中：ZooKeeper集群运行过程中，leader节点可能由于某个原因挂掉了，节点之间重新投票选举。

针对集群初始化阶段的选举

各个节点之间通过投票进行竞争，集群的每个节点收到投票后，会判断该投票的有效性（如检查是否是本轮投票、是否来自LOOKING状态的服务器）。

针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，优先检查ZXID。ZXID比较大的服务器优先作为Leader。如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。

一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。

针对集群运行过程中的选举

Zookeeper集群运行期间，一旦Leader服务器宕机，整个集群会暂停对外服务，进入新一轮Leader选举（过程和集群初始化阶段基本一致）。Leader宕机后，剩下的非Observer服务器将状态变更为LOOKING，然后开始投票，直至选出新的Leader。

3、Zookeeper的watch机制

Zookeeper的watch机制，是支撑配置管理、集群管理、分布式锁、发布/订阅等特性的基础。只要数据一发生变化，就会通知相应地注册了监听的客户端，从而实现数据的及时通知。

第1步：客户端注册Watcher到服务端；

第2步：注册成功，本地存储当前状态；

第3步：集群中所监控节点发生变化，服务端通知客户端数据变更；

第4步：客户端回调Watcher处理变更应对逻辑。

关于大数据入门，Zookeeper结构体系，以上就为大家做了详细的介绍了。理解和掌握Zookeeper的结构体系，对于后续的Zookeeper的进一步学习，也能起到很好的帮助作用。