集群特点
顺序一致性
客户端的更新顺序与它们被发送的顺序相一致
（针对同一个Follower A提交的写请求request1、request2，某些Follower虽然可能不能在请求提交成功后立即看到（也就是强一致性），但经过自身与Leader之间的同步后，这些Follower在看到这两个请求时，一定是先看到request1，然后再看到request2，两个请求之间不会乱序，即顺序一致性）
原子性
更新操作要么成功要么失败，没有第三种结果。
单一视图
无论客户端连接到哪一个服务器，客户端将看到相同的 ZooKeeper 视图。
可靠性
一旦一个更新操作被应用，那么在客户端再次更新它之前，它的值将不会改变。
实时性
连接上一个服务端数据修改，所以其他的服务端都会实时的跟新，不算完全的实时，有一点延时的
角色轮换避免单点故障
当leader出现问题的时候，会选举从follower中选举一个新的leader
集群中节点的角色分配
Leader 集群工作机制中的核心
事务请求（增，删，改）的唯一调度和处理者，保证集群事务处理的顺序性
集群内部个服务器的调度者(管理follower,数据同步)
Follower 集群工作机制中的跟随者
处理非事务请求，转发事务请求给Leader
参与事务请求proposal投票
参与leader选举投票
Observer 观察者
3.30以上版本提供，和follower功能相同，但不参与任何形式投票
处理非事务请求，转发事务请求给Leader
提高集群非事务处理能力
Zookeeper集群搭建
1、修改zoo.cfg文件添加以下配置
server.0=192.168.212.154:2888:3888
server.1=192.168.212.156:2888:3888
server.2=192.168.212.157:2888:3888
解释一下上面的配置
server.A=B:C:D其中A是一个数字,表示这个是第几号服务器,B是这个服务器的IP地址，C第一个端口用来集群成员的信息交换,表示这个服务器与集群中的leader服务器交换信息的端口，D是在leader挂掉时专门用来进行选举leader所用的端口
2、dataDir路径下创建myid文件
这个文件里面有一个数据就是A的值（该A就是zoo.cfg文件中server.A=B:C:D中的A）,在zoo.cfg文件中配置的dataDir路径中创建myid文件
ZAB一致性协议
zab协议核心是在整个zookeeper集群中只有一个节点既leader将所有客户端的写操作转化为事务（提议proposal）.leader节点再数据写完之后，将向所有的follower节点发送数据广播请求（数据复制），等所有的follower节点的反馈，在zab协议中，只要超过半数follower节点反馈ok,leader节点会向所有follower服务器发送commit消息，既将leader节点上的数据同步到follower节点之上。
Zab可以分成两部分。消息广播模式，崩溃恢复模式。
消息广播
广播模式需要保证 proposal 被按顺序处理，因此 zk 采用了递增的事务 id 号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了 zxid。
1、Leader 接收到消息请求后，将消息赋予一个全局唯一的 64 位自增 id，叫做：zxid，通过 zxid 的大小比较即可实现因果有序这一特性。
2、 Leader 通过先进先出队列(通过 TCP 协议来实现，以此实现了全局有序这一特性)将带有 zxid 的消息作为一个提案(proposal)分发给所有 follower。
3、当 follower 接收到 proposal，先将 proposal 写到硬盘，写硬盘成功后再向 leader 回一个 ACK。
4、当 leader 接收到合法数量的 ACKs 后，leader 就向所有 follower 发送 COMMIT 命令，会在本地执行该消息。
5、当 follower 收到消息的 COMMIT 命令时，就会执行该消息
与2pc相比：
二阶段提交的要求协调者必须等到所有的参与者全部反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题，但paxos和2pc没有这要求。
为了进一步防止阻塞，leader服务器与每个follower之间都有一个单独的队列进行收发消息，使用队列消息可以做到异步解耦。leader和follower之间只要往队列中发送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多
崩溃恢复
当 leader 崩溃或者 leader 失去大多数的 follower，这时候 zk 进入恢复模式，
zxid就是事务ID，最大的表示是最新的事务
1、每个Server会发出一个投票,第一次都是投自己。投票信息：（myid，ZXID）
2、收集来自各个服务器的投票
3、处理投票并重新投票，处理逻辑：优先比较ZXID,然后比较myid
4、统计投票，只要超过半数的机器接收到同样的投票信息，就可以确定leader
改变服务器状态
投票完成后，之前崩溃了的那台leader重启后不会成为leader