Zookeeper
Zookeeper是一个高性能分布式应用协调服务
》Naming Service
》配置管理
》Leader Election
》服务发现
》同步
》Group Service
》Barrier
》分布式队列(其实zookeeper并不适合作为分布式队列，性能不高只不过在特定场合可以)
》两阶段提交
Zookeeper工作方式
》Zookeeper集群包含一个1个Leader，多个Follower
》所有的Follower都可提供读服务
》所有的写操作都会被forward到Leader
》Client与Server通过NIO通信
》全局串行化所有的写操作
》保证同一客户端的指令被FIFO执行
》保证消息通知的FIFO
与Kafka读写操作不一样，Kafka只有Leader提供读写操作。
Zab协议-广播模式
客户端每发送一个更新请求，ZooKeeper都会生成一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，这个唯一编号就是事务ID(ZXID)，只有更新请求才算是事务请求。
为保证按照事务的ZXID先后顺序来处理，Leader服务器会分别为每个Follower服务器创建一个队列，并将事务的先后顺序放入队列中，并按照FIFO的策略进行消息发送。收到需要处理的事务后，Follower服务器会首先以事务日志的形式写入服务器的磁盘中，写入成功后会向Leader服务器发送ACK响应。当Leader服务器收到超过一半的Follower服务器的ACK响应后，会向所有Follower服务器广播Commit消息，收到Commit消息的Follower服务器也会完成对事务的提交。
如果接收到事务请求的是Follower服务器，它会将请求转发给Leader服务器处理。
Zab协议-恢复模式
进入恢复模式：当Leader宕机或者丢失大多数Follower后，即进入恢复模式
结束恢复模式：新领导被选举出来，且大多数Follower完成了与Leader的状态同步后，恢复模式即结束，从而进入广播模式
恢复模式的意义
》发现集群中被commit的proposal的最大zxid
》建立新的epoch，从而保证之前的Leader不能再commit新的proposal
》集群中大部分节点都commit过前一个Leader commit过的信息，而新的Leader是被大部分节点所支持的，所以被之前Leader commit过的Proposal不会丢失，至少被一个节点所保存
》新Leader会与所有Follower通信，从而保证大部分节点都拥有最新的数据
Zookeeper一致性保证
顺序一致性：从一个客户端发出的更新操作会发送顺序被顺序执行
原子性：更新操作要么成功要么失败，无中间状态
单一系统镜像：一个客户端只会看到同一个view，无论它连到哪台服务器
可靠性：
》一旦一个更新被应用，该更新将被持久化，直到有客户端更新该结果
》如果一个客户端得到更新成功的状态码，则该更新一定生效
》任何一个被客户端通过读或者更新“看到”的结果，将不会被回滚，即使是从失败中恢复
实时性：保证客户端可在一定时间（通常是几十秒）内看到最新的视图
Zookeeper使用注意事项
》只保证同一客户端的单一系统镜像，并不保证多个不同客户端在同一时刻一定看到同一系统镜像，如果要实现这种效果，需要在读取数据之前调用sync操作
》Zookeeper读性能好于写性能，因为任何Server均可提供读服务，而只有Leader可提供写服务
》为了保证Zookeeper本身的Leader Election顺利进行，通常将Server设置为奇数
》若需容忍f个Server的失败，必须保证有2f+1个以上的Server