Zookeeper架构浅析

一、架构

Zookeeper架构浅析

部分	描述
Client	分布式应用程序集群中的一个节点，连接服务器进行访问。对于特定的时间间隔，客户端向服务器端发送消息已使服务器知道客户端还活着。相反，当客户端连接时，服务器会发送确认，若服务器无响应，则客户端会自动将消息重定向到另一个服务器。
Server	服务器，Zookeeper集群中的一个节点，为客户端提供所有的服务。向客户端发送确认，表示服务器处于活跃状态。
Zookeeper Service	Zookeeper服务器组。最少需要3个节点。
Leader	服务器节点，在服务启动时被选举出来
Follower	服务器节点

二、实现

Zookeeper架构浅析

组件	描述
Write	写请求由leader节点处理，leader节点将请求转发到所有znode，并等待znode响应，若有一半响应，则写入完成。
read	读请求由连接到znode节点处理，不需要与集群交互
Replicated Database	复制数据库，用于在zookeeper中存储数据，每个znode都有自己的数据库，且所有znode的数据库保持一致
Leader	负责处理写请求
Follower	处理读请求或从客户端接收写请求并转发到Leader
Request Processor	请求处理器，位于Leader节点
Atomic Broadcast	原子广播，负责Leader到Follower节点之间的变化广播

三、分层命名空间

Zookeeper架构浅析

Zookeeper的节点称为znode，每个znode都有一个名称标识。每个znode中都维护着一个stat结构，它由版本号、操作控制列表(ACL)、时间戳和数据长度组成。

版本号：每个znode都有一个版本号，当数据发生更改时，版本号随之增加。

操作控制列表(ACL)：ACL基本上访问znode的认证机制，管理所有znode读取和写入操作。

时间戳：znode创建和修改的时间

数据长度：存储在znode中的数据总量的数据长度，最多1M。

持久型：默认创建的节点为持久性，即当创建改znode的客户端断开连接仍然存在

临时型：即客户端断开连接后改znode自动删除，不允许有孩子节点？

顺序型：顺序znode可以为持久型或短暂型(临时型)。当一个新的znode被创建为一个顺序znode，则Zookeeper将会附加一个10位的***到gaiznode名称后面。副/myapp0000000001，序号唯一。

客户端连接到服务器的时候，服务器会分配一个唯一的会话ID，同时发送确认到客户端。若服务器未响应，则客户端将会尝试连接下一个服务器。会话中的请求按FIFO的顺序执行。

一种简单的机制，使客户端收到关于zookeeper集群中的更改通知。客户端可以在znode上设置监视(watch)，当znode更改时，将触发并删除监视，此时客户端会收到一个数据包，说明znode已更改。若想继续收到更改通知，需再次设置监视。

参考：