为什么用Zookeeper
官方地址：https://zookeeper.apache.org/doc/current/zookeeperOver.html
redis不能保证实时一致性和强一致性（最终一致性）
ZooKeeper实施对高性能，高可用性，严格排序的访问给予了高度重视
- ZooKeeper的性能方面意味着它可以在大型的分布式系统中使用
- 可靠性方面使它不会成为单点故障
- 严格的排序意味着可以在客户端上实现复杂的同步原语
组成ZooKeeper服务的服务器都必须彼此了解
- 它们维护内存中的状态图像，以及持久存储中的事务日志和快照
- 只要大多数服务器可用，ZooKeeper服务将可用
客户端连接到单个ZooKeeper服务器
- 客户端维护一个TCP连接，通过该连接发送请求，获取响应，获取监视事件并发送心跳
- 如果与服务器的TCP连接断开，则客户端将连接到其他服务器
ZooKeeper已订购
- ZooKeeper用一个反映所有ZooKeeper事务顺序的数字标记每个更新
- 后续操作可以使用该命令来实现更高级别的抽象，例如同步原语
ZooKeeper速度很快
- 在“读取为主”的工作负载中，它特别快
- ZooKeeper应用程序可在数千台计算机上运行，
- 并且在读取比写入更常见的情况下以10:1的比率运行时效果最佳
节点和短暂节点
- 与标准文件系统不同，ZooKeeper命名空间中的每个节点都可以具有与其关联的数据以及子节点
- 就像拥有一个文件系统一样，该文件系统也允许文件成为目录
- ZooKeeper旨在存储协调数据：状态信息，配置，位置信息等，因此存储在每个节点上的数据通常很小，在字节到千字节范围内
我们使用术语znode来明确表示在谈论ZooKeeper数据节点
Znodes维护一个统计信息结构，其中包括用于数据更改，ACL更改和时间戳的版本号，以允许进行缓存验证和协调更新
- znode的数据每次更改时，版本号都会增加
- 例如，每当客户端检索数据时，它也接收数据的版本
- 原子地读取和写入存储在名称空间中每个znode上的数据
- 读取将获取与znode关联的所有数据字节，而写入将替换所有数据
- 每个节点都有一个访问控制列表（ACL），用于限制谁可以执行操作
ZooKeeper短暂节点
- 只要创建znode的会话处于活动状态，这些znode就存在
- 会话结束时，将删除znode
有条件的更新和监视
- ZooKeeper支持watches的概念
- 客户端可以在znode上设置watches
- znode更改时，将触发并删除监视
- 触发监视后，客户端会收到一个数据包，说明znode已更改
- 如果客户端和其中一个ZooKeeper服务器之间的连接断开，则客户端将收到本地通知
ZooKeeper非常快速且非常简单
同时提供了一组保证
- 顺序一致性，来自客户端的更新将按照发送的顺序应用
- 原子性，更新成功或失败，没有部分结果
- 单个系统映像，无论客户端连接到哪个服务器，客户端都将看到相同的服务视图
- 即使客户端故障转移到具有相同会话的其他服务器，客户端也永远不会看到系统的较旧视图
- 可靠性，应用更新后，此更新将一直持续到客户端覆盖更新为止
- 及时性，保证系统的客户视图在特定时间内是最新的
简单的API
- create : creates a node at a location in the tree
- delete : deletes a node
- exists : tests if a node exists at a location
- get data : reads the data from a node
- set data : writes data to a node
- get children : retrieves a list of children of a node
- sync : waits for data to be propagated
Zookeeper执行过程
复制的数据库是包含整个数据树的内存数据库
- 将更新记录到磁盘以确保可恢复性，并且将写入操作序列化到磁盘之后再将其应用于内存数据库
每个ZooKeeper服务器都为客户端提供服务
- 客户端仅连接到一台服务器即可提交请求
- 读取请求从每个服务器数据库的本地副本提供服务
- 更改服务状态的请求（写请求）由协议协议处理
- 作为协议协议的一部分，来自客户端的所有写请求都转发到称为领导者的单个服务器
- 其余的ZooKeeper服务器（称为跟随者）从领导者接收消息建议并同意消息传递
- 消息传递层负责替换出现故障的领导者，并将跟随者与领导者同步
ZooKeeper使用自定义的原子消息传递协议
- 由于消息传递层是原子层，因此ZooKeeper可以保证本地副本永远不会发散
- 当领导者收到写请求时，它将计算要应用写操作时系统的状态，并将其转换为捕获该新状态的事务