什么是Zookeeper
Zookeepr的定位：
Zookeeper是一个分布式协调服务框架，，为分布式系统提供高效稳健的分布式协调服务，我们要如何理解zookeeper的定位呢？我们知道，各个分布式系统都有自己独特的商标，zookeeper的如下图，这是一个理解zookeep的小方法，之后会详细解释zookeeper的基础概念。
它可以解决分布式环境常见的问题：
Zookeeper基础概念：
1.Zookeeper有一个根节点 /
2.每一个节点叫做znode
3.每个znode节点都可以有自己的子节点
4.Zookeeper的所有操作，都是基于节点路径来操作的
5.多个znode节点共同形成一个znode树（整个Zookeeper存储的目录结构）
6.每个Znode节点都可以存储数据，但是不超过1M
7.znode的节点路径是唯一的，基于这个特性，可以做集群的统一命名服务，用路径来标识一台服务器
8.znode是维系于内存中的，即znode节点的数据也是存在内存中，目的是供用户快速查询。
9.不能利用Zookeeper存储海量数据，一是Zookeeper的使用场景是做分布式协调服务，二是基于内存存储，多台zk节点存储的是同一数据。
10.Zookeeper也提供了持久化机制，持久化的目录：zoo.cfg中的dataDir来决定
11.Zookeeper会为每个事务分配一个全局递增事务id
cZxid：创建节点的事务id
mZxid：修改节点的事务id
pZxid：此节点的子节点最新的事务id
12.Zookeeper有四种类型：
a.create /park01 创建普通节点
b.create -e /park01 创建临时节点创建临时节点的客户端宕机（下线），它所创建的临时节点被删除，基于此特性，zookeeper可以管理集群中节点的服务状态。
c.create -s /park01 创建顺序节点
d.create -e -s /park01 创建临时顺序节点
Zookeeper选举机制
zookeeper的选举机制有两个阶段：
1.数据恢复阶段：每台zk服务器启动时，会从本地数据目录中，找到自己所拥有的最大事务id，即找到自己所拥有的最新事务。最大事务id：Zxid
2.选举阶段：每台zk服务器都会提交选举协议，推荐自己当leader。
选举协议(数据包)有以下内容：
a.自己拥有的最大事务id（Zxid）
b.自己的选举id（myid写的数字）
c.逻辑时钟值，作用是确保每台zk服务器在同一轮选举中
d.当前zk服务器的状态：
Looking 处于选举状态
Follower 处于追随者状态
Leader 处于领导者状态
Observer 处于观察者状态
3.zk主机竞选Leader的PK原则：
a.先比较Zxid，谁大谁当Leader，因为Zxid越大，事务越新。
b.如果Zxid比较不出来，就要比较选举id，谁大谁当leader。
注意：pk最基本的原则是要满足过半性。
Zookeeper的选举机制可以确保崩溃恢复，当leader挂掉后，如果集群数量满足过半性，就会从剩下的Follower选出新leader。
过半性的体现：
选举时要满足过半同意
zk服务集群要满足过半存活
搭建zk集群时最好使用奇数个主机
称为Leader的主机能做什么？
1.原子广播：确保所有的节点数据一致。即客户端节点无论从哪一台zk服务器读数据，数据都是一致的。
2.如果客户端发起的是事务请求，follower会将事务请求转交给leader，然后leader做原子广播确保数据一致性。
前面我们说道做原子广播是为了保持数据一致性，但它究竟是怎么做到数据一致的呢？我们来看两个关于保证数据一致性的算法。
保证数据一致性的算法
2PC算法：
2PC，是Two-Phase-Commit的缩写，即二阶段提交，是计算机网络尤其是在数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种算法。通常，二阶段提交协议被认为是一种一致性协议，用来保证分布式系统数据的一致性。目前，绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的，利用该协议能够非常方便完成所有分布式事务参与者的协调，统一决定事务的提交或回滚，从而能够有效保障分布式数据一致性，因此二阶段提交协议被广泛应用于许多分布式系统中。
2PC的优点：原理简单，实现方便。
2PC的缺点：同步阻塞，单点问题，脑裂，太过保守。
如果一个集群管理中，出现两个leader或多个leader，称为脑裂现象。
什么叫同步阻塞？
在二阶段提交的执行过程中，所有参加该事物操作的逻辑都处于阻塞状态，也就是说各个参与者在等待其他参与者响应的过程中，将无法执行其他任何操作。
什么叫单点问题？
在上图中，协调者可能挂掉，而且没有崩溃恢复机制。那么整个二阶段提交流程无法运转。
Paxos算法：
Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一，其解决的问题就是在分布式系统中如何就某个值（决议）达成一致。在常见的分布式系统中，总会发生诸如机器宕机或网络异常（包括消息的延迟、丢失、重复、乱序，还有网络分区）(也就是会发生异常的分布式系统)等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致。也可以理解成分布式系统中达成状态的一致性。
ZBA协议
1.概述：ZBA协议是分布式协调服务Zookeeper专门设计id一种支持崩溃恢复的原子广播协议，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。这个算法是一种类2PC算法，在2PC基础上做的改进
2.ZBA协议包括两种基本的模式，分别是：
消息原子广播(保证数据一致性)
崩溃恢复（解决2PC算法的单点问题）
3.协议流程（消息的原子广播）
a.有事务请求时，为此事务分配一个全局递增事务id，将事务写到本地事务log，由dataDir属性指定的目录，然后将事务广播出去。
b.Leader会为每一个follower生成一个对应的事务队列，由于是队列，满足FIFO原则，所以保证事务执行的顺序性。然后通过网络发送给follower。
c.然后follower执行发过来的事务，所谓的执行事务是指：将事务写到本地的事务log中，如果写入成功，即代表事务执行成功。
d.当follower执行成功后，向leader反馈yes信息。然后Leader接受各个follower反馈的事务执行状态，Zookeeper并没有像2PC算法等待所有的Follower的反馈，而是只要满足过半性，就发起事务的Commit。
e.当leader发出Commit请求后，Leader和Follower会做事务的提交，将服务器内存中的数据做改变，因为客户端是从zk服务器的内存中获取数据的。
Zookeeper的事务log
事务日志指zookeeper系统在正常运行过程中，针对所有的事务操作，而返回客户端“事务成功”的响应前，zookeeper会保证已经将本次更新操作的事务日志写在磁盘上。
zookeeper的事务日志为二进制文件不能通过vim等工具访问，可以通过zookeeper自带的jar包读取事务日志文件
查看事物log的命令：
java -classpath :slf4j-api-1.6.1.jar:zookeeper-3.4.6.jarorg.apache.zookeeper.server.LogFormatter ./log.000000001
这个./log.00000001是具体要查看的事务文件名，不同情况要做改变。
查看快照文件：
java -classpath :slf4j-api-1.6.1.jar:zookeeper-3.4.6.jarorg.apache.zookeeper.server.SnapshotFormatter ./snapshot.200000000
这个 ./snapshot.200000000 也是具体的文件。
Zookeeper观察者
虽然客户端直接连接到投票选举的zookeeper成员执行良好，但这个架构很难扩大到大量的客户端。问题就是我们添加了更多的投票成员，写入性能下降。这是由于这样的事实：一个写入操作要求共识协议至少是整体的一半，因此投票的成本随着投票者越多会显著增加。
我们引入一个新节点类型叫做observer（观察者），观察者不参与投票，它只监听投票的结果。除了这个简单的区别，观察者和follower一样运行，客户端可以连接他们且发送读取和写入请求。观察者像follower一样转发这些请求到Leader，而他们只是简单的等待监听投票结果。正因为如此，我们可以尽可能多的增加观察者的数量，而不影响投票的性能。
观察者还有其他优势，因为他们不投票，不是zookeeper整体的主要组件。因此他们可以故障，或者从集群中断开连接，而不影响zookeeper服务的可用性。
