zookeeper（学习笔记）

一. ZooKeeper是什么
ZooKeeper由雅虎研究院开发，是Google Chubby的开源实现，后来托管到Apache，于2010年11月正式成为Apache的顶级项目。 
ZooKeeper是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。 
分布式应用程序可以基于ZooKeeper实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁、分布式队列等功能。

二、ZooKeeper五大特性
ZooKeeper一般以集群的方式对外提供服务，一个集群包含多个节点，每个节点对应一台ZooKeeper服务器，所有的节点共同对外提供服务，整个集群环境对分布式数据一致性提供了全面的支持，具体包括以下五大特性：

3.1 顺序一致性
从同一个客户端发起的请求，最终将会严格按照其发送顺序进入ZooKeeper中

3.2 原子性
所有请求的响应结果在整个分布式集群环境中具备原子性，即要么整个集群中所有机器都成功的处理了某个请求，要么就都没有处理，绝对不会出现集群中一部分机器处理了某一个请求，而另一部分机器却没有处理的情况

3.3 单一性
无论客户端连接到ZooKeeper集群中哪个服务器，每个客户端所看到的服务端模型都是一致的，不可能出现两种不同的数据状态，因为ZooKeeper集群中每台服务器之间会进行数据同步

3.4 可靠性
一旦服务端数据的状态发送了变化，就会立即存储起来，除非此时有另一个请求对其进行了变更，否则数据一定是可靠的

3.5 实时性
当某个请求被成功处理后，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能从服务端上读取到最新的数据状态，即ZooKeeper保证数据的最终一致性

zookeeper：

 

 

服务注册与发现：

 

 

集群崩溃与恢复：

Zookeeper-集群崩溃恢复

1. zookeeper 的一致性，为了防止单机挂掉，zookeeper维护了一个集群，实现自身的高可用

1.1 Zookeeper 集群是一主多从结构

1.2 在更新数据时，首先更新到主节点（这里的节点时指服务器，不是Znode），再同步到从节点。

1.3 再读取数据时，直接读取任意从节点

1.4 为了保证主从节点的数据一致性，Zookeeper采用了ZAB协议，这种协议非常类似于一致性算法 Paxos和Raft.

2. 什么是ZAB？

2.1 Zookeeper Automic Broadcast,有效的解决了Zookeeper集群崩溃恢复，以及主从同步数据的问题。

2.2 ZAB协议定义的三种节点状态

Looking-选举状态

Following-从节点

Leader-主节点

2.3 最大ZXID：节点本地的最新事务编码，包含epoch和计数两部分。

2.4 ZAB的崩溃恢复

　　假如Zookeeper 当前的主节点挂掉了，集群会进行崩溃恢复，分三个阶段：

2.4.1 Leader election 选举状态。此时集群中的节点处于Looking状态，向其他节点发起投票，投票当中包含自己的服务器ID和最新的事务ID（ZXID)

　　接下来，节点会用自身的ZXID和从其他节点接收到的ZXID做比较，如果发现别人家的ZXID比自己的大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的ZXID所属节点。

　　每次投票后，服务器都会统计投票数量，判断是否有某个节点但得到半数以上的投票，如果存在这样的节点，该节点将会成为准Leader，状态变为Leader,其他系欸但状态变为Following。

2.4.2 Discover 发现阶段，用于从节点中发现最新的ZXID和事务日志，问：既然Leader被选为主节点，已经是集群里最新数据了，为什么还要从节点中寻找最新事务呢？

　　这是为了防止某些意外情况，比如因网络原因再上一阶段产生多个Leader的情况。

　　所以该阶段。Leader接受所有Follower发来的各自最新的epoch值，Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。

各个Follower收到全新的epoch后，返回ACK给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。

2.4.3 Sysnchronization 同步阶段，把Leader 刚才收集得到的最新历史事务日志，同步给集群中所有的Follower，只有当半数Follower同步成功，这个准Leader才能成为正式的Leader，故障恢复正式完成。

2.5 ZAB数据写入

2.5.1 Broadcast，Zookeeper常规情况下更新数据的时候，由Leader广播所有的Follower，其过程如下：

　　1. 客户端发出写入的数据请求给任意Follower

　　2. Follower把写入数据请求转发给Leader

　　3. Leader采用二阶段提交方式，先发送Propose广播给Follower

　　4. Follower接收到Propose消息，写入日志成功后，返回ACK消息给Leader。

　　5. Leader接到半数以上ACK消息，返回成功给客户端，并且广播Commit请求给Follower