ZooKeeper--分布式协调服务介绍

zookeeper

分布式协调服务，设计初衷是为了协调各个服务，并不是主要用来做服务注册发现的

简述

简单说就是：ZooKeeper是用于分布式应用程序的高性能协调服务。提供了配置管理，同步服务等，还有就是领导者选举和状态协议，还可以在服务提供的基础上自己定义

---

设计目标：

zk允许分布式进程通过共享的分层名称空间相互协调，命名空间的组织方式类似于标准文件系统，zk的数据保留在内存中，意味着zk可以实现高吞吐量和低延迟数。

---

数据结构：

类似文件系统中的文件夹，只是这里的文件夹可以存数据

---

API和实例

zk的设计目标就是简单所以 它仅支持以下操作：

• create：在树中的某个位置创建一个节点
• delete：删除节点
• 存在：测试某个位置是否存在节点
• 获取数据：从节点读取数据
• 设置数据：将数据写入节点
• 获取子节点：获取节点子节点的列表
• sync：等待数据传播

复制的数据库是包含整个数据树的内存数据库。更新被记录到磁盘以确保可恢复性，并且在将写入应用于内存数据库之前将写入序列化到磁盘。

每个ZooKeeper服务器都为客户端提供服务。客户端仅连接到一台服务器即可提交请求。读取请求从每个服务器数据库的本地副本提供服务。更改服务状态的请求（写请求）由协议协议处理。

作为协议协议的一部分，来自客户端的所有写请求都转发到称为领导者的单个服务器。其余的ZooKeeper服务器（称为跟随者）从领导者接收消息建议并同意消息传递。消息传递层负责替换出现故障的领导者，并将跟随者与领导者同步。

ZooKeeper使用自定义的原子消息传递协议。由于消息传递层是原子层，因此ZooKeeper可以保证本地副本永远不会发散。领导者收到写请求时，它将计算要应用写操作时系统的状态，并将其转换为捕获此新状态的事务。

---

性能

1. 如果关注者失败并迅速恢复，则ZooKeeper能够在失败的情况下维持高吞吐量
2. 领导者选举算法允许系统恢复得足够快，以防止吞吐量大幅下降
3. ZooKeeper只需不到200毫秒即可选出新的领导者
4. 随着关注者的恢复，ZooKeeper能够在开始处理请求后再次提高吞吐量。

---

总结：特性/保证

1. 顺序一致性：客户端的更新将按发送顺序应用。
2. 原子性：更新成功或者失败。没有部分结果
3. 统一视图：无论服务器连接到那个服务，客户端都将看到相同的服务器视图。
4. 可靠性：一旦应用了更新，它将从那时起持续到客户端覆盖更新。
5. 及时性：系统的客户视图保证在特定时间范围内是最新的。

Zookeeper