Zookeeper简介

Zookeeper是什么：

Zookeeper是一个高效的分布式协调服务，它暴露了一些公共服务，比如命名/配置管理/同步控制/群组服务等。我们可以使用Zookeeper来实现比如达成共识、集群管理、leader选举等。同时zookeeper还是一个高可用的分布式管理与协调框架，基于ZAB算法(原子消息广播协议)的实现。该框架能够很好的保证分布式环境数据的一致性。

Zookeeper的特性：

1. 顺序一致性：从一个客户端发起的事物请求，最终将会严格地按照其发起的顺序被应用到Zookeeper中
2. 原子性：所有事物请求的处理结果在整个集群中所有机器上的应用情况时一致的。即整个集群所有机器的应用某一事物，要么都成功要么都不成功。
3. 单一视图：无论客户端连接的哪一个zookeeper服务器，其看到的服务器端数据模型都是一致的。
4. 可靠性：一旦服务器成功地应用了一个事物，并完成对客户端的影响，那么该事物锁引起的服务器端状态将会被一致保留下来，除非另外有一个事物对其做了更改
5. 实时性：通常意义下的实时性指事物一旦被成功应用，那么客户端就能立刻从服务器上获取更新后的信息。zookeeper仅仅能保证在一段时间内，客户端最终一定能从服务器端获取最新的数据。

Zookeeper设计目标：

1. 简单的数据结构：zookeeper是以简单的属性结构来进行相互协调的，也叫树形名字空间
2. 构建集群：zookeeper集群通常由一组机器构成，一般3~5台可以组成一个zookeeper，只要集群中超过半数以上的机器能够正常工作，那么整个集群就能对外提供正常服务。且zookeeper集群中，节点数一般为奇数个如：3个、5个、7个等，便于选择出leader节点。
3. 顺序访问：对于每个辣子客户端的请求，zookeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事物的先后顺序，应用程序利用该特性来实现更高层次的同步。
4. 高性能：zookeeper数据都是存储在内存中的，并直接服务于所有非事务请求，因此在读操作为主的场景下，性能较高。在JMater压力测试下，结果大约在12~13W的QPS

zookeeper数据模型：

1. 每个子目录项，如NameService都被称为znode，这个znode是被其它所在的路径唯一标识，如server1的znode标识为：/NameService/server1
2. znode可以有子节点目录，且每个znode可以存储数据，注意EPHEMERAL类型的目录节点不能有子节点目录
3. znode是有版本的，每个znode中可以存储数据的多个版本，也就是一个访问路径可以存储多份数据
4. znode可以是临时节点，一旦创建这个znode的客户端与服务器端是去连接，这个znode也将自动删除。zookeeper的客户端与服务器端的通信采用长链接方式，每个客户端和服务器端通过心跳保持连接，这个连接状态称为session，如果znode是临时节点，这个session将失效，znode也就删除
5. znode的目录名可以自动编号，如App1已经存在，再次创建的话，将会自动命名为App2
6. znode可以被监控（watcher机制），包括这个目录节点中存储的数据的修改，子节点目录的变化等。一旦变化可以通知设置监控的客户端，这个是zookeeper的核心特性。zookeeper的很多功能都是基于这个特性实现的。

zookeeper集群的组成：

• leader：负责客户端的writer类型的请求
• Follower：负责客户端reader类型的请求，参与leader选举
• Observer：特殊的Follower，可以接受客户端reader请求，但不参与选举。主要作用是扩容系统的支撑能力提高读取速度，因为它不接受同步的写入请求，只负责与leader同步数据。

zookeeper应用场景：

zookeeper从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦数据状态发生变化，zookeeper将负责通知已在zookeeper上注册的那些观察者做出相应的反应。从而实现集群中类似Master/Slave管理模式。

主要应用的场景有：

• 配置管理：使用场景------数据量小；数据在运行时动态变化；集群中各个节点共享信息，配置一致；
• 集群管理：使用场景----- 希望知道当前集群中有多少机器工作；集群中每天集群的运行时状态进行数据收集；集群中每台服务器进行上下线操作
• 发布与订阅：zk是一个典型的发布/订阅模式的分布式数控管理与协调框架。
• 数据库切换：如我们在初始化zk时，读取器节点上的数据库配置文件，当配置一旦发生变更时，zk就能帮我们把变更的通知发送到各个客户端，每个互动在接受到这个变更通知后，就可以重新获取最新数据。
• 分布式日志收集：我们可以做一个日志系统收集集群中所有日志信息，进行统一管理
• 分布式锁、队列管理：zk的特性是在分布式场景下高可用，但原生的API实现分布式功能非常困难。一般采用第三方的客户端如：Curator、zkClient客户端等。

zookeeper节点类型：

节点有两个维度，一个是永久的还是临时的，另一个是否有序。组合成的四种类型如下：

1. PERSISTENT                                //  持久化节点
2. PERSISTENT_SEQUENTIAL       //  持久化排序节点
3. EPHEMERAL                                 //  临时节点
4. EPHEMERAL_SEQUENTIAL        //  临时排序节点

永久节点：节点创建后会被持久化，只有主动调用delete方法的时候才可以删除节点。

临时节点：节点创建后在创建者超时连接或失去连接的时候，节点会被删除。临时节点下不能存在字节点。（临时节点可以用于设计分布式锁）

排序节点：创建的节点名称后自动添加序号，如节点名称为"node-"，自动添加为"node-1"，顺序添加为"node-2"...

ZAB算法：

ZAB全称为 ZooKeeper Atomic Broadcast (Zookeeper 原子广播)，是 Zookeeper 中的一种多主同步算法，该算法用于保证集群中所有服务器之间的数据一致性和顺序性。ZAB 是一个轻量级的算法，它的主要优点是能够快速地将数据提交和同步至集群中的所有节点。此外，ZAB 也可以保证确保集群节点之间的数据一致性。

当任何一个节点对数据进行写操作时，都需要先经过 Zookeeper 集群中的 Leader 节点，Leader 节点通过 ZAB 算法将数据广播给所有的 Follower 节点。这个过程中，Leader 节点扮演着一个协调者的角色，它会维护一个全局的顺序并生成唯一的事务 ID。当 Follower 节点接收到 Leader 节点发来的数据修改请求后，会确认并将确认消息返回给 Leader 节点，并等待 Leader 节点广播下一个数据修改请求。如果 Leader 节点出现故障，Zookeeper 会自动选举一个新的 Leader 节点。以下是 ZAB 算法的几个核心步骤：

1. 选举 Leader：在 ZooKeeper 集群中，所有节点都可以作为 Leader，但是只有一个节点可以担当该角色。当 Leader 节点出现故障或失去联系时，ZooKeeper 会自动在 Follower 节点中选举出新的 Leader 节点。

2. 发现 Leader：所有的 Follower 节点都会尝试去寻找可用的 Leader，并在找到时与其进行同步。ZooKeeper 将会选举出一个新的 Leader 并将其宣布出去。

3. 启动恢复模式：如果 Leader 节点与 Follower 节点发生连接中断或 Leader 节点快照不完整时，Follower 节点会启动恢复模式，在这种模式下，Follower 节点会请求 Leader 节点发送最新的数据。一旦 Follower 节点收到最新的数据，它们就会结束恢复模式并与 Leader 节点进行同步。

4. 同步数据：一旦 Follower 节点与 Leader 节点建立了连接，Follower 节点就会遵循 Leader 节点的命令来进行数据同步。此外，当任何一个节点对数据进行写操作时，都需要先经过 Leader 节点，ZAB 算法会将这些请求广播到所有 Follower 节点，并等待大多数节点确认当前请求，确认通过后再执行下一次请求。

5. 事务标识符的唯一性：ZAB 算法会给所有的写操作分配一个递增的事务 ID，这个 ID 就像一个时间戳，可以用于记录每个操作的先后顺序。ZAB 算法保证事务 ID 的唯一性，因此所有节点都可以根据事务 ID 来达成共识。

总的来说，ZAB 算法通过选举 Leader、发现 Leader、启动恢复模式、同步数据和确保事务 ID 的唯一性等步骤来维护 ZooKeeper 集群的数据一致性和容错性。