zookeeper 的核心原理

分布式环境下需要解决的问题

1. 各个节点的数据一致性
2. 保证某一个任务只在一个节点执行，比如说定时任务
3. 如果集群的机器中有一台挂掉，怎么告知其他节点并接替任务
4. 一些共享资源需要保证互斥和安全性，不能同时修改
5. 所以需要引入分布式协调服务解决上述问题

分布式协调服务设计猜想

1. 所有节点统一到协调服务注册，然后让协调服务管理节点的调用
2. 因为所有节点都要调用协调服务，所以协调服务需要使用集群，提高可用性，防止单点故障导致所有节点挂掉，而且可以分担请求带来的流量
3. 协调服务做集群的话，如果要保证每个节点都收到请求，并且处理的话，就要面临着数据一致性的问题，所以需要选出一台 leader 节点负责协调节点和数据同步的操作
4. 如果 leader 挂了怎么办，所以在 zookeeper 中引入了基于 paxos 理论衍生的 ZAB 协议

zookeeper 的集群角色

1. 有三种角色 Leader、Follower、Observer
2. Leader
   • 是事务请求的唯一调度和处理者，保证集群事务处理的顺序序性
   • 是集群内部各服务器的调度者
3. Follower
   • 处理客户端非事务请求，转发事务请求给 Leader 服务器
   • 参与事务请求 Proposal 的投票
   • 参与 Leader 的选举投票
4. Observer
   • 处理客户端非事务请求，转发事务请求给 Leader 服务器
   • 不参加任何形式的投票，包括选举和事务投票(超过半数确认)
   • 它的存在是为了提高 zk 集群对外提供读性能的能力
5. 当收到非事务请求时，任意一个节点收到都可以直接处理
6. 当收到事务请求时：
   • 如果是 Follower 或者 Observer，都需要把请求转发给 Leader
   • 然后 Leader 把事务转发给所有 Follower 节点（Observer 不需要）
   • 所有 Follower 节点会返回 Leader 节点答复，告知是否可以执行，当收到过半数的 Follower 节点同意执行事务的请求，则会提交当前事务

ZAB 协议

1. 支持崩溃回复的原子消息广播协议、主要用于实现 zk 集群数据的一致性
2. 消息广播模式
   • Leader 服务器对事务请求生成一个全局的的递增事务 ZXID，保证每个消息的因果关系的顺序（64 位自增 ID）
   • Leader 为每一个 Follower 服务器都各自分配一个单独的队列，然后将需要广播的带有 zxid 的消息作为事务 Proposal 依次放入这些队列中去，并根据 FIFO 策略进行消息发送
   • 每一个 Follower 服务器在接收到这个事务 Proposal 之后，首先以日志形式写入本地磁盘，并且成功写入后反馈给 Leader 服务器一个 Ack 响应
   • 当 Leader 服务器接收超过半数的 Follower 的 Ack 响应，Leader 自身也会完成对事务的提交。同时就会广播一个 Commit 消息给所有的 Follower 服务器以通知进行事务提交。每一个 Follower 服务器在接收到 Commit 消息后，也会完成对事务的提交。
3. 崩溃恢复
   • 当 Leader 失去过半的 Follower 节点的联系或者自己挂了的时候，集群就会进入崩溃恢复阶段
   • 崩溃恢复要保证已被处理的消息不能被丢失，假设 Leader 在自己提交事务后，通知 Follower 节点提交事务时挂掉，需要保证这个数据在重新选出 Leader 后一样能同步到各节点
   • 崩溃恢复还需要保证丢弃那些只在 Leader 服务器上被提出的事务。假设 Leader 在收到事务请求准备通知 Follower 投票时挂掉了，需要保证重新选出 Leader 后这条消息需要被丢弃