Zookeeper学习系列【三】Zookeeper 集群架构、读写机制以及一致性原理(ZAB协议)

前言

同学们，在上一章中，我们主要讲了Zookeeper两种启动模式以及具体如何搭建。本章内容主要讲的是集群相关的原理内容，第一章可以当做是Zookeeper原理篇的基础部分，本章则是Zookeeper原理篇进阶部分，有关于Zookeeper集群的读写机制、ZAB协议的知识解析。

本篇的内容主要包含以下几点：

• Zookeeper 集群架构
• **Zookeeper 读写机制 **
• ZAB协议
• 关于Zookeeper 集群的一些其他讨论
  • Zookeeper（读性能）可伸缩性 和 Observer节点
  • Zookeeper 与 CAP 理论
  • Zookeeper 作为 服务注册中心的局限性

一、Zookeeper 集群架构

接下来我们来说一说Zookeeper的集群架构。

Zookeeper 集群中的角色

第一章提过，Zookeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。

• Leader 领导者 ：Leader 节点负责Zookeeper集群内部投票的发起和决议（一次事务操作），更新系统的状态；同时它也能接收并且响应Client端发送的请求。
• Learner 学习者
  • Follower 跟随者 ： Follower 节点用于接收并且响应Client端的请求，如果是事务操作，会将请求转发给Leader节点，发起投票，参与集群的内部投票，
  • Observer 观察者：Observer 节点功能和Follower相同，只是Observer 节点不参与投票过程，只会同步Leader节点的状态。
• Client 客户端

Zookeeper 通过复制来实现高可用。在上一章提到的集群模式（replicated mode）下，以Leader节点为准，Zookeeper的ZNode树上面的每一个修改都会被同步（复制）到其他的Server 节点上面。

上面实际上只是一个概念性的简单叙述，在看完下文的读写机制和ZAB协议的两种模式之后，你就会对这几种角色有一个更加深刻的认识。

<