大数据生态之zookeeper（原理）

1. 集群的角色描述：

角色	描述
领导者（leader）	领导者负责进行公布决议，主要处理写请求
跟随者（follower）	Follower用于接收客户端请求并向客户端返回结果（只能处理读请求，如果接收到写请求，将写请求转发给leader），当leader宕机时，发起选主，有投票和被投票权
观察者（observer）	Observer可以接收客户端连接，将写请求转发给leader节点，帮助follower减轻读的压力。但Observer不参加选举和被选举。Observer的目录是为了扩展系统，提高读取速度
客户端	请求发起方

2. zookeeper的选主过程

（1）全新集群的选主：

根据启动的顺序和id进行选主（过半机制：集群中超过半数的集群可使用时，才开始选主）

以hadoop01（id=1）—hadoop02（id=2）---hadoop03（id=3）----hadoop04（id=r）----hadoop05（id=5）为例：

当hadoop01启动时，此时只有它一台服务器，，他发出取的报告没有任何相应，所有它的选举一直是looking状态。
Hadoop02启动：它与最开始启动的hadoop01进行通信，相互交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器胜出，但是由于没有达到超过半数以上的服务器同意选举它（这个例子中的半数以上是 3），所有hadoop01、hadoop02还是继续保持looking状态。
Hadoop03启动，根据前面的分析，服务器 3 成为服务器 1,2,3 中的老大，而与上面不同的是，此时有三台服务器(超过半数)选举了它，所Hadoop03它成为了这次选举的 leader
服hadoop04启动，根据上面的分析，理论上，hadoop04应该是服务器中id最大的，但是由前面已近有超过半数的服务器选举了hadoop03，所以hadoop04只能是follower
Hadoop05启动，与hadoop04一样，也是follower

zookeeper server的三种工作状态：

（2）非全新集群的选主

leader 已经选举出来，当前 Server 与之同步，服从 leader 的命令，但是由于某种原因主节点宕机：

此时我们根据三个维度来选主：数据version、serverid、逻辑时钟。

数据version：数据新的version就大，数据每次更新，同时会更新它的version
Serverid：就是我们配置的 myid 中的值，每个机器一个
逻辑时钟：这个值从0开始，每一次选举对应一个值，也就是说，如果在同一次选举中，这个值应该一致，逻辑时钟越大，说明这一次选举leader人的进程更新，也就是每次选举拥有一个 zxid，投票结果只取 zxid 最新的

选举的标准：

根据以上的规则，快速选出集群的主节点。

3. zookeeper写数据的流程：

4. zookeeper的数据的同步过程

follower连接leader并发送自己最大的zixd
leader进行对比，将自己最大的zxid和follower发送过来的zxid进行对比，如果leader的zxid大于follower的，则通知follower进行数据同步
follower发送数据同步请求
leader确定当前的follower的数据同步点（从follower最大的zxid到leader最大的zxid之间数据需要同步）
follower开始同步数据，这个过程不对外提供读写服务。
follower同步完成，发送消息给leader
leader就会修改当前的follower的状态为update，这个时候follower就可以接受客户端的读写请求，但是只能读，如果是写入请求，需要转发给leader

5. ZooKeeper 中各个角色的工作职责

（1）Leader

（2）follower