zookeeper学习补充

zookeeper补充

分布式原理

CAP原理&BASE理论

CAP原理
CAP 理论指出对于一个分布式计算系统来说，不可能同时满足以下三点：
一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
可用性：每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。
分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区 容错性（Partition tolerance）这三项中的两项。
BASE理论
BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最 终一致性) 三个短语的缩写。

• 基本可用：在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。
• 软状态：允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。
• 最终一致性：data replications 经过一段时间达到一致性。

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

zookeeper一致性问题

思考：zookeeper是强一致性吗？
我们知道zookeeper在CAP原理中属于CP原理，那么zookeeper到底是不是强一致性呢，这个需要分开来讨论，既不能说不是，也不能单纯说是最终一致性。
zookeeper在集群架构中，对于写操作是强一致性的。所有写操作不管到那个节点都会转发到leader节点，leader写数据后会同步到其他节点，此时如果大部分节点(成功节点数大于半数节点)都返回同步成功，那么该写操作就完成。因此写操作是强一致性的。
但是读操作就不是强一致性的，因为写操作要求是大部分节点返回成功，有可能个别节点还存在延迟，如果此时读操作刚好请求到延迟的节点，那么就会出现脏数据。当然脏数据存在的时间是短暂的，最终还是同步成最新的数据。可以理解为最终一致性，但是准确来说的话应该顺序一致性，每次写操作都会带有一个版本号，同步的时候也会同步最新版本的数据。所以读操作最终会读到最新版本的数据。
总结：zookeeper写操作是强一致性，读操作是顺序一致性

zoo.cfg中参数含义和常用命令补充

** zoo.cfg中参数含义**

常用命令

命令基本语法	功能描述
help	显示所有操作命令
ls [-s] [-w] [-R] path	使用 ls 命令来查看当前 znode 的子节点 [可监听] -w: 监听子节点变化 -s: 节点状态信息（时间戳、版本号、数据大小等） -R: 表示递归的获取
create [-s] [-e] [-c] [-t ttl] path [data] [acl]	创建节点 -s : 创建有序节点。 -e : 创建临时节点。 -c : 创建一个容器节点。 t ttl : 创建一个TTL节点， -t 时间（单位毫秒）。 data：节点的数据，可选，如果不使用时，节点数据 就为null。 acl：访问控制
get [-s] [-w] path	获取节点数据信息 -s: 节点状态信息（时间戳、版本号、数据大小等） -w: 监听节点变化
set [-s] [-v version] path data	设置节点数据 -s:表示节点为顺序节点 -v: 指定版本号
getAcl [-s] path	获取节点的访问控制信息 -s: 节点状态信息（时间戳、版本号、数据大小等）
setAcl [-s] [-v version] [-R] path acl	设置节点的访问控制列表 -s:节点状态信息（时间戳、版本号、数据大小等） -v:指定版本号 -R:递归的设置
stat [-w] path	查看节点状态信息
delete [-v version] path	删除某一节点，只能删除无子节点的节点。 -v： 表示节点版本号
deleteall path	递归的删除某一节点及其子节点
setquota -n	-b val path

Zookeeper 节点特性总结

1. 同一级节点 key 名称是唯一的。已存在/lock节点，再次创建会提示已经存在
2. 已存在/lock节点，再次创建会提示已经存在
3. session 关闭，临时节点清除
4. 自动创建顺序节点
5. watch 机制，监听节点变化。
   事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。特别注意：监听事件被单次触发后，事件就失效了。
6. delete 命令只能一层一层删除。新版本可以通过 deleteall 命令递归删除

永久性Watch补充

永久性Watch 在被触发之后，仍然保留，可以继续监听ZNode上的变更，是Zookeeper 3.6.0版本新增的 功能
addWatch [‐m mode] path addWatch的作用是针对指定节点添加事件监听，支持两种模式 PERSISTENT，持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。
PERSISTENT_RECURSIVE，持久化递归订阅，在PERSISTENT的基础上，增加 了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足 递归订阅特性）

zookeeper使用场景补充

ZooKeeper适用于存储和协同相关的关键数据，不适合用于大数据量存储。
有了上述众多节点特性，使得 zookeeper 能开发不出不同的经典应用场景，比如：

• 注册中心
• 数据发布/订阅（常用于实现配置中心）
• 负载均衡
• 命名服务
• 分布式协调/通知
• 集群管理
• Master选举
• 分布式锁
• 分布式队列

统一命名服务
在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。例如：IP不容易记住，而域名容易记住。

序列号生成
利用 ZooKeeper 顺序节点的特性，制作分布式的序列号生成器。（分布式环境下使用作为数据库 id，另外一种是 UUID（缺点：没有规律）），ZooKeeper 可以生成有顺序的容易理解的同时支持分布式环境的编号。

/
└── /order
    ├── /order-date1-000000000000001
    ├── /order-date2-000000000000002
    ├── /order-date3-000000000000003
    ├── /order-date4-000000000000004
    └── /order-date5-000000000000005

数据发布/订阅
数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。配置信息一般有几个特点:

• 数据量小的KV
• 数据内容在运行时会发生动态变化
• 集群机器共享，配置一致

ZooKeeper 采用的是推拉结合的方式。
推: 服务端会推给注册了监控节点的客户端 Watcher 事件通知
拉: 客户端获得通知后，然后主动到服务端拉取最新的数据

统一集群管理
分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。 ZooKeeper可以实现实时监控节点状态变化：
可将节点信息写入ZooKeeper上的一个ZNode。监听这个ZNode可获取它的实时状态变化。

负载均衡
在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求

集群信息选举和信息同步

Zookeeper Leader 选举原理

zookeeper 的 leader 选举存在两个阶段，一个是服务器启动时 leader 选举，另一个是运行过程中 leader 服务器宕机。
在分析选举原理前，先介绍几个重要的参数：

• 服务器 ID(myid)：编号越大在选举算法中权重越大
• 事务 ID(zxid)：值越大说明数据越新，权重越大
• 逻辑时钟(epoch-logicalclock)：同一轮投票过程中的逻辑时钟值是相同的，每投完一次值会增加

选举状态：

• LOOKING: 竞选状态
• FOLLOWING: 随从状态，同步 leader 状态，参与投票
• OBSERVING: 观察状态，同步 leader 状态，不参与投票
• LEADING: 领导者状态

服务器启动时的 leader 选举
每个节点启动的时候都 LOOKING 观望状态，接下来就开始进行选举主流程。这里选取三台机器组成的集群为例。第一台服务器 server1启动时，无法进行 leader 选举，当第二台服务器 server2 启动时，两台机器可以相互通信，进入 leader 选举过程：

1. 每台 server 发出一个投票，由于是初始情况，server1 和 server2 都将自己作为 leader 服务器进行投票，每次投票包含所推举的服务器myid、zxid、epoch，使用（myid，zxid）表示，此时 server1 投票为（1,0），server2 投票为（2,0），然后将各自投票发送给集群中其他机器。
2. 接收来自各个服务器的投票。集群中的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票（epoch）、是否来自 LOOKING 状态的服务器。
3. 分别处理投票。针对每一次投票，服务器都需要将其他服务器的投票和自己的投票进行对比，对比规则如下：
   a. 优先比较 epoch
b. 检查 zxid，zxid 比较大的服务器优先作为 leader
c. 如果 zxid 相同，那么就比较 myid，myid 较大的服务器作为 leader 服务器
4. 统计投票。每次投票后，服务器统计投票信息，判断是都有过半机器接收到相同的投票信息。server1、server2 都统计出集群中有两台机器接受了（2,0）的投票信息，此时已经选出了 server2 为 leader 节点。
5. 改变服务器状态。一旦确定了 leader，每个服务器响应更新自己的状态，如果是 follower，那么就变更为 FOLLOWING，如果是 Leader，变更为 LEADING。此时 server3继续启动，直接加入变更自己为 FOLLOWING。

运行过程中的 leader 选举
当集群中 leader 服务器出现宕机或者不可用情况时，整个集群无法对外提供服务，进入新一轮的 leader 选举。

• 变更状态。leader 挂后，其他非 Oberver服务器将自身服务器状态变更为 LOOKING。
• 每个 server 发出一个投票。在运行期间，每个服务器上 zxid 可能不同。
• 处理投票。规则同启动过程。
• 统计投票。与启动过程相同。
• 改变服务器状态。与启动过程相同。

Zookeeper 数据同步流程

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

崩溃恢复
在正常情况消息下广播能运行良好，但是一旦 Leader 服务器出现崩溃，或者由于网络原理导致 Leader 服务器失去了与过半 Follower 的通信，那么就会进入崩溃恢复模式，需要选举出一个新的 Leader 服务器。在这个过程中可能会出现两种数据不一致性的隐患，需要 ZAB 协议的特性进行避免。

• Leader 服务器将消息 commit 发出后，立即崩溃
• Leader 服务器刚提出 proposal 后，立即崩溃
  ZAB 协议的恢复模式使用了以下策略：
• 选举 zxid 最大的节点作为新的 leader
• 新 leader 将事务日志中尚未提交的消息进行处理