ZAB 协议
ZAB 协议
故障恢复的原子广播协议。
消息广播：
- 只允许有一个主进程（leader）接收事务请求并处理。
- 当leader 接收到请求之后，将事务请求转化为事务提议（proposal） 并将该proposal 分别入队 （leader 会为每个follower 分别创建一个响应队列用来保证事务提交的顺序）。
- 每个事务proposal 有一个递增的全局唯一的ID，事务ID（ZXID）
- leader 通过响应队列将proposal 分发到其他节点之后，等待反馈；follower 接收到proposal 之后写入本地日志，返回 ack；
- leader 收到一半以上follower 的反馈之后，会向其他节点 发送commit，同时提交事务。
故障恢复：
- 保证已经在leader 机器上提交的事务最终被所有机器提交
- 丢弃只在leader 机器上被提出的事务
为保证以上两点：
- Leader选举：选择ZXID 最大的节点作为Leader。
- 数据同步：leader 为每个follower 创建一个队列，将没有被各个follower 提交的事务 proposal填入各个队列，并分发给follower。follower 事务同步以后，leader会将它加入到真正可用follower 列表中。
ZAB协议中两种模式：
消息广播和故障恢复。
当系统启动或者leader 机器出现故障现象时，进入故障恢复模式并进行leader选举。选举产生的leader 会与过半的follower 进行数据同步。同步结束，退出故障恢复模式，进入消息广播模式；任意一台遵从ZAB协议的机器启动后，如果检测到leader 广播，都会自动进入故障恢复模式与leader 进行数据同步，同步之后，进入消息广播模式；非leader 接收到客户端事务请求时，会转发给leader 处理；
Leader 重新选举条件：
- leader 宕机或故障
- 与leader 保持连接的机器少于一半
Zookeeper
- zookeeper 为分布式应用提供了一个高效可靠的分布式协调服务；
- 实现依赖于ZAB 协议，实现了一种主备模式的架构来保持集群的数据一致性；
- zookeeper 可以帮助分布式应用以一个共享的树形的命名空间实现协调；
- zookeeper 将数据全部存储在内存中并且集群中任意一台机器都可以响应客户端读操作，因此它更适合用以读操作为主的场景；zookeeper 集群节点有三种角色：leader、follower、observer。
- leader：通过选举产生的集群领导者；提供读写服务；
- follower：提供读服务；参与leader 选举和写操作“过半写成功”策略；
- observer：提供读服务；不影响集群写性能的前提下提升集群的读性能；
- zookeeper 集群节点总数为奇数；
- zookeeper 数据节点类型：持久节点（只能采用删除操作清除该节点）、临时节点（其生命周期取决于session 是否失效）、顺序节点（子节点顺序表，节点名有数字后缀） ；
- zookeeper 每个节点都有 Stat 结构（数据节点的所有状态信息）
- 最重要的功能：watcher；
- 开源客户端：zkclient、curator；
