zookeeper 的设计目标

为什么有zookeeper

问题: 大流量大吞吐->分布式系统->分布式系统存在调度、一致性问题->分布式协调服务

多进程协作的共性问题伶出，作为基础设施，可更加专注业务逻辑开发

不同的状态在复杂业务场景下的多重组和就会导致千差万别的结果。日益庞大的服务器，需要一个优异的管理者来进行管理。

在诸多的分布式框架之中，zookeeper又是表现极为良好的一种。

zookeeper是最常用的分布式协调服务，它能够解决大多数的集群问题，包括发布/订阅、负载均衡、命令服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等。同时针对集群资源管理的需求，又衍生了Hadoop YARN

zookeeper设计目标

设计目的

• 最终一致性：无论client连接到哪个server，展示的都是同一个视图，这是zookeeper最重要性能。
• 顺序一致性：从一个客户端发起的事务请求，最终都会严格按照其发起顺序被应用到zookeeper中。
• 原子性:所有事务请求的处理结果在整个集群中所有机器上都是一致的；不存在部分机器应用了该事务，而另一部分没有应用的情况。
• 单一视图：所有客户端看到的服务端数据模型都是一致的。
• 可靠性：一旦服务端成功应用了一个事务，则其引起的改变会一直保留，直到被另外一个事务所更改。

数据节点

zookeeper是由一系列基本数据单元Znode(数据节点)组成的节点树，其根节点为/。每个节点上都会保存自己的数据和节点信息。zookeeper中节点可以分为两大类：

• 持久节点：节点一旦创建，除非被主动删除，否则一直存在；
• 临时节点：一旦创建该节点的客户端会话失效，则所有该客户端创建的临时节点都会被删除。(宕机同样自动删除)

临时节点和持久节点都可以添加一个特殊的属性：SEQUENTIAL,代表该节点是由具有递增属性。如果指定该属性，那么在这个节点创建时，zookeeper会自动在其节点名称后面追加一个由父节点维护的递增数字。

节点的一些属性值

每个ZNode节点在存储数据的同时，都会维护一个叫做Stat的数据结构，里面存储了关于该节点的全部状态信息

• czxid:数据节点创建时的事务ID
• ctime:数据节点创建时的时间
• numChildren:数据节点当前子节点个数
• mzxid:数据节点最后一次更新时的事务
• IDmtime:数据节点最后一次更新时的时间
• pzxid:数据节点的子节点最后一次被修改时的事务
• IDcversion:子节点的更改次数
• version:节点数据的更改次数
• aversion:节点的ACL的更改次数
• ephemeralOwner:如果节点时临时节点，则表示创建该节点的会话SessionId;如果节点时持久节点，则该属性值为0
• dataLength:数据内容的长度

集群角色

zookeeper集群中的机器分为以下三种角色：

• Leader:提供读写服务，并维护集群状态，由集群选举产生；
• Follower:提供读写服务，并定期向Leader汇报自己的节点状态。同时参与写操作"过半写成功"策略和Leader的选举；
• Observer:为客户端提供读写服务，并定期向Leader汇报自己的节点状态，但不参与写操作"过半写成功"策略和Leader选举，因此Observer可以在不影响写性能的情况下提升集群的读性能。

ACL(权限)

zookeeper采用ACL(Access Control Lists)策略来进行权限控制，类似于UNIX文件系统的权限控制。它定义了如下五种权限:

• CREATE:允许创建子节点
• READ:允许从节点获取数据并列出其子节点；
• WRITE:允许为节点设置数据
• DELETE:允许删除子节点
• ADMIN:允许为节点设置权限

用途

• 简单的数据模型

树形结构来存储数据，它由一些列被称为ZNode的数据节点组成，数据全量存储在内存中，以此来实现高吞吐，减少访问延迟。默认存储1M

• 构建集群
  由Zookeeper服务构成集群，每台机器都会单独在内存中维护自身的状态，且机器之间都保持着通讯，只要有半数机器能够正常工作，那么集群都可以正常提供服务。

• 顺序访问

客户端的每个更新请求，Zookeeper都会分配一个全局唯一的递增ID，ID保证事务请求的先后顺序

• 高性能高可用

数据全量存储在内存中保持高性能，通过集群来实现高可用，由于Zookeeper的所有更新和删除都是基于事务的，所以其在读多写少的应用场景中有着很高的性能表现。

ZBA协议与数据一致性

ZBA协议是zookeeper专门支持崩溃恢复的原子广播协议。zookeeper主从模式的系统架构通过ZAB保持集群中的各个副本之间数据的一致性。zookeeper使用单一的主进程来接收、处理客户端的所有事务请求，采用原子广播协议将数据状态的变更以事务Proposal的形式广播到所有的副本进程上去。

具体流程

所有的事务请求必须由唯一的Leader服务来处理，Leader服务将事务请求转换为事务Proposal，并将该Proposal分发给集群中所有的Follower服务。如果有半数的Follower服务进行了正确的反馈，那么Leader就会再次向所有的Follower发出Commit消息，要求将前一个Proponsal进行提交。