zookeeper笔记-理论1

zookeeper 是什么

参看官网：A Distributed Coordination Service for Distributed Applications（分布式协调服务）。

基本信息

znode 节点

临时节点
持久化节点
有序节点
基于节点的特性，在很多场景中发挥作用

场景

分布式锁
leader选举
配置中心

连接会话

1. Client 初始化连接，状态转为 CONNECTING(①)
2. Client 与 Server 成功建立连接，状态转为 CONNECTED(②)
3. Client 丢失了与 Server 的连接或者没有接受到 Server 的响应，状态转为 CONNECTING(③)
4. Client 连上另外的 Server 或连接上了之前的 Server，状态转为 CONNECTED(②)
5. 若会话过期(是 Server 负责声明会话过期，而不是 Client )，状态转为 CLOSED(⑤)，状态转为 CLOSED
6. Client 也可以主动关闭会话(④)，状态转为 CLOSED

stat 获取的状态信息

zkcli 中 stat /node 查看

版本

保证分布式数据原子性

zookeeper 的设计

集群的角色

Leader 角色

Leader 服务器是整个 zookeeper 集群的核心，主要的工作 任务有两项

1. 事务请求的唯一调度和处理者，保证集群事务处理的顺 序性
2. 集群内部各服务器的调度者

Follower 角色

Follower 角色的主要职责是

1. 处理客户端非事物请求、转发事务请求给leader服务器
2. 参与事物请求 Proposal 的投票(需要半数以上服务器 通过才能通知 leader commit 数据; Leader 发起的提案， 要求 Follower 投票)
3. 参与 Leader 选举的投票

Observer 角色

Observer 是 zookeeper3.3 开始引入的一个全新的服务器 角色，从字面来理解，该角色充当了观察者的角色。 观察 zookeeper 集群中的最新状态变化并将这些状态变化 同步到 observer 服务器上。Observer 的工作原理与 follower 角色基本一致，而它和 follower 角色唯一的不同 在于 observer 不参与任何形式的投票，包括事物请求 Proposal 的投票和 leader 选举的投票。简单来说，observer 服务器只提供非事物请求服务，通常在于不影响集群事物 处理能力的前提下提升集群非事物处理的能力。

集群组成

通常 zookeeper 是由 2n+1 台 server 组成，每个 server 都 知道彼此的存在。对于 2n+1 台 server，只要有 n+1 台(大 多数)server 可用，整个系统保持可用。我们已经了解到， 一个 zookeeper 集群如果要对外提供可用的服务，那么集 群中必须要有过半的机器正常工作并且彼此之间能够正常 通信，基于这个特性，如果向搭建一个能够允许 F 台机器 down 掉的集群，那么就要部署 2*F+1 台服务器构成的 zookeeper 集群。因此 3 台机器构成的 zookeeper 集群， 能够在挂掉一台机器后依然正常工作。一个 5 台机器集群 的服务，能够对 2 台机器挂掉的情况下进行容灾。如果一台由 6 台服务构成的集群，同样只能挂掉 2 台机器。因此， 5 台和 6 台在容灾能力上并没有明显优势，反而增加了网 络通信负担。系统启动时，集群中的 server 会选举出一台 server 为 Leader，其它的就作为 follower(这里先不考虑 observer 角色)。 之所以要满足这样一个等式，是因为一个节点要成为集群 中的 leader，需要有超过及群众过半数的节点支持，这个 涉及到 leader 选举算法。同时也涉及到事务请求的提交投票。

zk 一致性原理

顺序一致性

不同client （网络问题等）可能读到不同的值，以到达服务器的时间顺序为准。但可通过 sync() api 同步后返回最新结果。
如果一个 client 连接到 zxid 大的 服务器，第二次如果 连接到 zxid 小的服务器，则会连接失败。
过半提交策略

需要解决问题

1、防止单点故障
2、数据同步
3、leader选举算法(zab协议）

zab协议 与 paxos 协议 对比

paxos 协议
构建一个分布式的一致性状态机系统
第一个阶段是读阶段，这个阶段中，这个新的主进程会通过和所有其他进程进行通信的方式收集上一个主进程提出的提案，并将它们提交。
第二个阶段是写阶段，这个阶段中，当前主进程Leader开始提出它自己的提案。
chubby
1、master选举（paxos算法实现）
2、数据同步-slave 节点要和master同步。（paxos 投票机制）

zab协议
构建一个高可用的分布式数椐主备系统
三阶段：发现阶段、同步阶段、广播阶段，其中发现阶段等同于Paxos的 读阶段，广播阶段等同于Paxos的写阶段。
同步阶段是ZAB算法新添加的，在同步阶段，新的Leader会确保存在过半的Follower已经提交了之前Leader周期中的所有事务Proposal。
同步阶段的引入，能够有效地保证Leader在新的周期提出事物Proposal之前，所有的进程都已经完成了对之前所有事务的提交。

ZAB协议

主要功能：
奔溃恢复

原子广播

奔溃恢复

需要考虑一下问题：
1、leader挂了。进入 恢复模式，重新发起 leader选举
2、leader选举后，进行数据同步
3、服务启动时，发起leader选举

ZAB 协议的这个基于原子广播协议的消息广播过程，在正 常情况下是没有任何问题的，但是一旦 Leader 节点崩溃， 或者由于网络问题导致 Leader 服务器失去了过半的Follower 节点的联系(leader 失去与过半 follower 节点联 系，可能是 leader 节点和 follower 节点之间产生了网络分 区，那么此时的 leader 不再是合法的 leader 了)，那么就 会进入到崩溃恢复模式。在 ZAB 协议中，为了保证程序的 正确运行，整个恢复过程结束后需要选举出一个新的 Leader.

为了leader挂了后系统能正常工作，需要解决一下两个问题；
1、已经被处理的消息不能丢失
当 leader 收到合法数量 follower 的 ACKs 后，就向 各个 follower 广播 COMMIT 命令，同时也会在本地 执行 COMMIT 并向连接的客户端返回「成功」。但是如 果在各个 follower 在收到 COMMIT 命令前 leader 就挂了，导致剩下的服务器并没有执行这条消息。
leader 对事务消息发起 commit 操作，但是该消息在 follower1 上执行了，但是 follower2 还没有收到 commit， 就已经挂了，而实际上客户端已经收到该事务消息处理成功的回执了。所以在 zab 协议下需要保证所有机器都要执 行这个事务消息
即 选举数据同步到最新的slave 为 leader（zxid 最大）
2、被丢弃的消息不能再次出现
当 leader 接收到消息请求生成 proposal 后就挂了，其 他 follower 并没有收到此 proposal，因此经过恢复模式 重新选了 leader 后，这条消息是被跳过的（未过半提交）。 此时，之前 挂了的 leader 重新启动并注册成了 follower，他保留了 被跳过消息的 proposal 状态，与整个系统的状态是不一 致的，需要将其删除。