Java进阶6-Zookeeper_独立性(等待无关)

1、Zookeeper是什么

ZooKeeper 是一个开源的分布式协调服务，它的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

ZooKeeper 为我们提供了高可用、高性能、稳定的分布式数据一致性解决方案，通常被用于实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

简述：有些软件你想做成集群或者分布式，你可以用 ZooKeeper 帮你来辅助实现

特点：
最终一致性：客户端看到的数据最终是一致的。
可靠性：服务器保存了消息，那么它就一直都存在。
实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据。
独立性（等待无关）：不同客户端直接互不影响。
原子性：更新要不成功要不失败，没有第三个状态。

ZooKeeper 典型应用场景：

1. 分布式锁 ： 通过创建唯一节点获得分布式锁，当获得锁的一方执行完相关代码或者是挂掉之后就释放锁。
2. 命名服务 ：可以通过 ZooKeeper 的顺序节点生成全局唯一 ID
3. 数据发布/订阅 ：通过 Watcher 机制 可以很方便地实现数据发布/订阅。当你将数据发布到 ZooKeeper 被监听的节点上，其他机器可通过监听 ZooKeeper 上节点的变化来实现配置的动态更新。

实际上，这些功能的实现基本都得益于 ZooKeeper 可以保存数据的功能，但是 ZooKeeper 不适合保存大量数据，这一点需要注意。

有哪些著名的开源项目用到了 ZooKeeper?

• Kafka : ZooKeeper 主要为 Kafka 提供 Broker 和 Topic 的注册以及多个 Partition 的负载均衡等功能。
• Hbase : ZooKeeper 为 Hbase 提供确保整个集群只有一个 Master 以及保存和提供 regionserver 状态信息（是否在线）等功能。
• Hadoop : ZooKeeper 为 Namenode 提供高可用支持。

2、Zookeeper有哪些模块组成

ZooKeeper 数据模型采用层次化的多叉树形结构，每个节点上都可以存储数据，这些数据可以是数字、字符串或者是二级制序列。每个节点还可以拥有 N 个子节点，最上层是根节点以“/”来代表。每个数据节点在ZooKeeper 中被称为 znode，它是 ZooKeeper 中数据的最小单元。每个 znode 都一个唯一的路径标识。
强调一句：ZooKeeper 主要是用来协调服务的，而不是用来存储业务数据的，所以不要放比较大的数据在 znode 上，ZooKeeper 给出的上限是每个结点的数据大小最大是 1M。

通常是将 znode 分为 4 大类：

• 持久（PERSISTENT）节点 ：一旦创建就一直存在即使 ZooKeeper 集群宕机，直到将其删除。
• 临时（EPHEMERAL）节点 ：临时节点的生命周期是与 客户端会话（session） 绑定的，会话消失则节点消失 。并且，临时节点只能做叶子节点 ，不能创建子节点。
• 持久顺序（PERSISTENT_SEQUENTIAL）节点 ：除了具有持久（PERSISTENT）节点的特性之外， 子节点的名称还具有顺序性。比如 /node1/app0000000001 、/node1/app0000000002 。
• 临时顺序（EPHEMERAL_SEQUENTIAL）节点 ：除了具备临时（EPHEMERAL）节点的特性之外，子节点的名称还具有顺序性。

每个 znode 由 2 部分组成:

• stat ：状态信息
• data ： 节点存放的数据的具体内容

3、Zookeeper工作原理

ACL（权限控制）

ZooKeeper 采用 ACL（AccessControlLists）策略来进行权限控制，类似于 UNIX 文件系统的权限控制。
对于 znode 操作的权限，ZooKeeper 提供了以下 5 种：

• CREATE : 能创建子节点
• READ ：能获取节点数据和列出其子节点
• WRITE : 能设置/更新节点数据
• DELETE : 能删除子节点
• ADMIN : 能设置节点 ACL 的权限

其中尤其需要注意的是，CREATE 和 DELETE 这两种权限都是针对 子节点 的权限控制。
对于身份认证，提供了以下几种方式：

• world ： 默认方式，所有用户都可无条件访问。
• auth :不使用任何 id，代表任何已认证的用户。
• digest :用户名:密码认证方式： username:password 。
• ip : 对指定 ip 进行限制。

Watcher（事件监听器）

Watcher（事件监听器），是 ZooKeeper 中的一个很重要的特性。ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是 ZooKeeper 实现分布式协调服务的重要特性。

会话（Session）

Session 可以看作是 ZooKeeper 服务器与客户端的之间的一个 TCP 长连接，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的 Watcher 事件通知。
Session 有一个属性叫做：sessionTimeout ，sessionTimeout 代表会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

Zookeeper 数据同步流程

Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos 算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在 ZooKeeper 的官方文档中也指出，ZAB 协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为 Zookeeper 设计的崩溃可恢复的原子消息广播算法。

在 Zookeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性。
ZAB 协议分为两部分：消息广播、崩溃恢复

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

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

• 1、Leader 服务器将消息 commit 发出后，立即崩溃
• 2、Leader 服务器刚提出 proposal 后，立即崩溃

ZAB 协议的恢复模式使用了以下策略：

• 1、选举 zxid 最大的节点作为新的 leader
• 2、新 leader 将事务日志中尚未提交的消息进行处理

Zookeeper Leader 选举原理

为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么 ZooKeeper 本身仍然是可用的。通常 3 台服务器就可以构成一个 ZooKeeper 集群了。ZooKeeper 官方提供的架构图就是一个 ZooKeeper 集群整体对外提供服务。

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

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

选举状态：

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

1、服务器启动时的 leader 选举

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

2、运行过程中的 leader 选举

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

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

4、Zookeeper优缺点

优点：
最终一致性：客户端看到的数据最终是一致的。
可靠性：服务器保存了消息，那么它就一直都存在。
实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据。
独立性（等待无关）：不同客户端直接互不影响。
原子性：更新要不成功要不失败，没有第三个状态。

缺点：
1、作为注册中心，只能保证CP，强一致性的设计。
2、增加新的zk服务器时可能导致数据丢失。
3、不能迁移。
4、节点数（其实集群中只要存活数过半即对外可用，但是会有脑裂情况发生）。要求3或5个这样奇数个zk节点（要求奇数是为了保证选举的正常进行因为leader选举要求 可用节点数量 > 总节点数/2，防止脑裂造成集群不可用。同时在容错能力相同的情况下，奇数个节点更节省资源）

参考链接：
https://juejin.cn/post/6844903942518734855
https://blog.csdn.net/qq_41544550/article/details/123148688
https://www.runoob.com/w3cnote/zookeeper-leader.html
http://www.passjava.cn/#/04.Architecture/05.%E4%B8%AD%E9%97%B4%E4%BB%B6%E5%8E%9F%E7%90%86%E5%89%96%E6%9E%90/01.Zookeeper/02.ZAB%E5%8D%8F%E8%AE%AE
https://doocs.github.io/advanced-java/#/docs/distributed-system/zookeeper-application-scenarios
https://javaguide.cn/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.html#_5-1-zab-%E5%8D%8F%E8%AE%AE%E4%BB%8B%E7%BB%8D