Zookeeper：保证、简单的API和主要实现

1.声明

当前内容主要用于本人学习和复习，当前内容主要为Zookeeper的保证和简单的API

当前内容来源于：Zookeeper官方文档

2.保证

1. 顺序一致性：客户端的更新将按照其发送顺序进行应用(zookeeper内部会自动标记每个执行方式并实现顺序执行)
2. 原子性：结果只有更新成功或者失败(所有对数据的操作是原子操作)
3. 单一系统映像：无论客户端连接到哪个服务器，客户端都将看到相同的服务视图(肯定啊，所有的节点内部都维护了一个相同的蓝图，并使用复制方式实现一致性)
4. 可靠性：应用更新后，此更新将一直持续到客户端覆盖更新为止(应为leader实际会先写入磁盘，然后加载到内存中，所以不怕宕机)
5. 及时性：确保系统客户视图在特定时间范围内是最新的(因为复制节点数据需要时间，leader宕机后需要通过选举方式从flowers中选出一个，然后才会提供服务)

3.简单的api

zookeeper提供了非常简单的编程方式：

1.在树中的某个位置添加节点使用：create

2.删除节点：delete

3.判断某个位置是否存在节点：exists

4.获取数据：get

5.修改节点：set

6.获取节点子节点的列表：get children,（该children必须是容器节点）

7.等待数据传播(同步)：sync

4.Zookeeper的主要实现

构成Zookeeper服务的每个服务都是复制器自己的每个组件的副本

下面是一个官方的写入请求的图解

根据当前的官方文档可以得到如下步骤

1. 当一个写入请求达一个服务器的时候(此时成为消息传递层)，该服务器将转发给集群中的leader的单个服务器中
2. 由leader通过原子层(实现原子性操作)并通过序列化方式写入到磁盘中，然后将该数据加载到内存中
3. 此时完成数据的写入操作，然后再响应当前的写入请求
4. 此时从节点开始读取leader的内存图像，并替换自身过时的内存图像，从而实现主从复制的目的
5. 读取每个zookeeper都是从本地的内存图像中获取的
6. 如果写入时leader出现问题，那么由消息传递层(也是一个flower)将替换当前的leader，实现leader与从者的同步

这说明所有的写操作都是通过leader中写入的，先写入磁盘然后再写入内存中，所有读取操作都是可以在各个节点上访问，获取的也是内存中的数据

5.总结

1.当前的zookeeper具有一致性，但是只有一个写入的leader，然后其他的flower直接leader的内存中的数据同步

2.所有的获取数据都是直接从当前的内存中获取的(所以速度快)

3.当前的写入中如果leader出现问题，那么就会用传递的那个flower进行替换leader做的任务

以上纯属个人见解，如有问题请联本人！