原文格式可以访问：https://www.rockysky.tech
分布式系统的基本操作
- 主节点选举：在绝大多数分布式系统中，都需要进行主节点选举。主节点负责管理协调其它节点或者同步集群中其它节点的数据。为了确保集群中一直存在一个主节点，需要有主节点的选举机制。但现有主节点无法访问的时候，自动产生新的主节点接管集群管理和协调的任务
- 宕机检测：当集群中有某个节点或者某部分节点脱离集群或者不可访问的时候，分布式系统的其他节点可以识别出来，并执行相应的步骤，去替换或者接管宕机节点的工作，使得整个集群的功能不会受到影响。
- 集群组管理：对于比较大规模的分布式系统，我们需要管理其不同的分组。比如说Kubernetes集群就需要管理基本的服务单位POD。如何去管理和协调每个组的资源和任务分配也是分布式系统必须要处理的任务。
- 元数据管理（Metadata）：在一个分布式系统中需要保存一些元数据。比如每个节点正在执行的任务，任务的进度，各个节点的状态。节点间需要共享的一些同步数据等等。
Zookeeper是什么
Zookeeper是一个分布式系统协调器，其本身并不直接实现上述的任何一个分布式系统的基本操作。Zookeeper本身其实就是一个通过Raft共识机制协同的分布式键值对文件存储系统。Zookeeper的文件以树状形式存储，每个节点都可以存储数据，每个节点叫做一个znode，如下图所示：
和普通的文件结构不同，Zookeeper没有目录的概念，每个节点都可以存储数据。
持久性节点（Persistent）和易失性（Ephemeral）节点
Zookeeper的节点分为两种主要的类型，即持久性节点和易失性节点，
- 持久性节点（Persistent），这种节点的数据必须能够一直保存，即使写入这些数据的客户端连接丢失，或者客户端宕机。这些节点和数据任然必须保留。举个例子，比如说一个并行运算的集群，给每个slave节点分配的运算任务必须要能够记录下来，即使集群的master节点或者slave节点宕机，为了保证最后的运算能够完整，也不能够把这些任务删除。
- 易失性节点（Ephemeral）一旦客户端本身连接中断或者宕机，这些数据节点会被释放。例如，一个集群的Master节点挂了，那这个Master节点的锁就必须要释放出来，这个锁的机制就可以用易失性节点来完成。
有条件的更新和Watch机制
Zookeeper支持一种watches机制。客户端可以给znode设定watch机制，一旦这个znode被更新，就会触发通知机制发送消息给客户端，同时删除这个watch。如果ZooKeeper服务器本身挂掉了，那客户端会直接收到本地通知。
ZooKeeper保证的是什么
ZooKeeper的设计原则
Zookeeper本身被设计为一个非常简单，高速和可靠的服务。从而为各类分布式系统提供高级别和负责的分布式系统基本操作。对于分布式系统的CAP分类中，ZooKeeper是一种CP系统，重点保证的是强一致性。包括以下的特点：
顺序一致性：客户端对节点的更新一定会保证其最终更新先后顺序的的一致性
原子性：对znode的更新只会有成功，失败两种状态，不会有中间结果
单点一致性：客户端对zookeeper集群中任何一节点看到的znode结构和数据完全相同
高可靠性：一旦对znode更新成功，其结果会一直保持，直到下一次变更
-
时效性：在一定时间段，确保系统数据最新（up-to-date）
不过需要注意的是Zookeeper不确保数据的可用性，必须要等到所有ZooKeeper集群节点都同步成功，数据更新才会确认操作成功。这是才能够读取这个数据。时效性是值得能够确保在一定的时间段内可以完成数据跟新和同步。
极为简单的API设计
Zookeeper通过API提供服务，提供以下几个API。
- create : 在树状结构上创建znode
- delete : 删除znode
- exists : 测试某个znode是否存在
- get data : 读取某个znode的数据
- set data : 向Znode写入数据
- get children : 获取子节点列表
- sync : 等待所有zookeeper节点广播和同步完成。
性能：
在大量读和少量写入的情况先，Zookeeper性能是比较高的。
可靠性：
官方数据显示，Zookeeper选举主节点的时间大概在200ms，当节点从新恢复后，整个系统性能可以迅速恢复。
