【zookeeper】

功能：是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。

Zookeeper 提供了一个类似于Linux 文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息（纯内存数据），完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。

zk集群必须部署奇数台：选举需要，zookeeper中的过半机制保证了zookeeper集群的数据一致性。

leader选举算法采用了paxos协议：：当多数server写成功，则任务数据写成功。如果有3个server则2个写成功即可，当有4个或5个server，则3个写成功即可。

角色划分：
　　Leader：支持读写，唯一支持写的节点，

　　　　它会发起并维护与各Follwer及Observer 间的心跳。所有的写操作必须要通过Leader 完成再由Leader 将写操作广播给其它服务器。只要有超过半数节点（不包括observeer 节点）写入成功，该写请求就会被提交（类 2PC 协议）。

　　Follower：只读，支持选举

　　　　存在多个Follower，它会响应Leader 的心跳

　　　　Follower 可直接处理并返回客户端的读请求，同时会将写请求转发给Leader 处理；

　　　　负责在Leader 处理写请求时对请求进行投票。

　　Observer：只读，无选举权

　　　Zookeeper 需保证高可用和强一致性，为了支持更多的客户端，需要增加更多Server； Server增多，投票阶段延迟增大，影响性能；引入Observer，Observer 不参与投票； Observers 接受客户端的连接，并将写请求转发给leader 节点；加入更多Observer 节点，　　提高伸缩性，同时不影响吞吐率。

数据同步ZAB协议：实现分布式数据一致性

消息广播：
- Zookeeper 使用单一的主进程 Leader 来接收和处理客户端所有事务请求；
- 采用 ZAB 协议的原子广播协议，将事务请求以 Proposal 提议广播到所有 Follower 节点，当集群中有过半的Follower 服务器进行正确的 ACK 反馈，那么Leader就会再次向所有的 Follower 服务器发送commit 消息，将此次提案进行提交。这个过程可以简称为 2pc 事务提交，整个流程可以参考下图，注意 Observer 节点只负责同步 Leader 数据，不参与 2PC 数据同步过程。