zookeeper的各个复制集节点（follower，leader，observer）都包含了集群所有的数据且存在内存中，像个内存数据库。更新操作会以日志的形式记录到磁盘以保证可恢复性，并且写入操作会在写入内存数据库之前序列化到磁盘。
每个ZooKeeper服务器都为客户端服务。客户端只连接到一台服务器以提交请求。读取请求由每个服务器数据库的本地副本提供服务。更改服务状态，写请求的请求由zab协议处理。
作为协议协议的一部分，来自客户端的所有写入请求都被转发到称为leader的单个服务器。其余的ZooKeeper服务器（称为followers）接收来自领导者leader的消息提议并同意消息传递。消息传递层负责替换失败的leader并将followers与leader同步。
ZooKeeper使用自定义原子消息传递协议zab。由于消息传递层是原子的，当领导者收到写入请求时，它会计算应用写入时系统的状态，并将其转换为捕获此新状态的事务。
6.zookeeper的CAP原则cap原则是指作为一个分布式系统，一致性，可用性，分区容错性这三个方面，最多只能任意选择两种。就是必定会要有取舍。
一致性C
Zookeeper是强一致性系统，同步数据很快。但是在不用sync()操作的前提下无法保证各节点的数据完全一致。zookeeper为了保证一致性使用了基于paxos协议且为zookeeper量身定做的zab协议。这两个协议是什么东西之后的文章会讲。
可用性A（高可用性和响应能力）
Zookeeper数据存储在内存中，且各个节点都可以相应读请求，具有好的响应性能。Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的。
分区容忍性P
有2点需要分析的
节点多了会导致写数据延时非常大（需要半数以上follower写完提交）,因为需要多个节点同步.
节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入 observer节点缓解这个问题.
zk在CAP问题上做的取舍严格地意义来讲zk把取舍这个问题抛给了开发者即用户。
为了协调CA（一致性和可用性），用户可以自己选择是否使用Sync()操作。使用则保证所有节点强一致，但是这个操作同步数据会有一定的延迟时间。反过来若不是必须保证强一致性的场景，可不使用sync，虽然zookeeper同步的数据很快，但是此时是没有办法保证各个节点的数据一定是一致的，这一点用户要注意。实际的开发中就要开发者根据实际场景来做取舍了，看更关注一致性还是可用性。
为了协调AP（一致性和扩展性），用户可以自己选择是否添加obsever以及添加个数，observer是3.3.0 以后版本新增角色，它不会参加选举和投票过程，目的就是提高集群扩展性。因为follower的数量不能过多，follower需要参加选举和投票，过多的话选举的收敛速度会非常慢，写数据时的投票过程也会很久。observer的增加可以提高可用性和扩展性，集群可接受client请求的点多了，可用性自然会提高，但是一致性的问题依然存在，这时又回到了上面CA的取舍问题上。
7.zookeeper的选主机制FastLeaderElection原理
myid
每个Zookeeper服务器，都需要在数据文件夹下创建一个名为myid的文件，该文件包含整个Zookeeper集群唯一的ID（整数）。例如某Zookeeper集群包含三台服务器，hostname分别为zoo1、zoo2和zoo3，其myid分别为1、2和3，则在配置文件中其ID与hostname必须一一对应，如下所示。在该配置文件中，server.后面的数据即为myid
server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888zxid
类似于RDBMS中的事务ID，用于标识一次更新操作的Proposal ID。为了保证顺序性，该zkid必须单调递增。因此Zookeeper使用一个64位的数来表示，高32位是Leader的epoch，从1开始，每次选出新的Leader，epoch加一。低32位为该epoch内的序号，每次epoch变化，都将低32位的序号重置。这样保证了zkid的全局递增性。
7.1.支持的领导选举算法