简述ZAB协议以及zookeeper

zookeeper为分布式应用提供了一个高效可靠的分布式协调服务，实现依赖于ZAB协议，实现了一种主备模式的架构来保持集群中数据的一致性。zookeeper使得分布式应用通过一个共享的树形结构的命名空间实现协调。zookeeper将所有的数据存储在内存中。zookeeper集群中的任何一台机器都可以响应客户端的读操作，且全量数据存在于内存中，因此zookeeper更适合以读操作为主的应用场景。
集群中包括三种角色：leader、follower、observer。其中leader是通过选举确定的一台机器，为客户端提供读写功能。follower与observer提供读功能，不同的是observer不参与选举，也不参与过半写成功策略，因此observer可以在不影响写性能的前提下提升机群的读性能。zookeeper集群节点的数量为奇数个，节点分为临时节点、持久节点和顺序节点，每个节点有一个stat结构，最重要的功能是watcher功能。开源客户端有：zkclient, curator。
ZAB协议：是为zookeeper专门设计的一种支持崩溃恢复的消息广播协议。ZAB协议只允许有一个主进程接收客户事务请求并处理，即leader。当leader收到请求后，将请求事务放入响应队列，保证事务的顺序性。之后会在队列中顺序向其他节点广播该提案，follower收到后会将其以事务的形式写入到本地日志中，并向leader发送反馈ack。leader会等待其他follower的回复，当收到一半以上的follower响应时，leader会向其他节点发送commit消息，同时leader提交提案。
ZAB有两种模式：故障恢复模式以及消息广播模式。当系统启动或者leader服务器出现故障灯现象时，进入故障恢复模式。将会开启新的一轮选举。选举产生的leader会与过半的follower进行同步，使数据一致。当同步结束后，退出恢复模式，进入消息广播模式。当一台遵循ZAB协议的服务器启动后，如果检测到有leader在广播消息，会自动进入恢复模式，当其完成与leader的同步以后，进入消息广播模式。如果集群中的非leader节点收到客户请求，非leader节点会先将请求发送到leader服务器。
故障恢复如下：
ZAB协议需要保证已经被leader提交的事务最终被所有的机器提交，并且丢弃那些只在leader上提出的事务。为了保证这两点，选举的时候选择ZXID最大的节点可以解决上述问题。数据同步使为每一个follower创建一个队列，leader将各个follower没有提交的事务写入各个队列，并发送给各个follower，follower将事务同步后leader将其加入真正可用的follower列表。
leader重新选举的条件：leader宕机或发生故障，集群中少于一半的节点与当前leader保持连接。