分布式协调组件Zookeeper之选举机制与ZAB协议

Zookeeper简介：

Zookeeper是什么：

　　Zookeeper 是⼀个分布式协调服务的开源框架。主要⽤来解决分布式集群中应⽤系统的⼀致性问题，例如怎样避免同时操作同⼀数据造成脏读的问题。分布式系统中数据存在⼀致性的问题！！

ZooKeeper 本质上是⼀个分布式的⼩⽂件存储系统。提供基于类似于⽂件系统的⽬录树⽅式的数据存储，并且可以对树中的节点进⾏有效管理。
ZooKeeper 提供给客户端监控存储在zk内部数据的功能，从⽽可以达到基于数据的集群管理。诸如：统⼀命名服务(dubbo)、分布式配置管理(solr的配置集中管理)、分布式消息队列（sub/pub）、分布式锁、分布式协调等功能。

架构组成：

Leader

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

Follower

处理客户端⾮事务（读操作）请求，
转发事务请求给 Leader；
参与集群 Leader 选举投票 2n-1台可以做集群投票。

此外，针对访问量⽐较⼤的 zookeeper 集群，还可新增观察者⻆⾊。

Observer

观察者⻆⾊，观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于⾮事务请求可以进⾏独⽴处理，对于事务请求，则会转发给 Leader服务器进⾏处理。
不会参与任何形式的投票只提供⾮事务服务，通常⽤于在不影响集群事务处理能⼒的前提下提升集群的⾮事务处理能⼒。增加了集群增加并发的读请求

ZK也是Master/slave架构，但是与之前不同的是zk集群中的Leader不是指定⽽来，⽽是通过选举产⽣。

Zookeeper 特点：

1.Zookeeper：⼀个领导者（leader:⽼⼤），多个跟随者（follower:⼩弟）组成的集群。
2. Leader负责进⾏投票的发起和决议，更新系统状态(内部原理)
3. Follower⽤于接收客户请求并向客户端返回结果，在选举Leader过程中参与投票
4. 集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。
5. 全局数据⼀致：每个server保存⼀份相同的数据副本，Client⽆论连接到哪个server，数据都是⼀致的。
6. 更新请求顺序进⾏(内部原理)
7. 数据更新原⼦性，⼀次数据更新要么成功，要么失败

Zookeeper 节点之 ZNode 类型：

Zookeeper 节点类型可以分为三⼤类：

持久性节点（Persistent）
临时性节点（Ephemeral）
顺序性节点（Sequential）

在开发中在创建节点的时候通过组合可以⽣成以下四种节点类型：持久节点、持久顺序节点、临时节点、临时顺序节点。不同类型的节点则会有不同的⽣命周期

持久节点：是Zookeeper中最常⻅的⼀种节点类型，所谓持久节点，就是指节点被创建后会⼀直存在服务器，直到删除操作主动清除

持久顺序节点：就是有顺序的持久节点，节点特性和持久节点是⼀样的，只是额外特性表现在顺序上。顺序特性实质是在创建节点的时候，会在节点名后⾯加上⼀个数字后缀，来表示其顺序。

临时节点：就是会被⾃动清理掉的节点，它的⽣命周期和客户端会话绑在⼀起，客户端会话结束，节点会被删除掉。与持久性节点不同的是，临时节点不能创建⼦节点。

临时顺序节点：就是有顺序的临时节点，和持久顺序节点相同，在其创建的时候会在名字后⾯加上数字后缀

事务ID：

　　在ZooKeeper中，事务是指能够改变ZooKeeper服务器状态的操作，我们也称之为事务操作或更新操作，⼀般包括数据节点创建与删除、数据节点内容更新等操作。对于每⼀个事务请求，ZooKeeper都会为其分配⼀个全局唯⼀的事务ID，⽤ ZXID 来表示，通常是⼀个 64 位的数字。每⼀个 ZXID 对应⼀次更新操作，从这些ZXID中可以间接地识别出ZooKeeper处理这些更新操作请求的全局顺序 zk中的事务指的是对zk服务器状态改变的操作(create,update data,更新字节点)；zk对这些事务操作都会编号，这个编号是⾃增⻓的被称为ZXID。

ZNode 的状态信息：

#使⽤bin/zkCli.sh 连接到zk集群

[zk: localhost:2181(CONNECTED) 2] get /zookeeper

cZxid = 0x0

ctime = Wed Dec 31 19:00:00 EST 1969

mZxid = 0x0

mtime = Wed Dec 31 19:00:00 EST 1969

pZxid = 0x0

cversion = -1

dataVersion = 0

aclVersion = 0

ephemeralOwner = 0x0

dataLength = 0

numChildren = 1

含义：

 cZxid 就是 Create ZXID，表示节点被创建时的事务ID。

 ctime 就是 Create Time，表示节点创建时间。

 mZxid 就是 Modified ZXID，表示节点最后⼀次被修改时的事务ID。

 mtime 就是 Modified Time，表示节点最后⼀次被修改的时间。

 pZxid 表示该节点的⼦节点列表最后⼀次被修改时的事务 ID。只有⼦节点列表变更才会更新 pZxid，

⼦节点内容变更不会更新。

 cversion 表示⼦节点的版本号。

 dataVersion 表示内容版本号。

 aclVersion 标识acl版本

 ephemeralOwner 表示创建该临时节点时的会话 sessionID，如果是持久性节点那么值为 0

 dataLength 表示数据⻓度。

 numChildren 表示直系⼦节点数。

Watcher 机制：

　　在 ZooKeeper 中，引⼊了 Watcher 机制来实现这种分布式的通知功能。ZooKeeper 允许客户端向服务端注册⼀个 Watcher 监听，当服务端的⼀些指定事件触发了这个 Watcher，那么Zk就会向指定客户端发送⼀个事件通知来实现分布式的通知功能。

Zookeeper的Watcher机制主要包括客户端线程、客户端WatcherManager、Zookeeper服务器三部分。

具体⼯作流程为：

客户端在向Zookeeper服务器注册的同时，会将Watcher对象存储在客户端的WatcherManager当中
当Zookeeper服务器触发Watcher事件后，会向客户端发送通知
客户端线程从WatcherManager中取出对应的Watcher对象来执⾏回调逻辑

注：客户端负责watch的注册和回调，zk服务器负责处理watch。

命令行使用：

　  创建顺序节点：create -s /zk-test 123

　　创建临时节点：create -e /zk-temp 123

　　创建永久节点：create /zk-permanent 123

　　读取节点：ls path   其中，path表示的是指定数据节点的节点路径

　　获取内容：get path

　　更新节点：set path data

　　删除节点： delete path

JAVA 操作Zookeeper：

<dependency>

 <groupId>org.apache.zookeeper</groupId>

 <artifactId>zookeeper</artifactId>

 <version>3.4.14</version>

</dependency>

<dependency>

 <groupId>com.101tec</groupId>

 <artifactId>zkclient</artifactId>

 <version>0.2</version>

 </dependency>

创建会话：

package com.hust.grid.leesf.zkclient.examples;

import java.io.IOException;

import org.I0Itec.zkclient.ZkClient;

public class CreateSession {

/*

 创建⼀个zkClient实例来进⾏连接

 */

 public static void main(String[] args) {

 　　ZkClient zkClient = new ZkClient("127.0.0.1:2181");

　　 System.out.println("ZooKeeper session created.");

 }

}

创建节点：

package com.hust.grid.leesf.zkclient.examples;

import org.I0Itec.zkclient.ZkClient;

public class Create_Node_Sample {

 public static void main(String[] args) {

 ZkClient zkClient = new ZkClient("127.0.0.1:2181");

 System.out.println("ZooKeeper session established.");

 //createParents的值设置为true，可以递归创建节点

 zkClient.createPersistent("/lg-zkClient/lg-c1",true);

 System.out.println("success create znode.");

 }

}

删除节点：

package com.hust.grid.leesf.zkclient.examples;

import org.I0Itec.zkclient.ZkClient;

public class Del_Data_Sample {

 public static void main(String[] args) throws Exception {

 String path = "/lg-zkClient/lg-c1";

 ZkClient zkClient = new ZkClient("127.0.0.1:2181", 5000);

 zkClient.deleteRecursive(path);

 System.out.println("success delete znode.");

 }

}

监听节点变化：

import org.I0Itec.zkclient.IZkChildListener;

import org.I0Itec.zkclient.ZkClient;

import org.apache.zookeeper.client.ZooKeeperSaslClient;

import java.util.List;

/*

演示zkClient如何使⽤监听器

*/

public class Get_Child_Change {

 public static void main(String[] args) throws InterruptedException {

 //获取到zkClient

 final ZkClient zkClient = new ZkClient("linux121:2181");

 //zkClient对指定⽬录进⾏监听(不存在⽬录:/lg-client)，指定收到通知之后的逻辑

 //对/lag-client注册了监听器，监听器是⼀直监听

 zkClient.subscribeChildChanges("/lg-client", new IZkChildListener() {

 //该⽅法是接收到通知之后的执⾏逻辑定义

 public void handleChildChange(String path, List<String> childs)

throws Exception {

 //打印节点信息

 System.out.println(path + " childs changes ,current childs " +

childs);

 }

 });

 //使⽤zkClient创建节点，删除节点，验证监听器是否运⾏

 zkClient.createPersistent("/lg-client");

 Thread.sleep(1000); //只是为了⽅便观察结果数据

 zkClient.createPersistent("/lg-client/c1");

 Thread.sleep(1000);

 zkClient.delete("/lg-client/c1");

 Thread.sleep(1000);

 zkClient.delete("/lg-client");

 Thread.sleep(Integer.MAX_VALUE);

 /*

 1 监听器可以对不存在的⽬录进⾏监听

 2 监听⽬录下⼦节点发⽣改变，可以接收到通知，携带数据有⼦节点列表

 3 监听⽬录创建和删除本身也会被监听到

 */

 }

}

执行结果：

/lg-zkClient 's child changed, currentChilds:[]

/lg-zkClient 's child changed, currentChilds:[c1]

/lg-zkClient 's child changed, currentChilds:[]

/lg-zkClient 's child changed, currentChilds:null

注：

客户端可以对⼀个不存在的节点进⾏⼦节点变更的监听。
⼀旦客户端对⼀个节点注册了⼦节点列表变更监听之后，那么当该节点的⼦节点列表发⽣变更时，服务端都会通知客户端，并将最新的⼦节点列表发送给客户端　
该节点本身的创建或删除也会通知到客户端。

监听节点数据变化：

import org.I0Itec.zkclient.IZkDataListener;

import org.I0Itec.zkclient.ZkClient;

//使⽤监听器监听节点数据的变化

public class Get_Data_Change {

 public static void main(String[] args) throws InterruptedException {

 // 获取zkClient对象

 final ZkClient zkClient = new ZkClient("linux121:2181");

 //设置⾃定义的序列化类型,否则会报错！！

 zkClient.setZkSerializer(new ZkStrSerializer());

 //判断节点是否存在，不存在创建节点并赋值

 final boolean exists = zkClient.exists("/lg-client1");

 if (!exists) {

 zkClient.createEphemeral("/lg-client1", "123");

 }

 //注册监听器，节点数据改变的类型，接收通知后的处理逻辑定义

 zkClient.subscribeDataChanges("/lg-client1", new IZkDataListener() {

 public void handleDataChange(String path, Object data) throws

Exception {

 //定义接收通知之后的处理逻辑

 System.out.println(path + " data is changed ,new data " +

data);

 }

 //数据删除--》节点删除

 public void handleDataDeleted(String path) throws Exception {

 System.out.println(path + " is deleted!!");

 }

 });

 //更新节点的数据，删除节点，验证监听器是否正常运⾏

 final Object o = zkClient.readData("/lg-client1");

 System.out.println(o);

 zkClient.writeData("/lg-client1", "new data");

 Thread.sleep(1000);

 //删除节点

 zkClient.delete("/lg-client1");

 Thread.sleep(Integer.MAX_VALUE);

 }

}

zk 自定义字符串序列化：

import org.I0Itec.zkclient.exception.ZkMarshallingError;

import org.I0Itec.zkclient.serialize.ZkSerializer;

public class ZkStrSerializer implements ZkSerializer {

 //序列化，数据--》byte[]

 public byte[] serialize(Object o) throws ZkMarshallingError {

　　return String.valueOf(o).getBytes();

 }

 //反序列化，byte[]--->数据

 public Object deserialize(byte[] bytes) throws ZkMarshallingError {

 return new String(bytes);

 }

}

Leader选举：

选举机制：

半数机制：集群中半数以上机器存活，集群可⽤。所以Zookeeper适合安装奇数台服务器。
Zookeeper虽然在配置⽂件中并没有指定Master和Slave。但是，Zookeeper⼯作时，是有⼀个节点为Leader，其它为Follower，Leader是通过内部的选举机制产⽣的。
只有当机器减少或集群初次启动才会选举leader。

详细步骤：

（1）服务器1启动，此时只有它⼀台服务器启动了，它发出去的报⽂没有任何响应，所以它的选举状态⼀直是LOOKING状态。
（2）服务器2启动，它与最开始启动的服务器1进⾏通信，互相交换⾃⼰的选举结果，由于两者都没有历史数据，所以id值较⼤的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例⼦中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。 return String.valueOf(o).getBytes(); } //反序列化，byte[]--->数据 public Object deserialize(byte[] bytes) throws ZkMarshallingError { return new String(bytes); } } 123 /lg-client1 data is changed ,new data new data /lg-client1 is deleted!!
（3）服务器3启动，根据前⾯的理论分析，服务器3成为服务器1、2、3中的⽼⼤，⽽与上⾯不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。
（4）服务器4启动，根据前⾯的分析，理论上服务器4应该是服务器1、2、3、4中最⼤的，但是由于前⾯已经有半数以上的服务器选举了服务器3，所以它只能接收当⼩弟的命了。
（5）服务器5启动，同4⼀样称为follower

集群首次启动：

　　半数前选myid 最大的机器。

非首次启动：

　　优先选择zxid值⼤的节点称为Leader!!

ZAB⼀致性协议：

　　ZAB 协议是为分布式协调服务 Zookeeper 专⻔设计的⼀种⽀持崩溃恢复和原⼦⼴播协议

原子广播：

具体流程：

总结：第一步发送提议，如果提议获得半数以上机器的ack，然后发送commit给follower，同时自己commit。

崩溃恢复：

Leader宕机后，被选举的新Leader需要解决的问题：

ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。

选举算法的关键点：保证选举出的新Leader拥有集群中所有节点最⼤编号(ZXID)的事务!!

总结：leader崩溃，新的leader必须拥有最大的事务id，这样才能保证数据最新。