Zookeeper工作原理

​

ZooKeeper的工作原理

选举制度说明

ZooKeeper是一个分布式协调服务，但本身也是一个集群，并且是一个主从架构的集群。与HDFS类似的是，这个集群中也是需要一个主节点和若干个从节点的，但是与HDFS不同的是，ZooKeeper集群的主节点并不是我们通过配置文件设置的，而是所有的节点启动之后自己选举出来的！

ZooKeeper集群中节点的角色状态: Leader 和 Follower

选举中的几个概念

• Leader

  Zookeeper 集群工作的核心。

  事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务器的调度者。
  对于 create， setData， delete 等有写操作的请求，需要统一转发给leader 处理， leader 需要决定编号、执行操作，这个过程称为一个事务。

• Follower

  • 处理客户端非事务（读操作）请求，转发事务请求给 Leader；
  • 参与集群 Leader 选举投票 2n-1台可以做集群投票。
  • 此外，针对访问量比较大的 zookeeper 集群， 还可新增观察者角色。

• Observer

  • 观察者角色，观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给 Leader服务器进行处理。
  • 不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

• 投票相关

  • myid

    我们在搭建ZooKeeper集群的时候设置过的服务器的ID值，这个值在选举的投票过程中有一定的权重占比。

  • zxid

    事务ID，ZooKeeper会为每一个更新的操作分配一个事务ID。事务ID是一个64位的数字，且全局单调递增。
    在一个节点的状态信息中会看到这个值。

  • Epoch

    逻辑时钟。

    • 在进行选举的时候，epoch > zxid > myid

• 状态相关

  • LOOKING: 竞选状态
  • FOLLOWING: 随从状态，同步leader状态，参与选票
  • OBSERVING: 观察状态，同步leader状态，不参与选票
  • LEADING: 领导状态

选举发生的时机

• 启动ZooKeeper集群的时候
• 集群运行过程中，Leader失联

启动集群选举

我们以3个节点的ZooKeeper集群为例，启动的顺序是qianfeng01, qianfeng02, qianfeng03

1. qianfeng01启动，投自己一票。由于未满足过半的条件，进入到LOOKING状态。
2. qianfeng02启动，投自己一票。现在活跃的节点已经过半，归票:
   • 优先比较Epoch，谁的大，谁当选Leader
   • 如果Epoch相同，比较zxid，谁的大，谁当选Leader
   • 如果zxid也相同，比较myid，谁的大，谁当选Leader
3. qianfeng03启动，由于集群中已经出现了Leader，因此qianfeng03直接进入FOLLOWING状态，成为Follower。

集群运行中

集群在运行的过程中，Leader失联了。例如: 集群启动之后，qianfeng02当选为Leader，先在已经失联…

• qianfeng01、qianfeng03会进入到LOOKING状态，开始投票，并每人都给自己投了一票。
• 归票:
  • 优先比较Epoch，谁的大，谁当选Leader
  • 如果Epoch相同，比较zxid，谁的大，谁当选Leader
  • 如果zxid也相同，比较myid，谁的大，谁当选Leader

监听原理

​

图解

1. 首先要有一个main()线程
2. 在main线程中创建Zookeeper客户端， 这时就会创建两个线程， 一个负责网络连接通信(connet),一个负责监听(listener)。
3. 通过connect线程将注册的监听事件发送给Zookeeper。
4. 在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。
5. Zookeeper监听到有数据或路径变化， 就会将这个消息发送给listener线程。
6. listener线程内部调用了process（） 方法。

用途

1. 监听节点数据的变化: get /path watch
2. 监听子节点增减的变化 : ls /path watch

写数据流程

​

1. Client向Zookeeper的server1上写数据，发送一个写请求
2. 如果server1不是leader,那么server1会把请求进一步转发给leader。
3. 这个leader会将写请求广播给所有server。
4. 各个Server写成功后就会通知leader。
5. 当leader收到半数以上的server写成功的通知，就说明数据写成功了。写成功后，leader会告诉server1数据写成功了。
6. server1会进一步通知Client数据写成功了。这时就认为整个写操作成功。

也可以观看大数据相关视频：

千锋大数据Hadoop全新增强版-先导片