Zookeeper--基本概念

ZooKeeper是用于分布式系统的高性能协调服务，通过简单的接口提供了命名服务，配置管理，同步和组服务等常用服务。 ZooKeeper是分布式的，开放源码的，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。

 

角色：

Zookeeper分为服务端和客户端，客户端连接到服务端的某台机器上，通过维护一个TCP连接发送请求，接受请求，发送心跳和获取观察的事件。如果该连接中断，客户端尝试连接到其他服务端。启动服务端集群后，集群中的服务器首先选举一个Leader，然后进入工作，当Leader机器崩溃后，剩下正常的机器会继续选举，Leader的作用是保证数据的一致性。

在ZooKeeper服务侧集群当中有两种角色Leader和Follower。Leader可以接受client请求，也接收其他Server转发的写请求，负责更新系统状态。 Follower也可以接收client请求，如果是写请求将转发给Leader来更新系统状态，读请求则由Follower的内存数据库直接响应。在zk的3.3.3版本以后，又添加了一种新角色Observer。Observer的作用同Follower类似，唯一区别就是它不参与选主过程。

 

特性：

1.最终一致性：客户端无论连接到哪个服务端，获取到的数据都一致。

2.实时性：客户端在一个时间范围内总能获取到服务端的更新信息或失效信息。

3.原子性：数据的更新只能是成功的或失败的。

4.顺序性：所以数据的更新请求都是单调有序的。

 

数据模型：

Zookeeper数据模型类似文件系统的目录树结构，特点如下：

1.每个节点（znode）被其所在的路径唯一标识，如/Apps/App1。

2.znode可以存储数据，EPHEMERAL类型节点没有子节点。

3.znode有版本，即znode中的数据有版本。

4.znode名称可以自动编号，即如果App1存在，再创建的节点会自动命名为App2

5.临时znode在失去连接的时候自动删除。

6.客户端服务端保持长连接，一个连接状态称为session，session失效了，临时节点就会自动删除。

7.任何znode的变化都可被监控，包括数据的变化和子节点的变化。当监控到变化，监控者（客户端）被通知，执行回调方法。

 

工作原理：

Zookeeper核心机制是原子广播，它保证了个服务端之间的数据同步。Zab协议保证了这一点。

Zookeeper有两种工作模式：恢复模式和广播模式。当服务启动时和Leader崩溃后进入恢复模式，恢复模式下Zookeeper进行leader选举，耗时在200ms内。当Leader被选举出来，且大多数服务器与Leader完成诗句同步后，ZK进入广播模式。为了保证事务的顺序一致性，ZK采用了递增的事务ID（zxid）来标识事务。

所有的提议都会被加上zxid，zxid为64位的数字，高32位是epoch用来标识leader是否改变的每一次leader选举出来都有一个新的epoch。zxid低32位用来递增计数。

每个服务器在工作中有3个状态：

Looking：当前服务器不知道谁是leader，搜索中。

Leading：当前服务器即为leader，领导中。

Following：当前服务器不是leader，正在与leader同步中。

 

同步流程：

1.leader等待服务器连接。

2.follower连接Leader，将最大的zxid发送给leader。

3.Leader根据follower的zxid确定同步点。

4.同步后通知follower成为uptodate状态。

5.follower收到uptodate消息后，同步完成。

 

leader工作流程：

leader功能：恢复数据，保持心跳，相应消息

leader可响应的消息有PING，REQUEST，ACK和REVALIDATE

PING即心跳消息，REQUEST为follower发送的提议（写请求或同步请求），ACK是follower对提议的回复，超过半数的follower通过，则commit。REVALIDATE为延长session的请求。

 

follower工作流程：

向leader发送请求并响应。

接受client请求并响应，接受写请求时发送给leader处理。

follower可响应的请求：

PING：发送心跳信息

PROPOSAL：leader发起的提案，follower投票

Commit：提议被commit

UPTODATE：同步完成

REVALIDATE：延长session的响应

SYNC：客户端发起，强制返回更新的数据

 

 

 

 

 

 

end