Zookeeper 分布式协调服务 概念及原理介绍

技术背景

随着信息化水平的不断提高，企业级系统变得越来越庞大臃肿，性能急剧下降，客户抱怨频频。拆分系统是目前我们可选择的解决系统可伸缩性和性能问题的唯一行之有效的方法。但是拆分系统同时也带来了系统的复杂性——各子系统不是孤立存在的，它们彼此之间需要协作和交互，这就是我们常说的分布式系统。各个子系统就好比动物园里的动物，为了使各个子系统能正常为用户提供统一的服务，必须需要一种机制来进行协调——这就是ZooKeeper(动物园管理员)

设计目的

用来解决[分布式集群中应用系统的一致性问题]

设计思想

通过特殊的主从分布式架构系统来解决一致性问题

• 解释：特殊： 各个子节点也接受客户端请求，区别于别的主从分布式架构

技术本质

分布式小文件存储系统

• 概念：zookeeper实际上是一个分布式小文件存储系统
• 解释：
  • 分布式： 即将多台机器的物理资源通过软件程序进行整合为一个整体虚拟资源的环境,例如有10台 1核/2G内存/1T硬盘的机器，通过分布式系统即可整合成为1台具有 10核/20G内存/10T硬盘的虚拟机器。然后通过此系统进行资源管理和任务拆分。
  • 小文件： zk的设计目的是用来解决分布式集群中应用系统的一致性问题，虽然也属于一个存储系统，但是他并不是为了专门做存储数据的目的，而是为了通过存储集群的元数据来管理集群。集群元数据信息并不需要很大，所以zk被设计为可以存储小文件 一般为Kb，最多不可超过1Mb
  • 存储系统： 上面提到过zk需要通过存储集群的元数据来管理集群，那么个人理解存储数据的方式目前有[内存/文件/dbms(数据库管理系统) 当然dbms最终也是通过文件来存储数据]。内存不安全，易丢失。而数据库则显得比较笨重,不如直接通过文件来存储，自己管理，不需要dbms。

类目录树结构方式数据存储

• 概念：zookeeper的数据存储是以类目录树方式进行的
• 解释：
  • 文件系统：文件系统具有文件和文件夹两种内容，文件负责存储数据，文件夹可以递归拥有子文件和子文件夹，又同时负责区分路径，同一个文件夹下不允许拥有同名文件，即保证每个文件的路径唯一。
  • 目录树：即指文件系统的目录结构，一般采用树形层次结构，故称之为目录树
  • 类目录树： 即类似于目录树结构，既有相同之处，又有不同之处

核心特性

• 全局数据一致性

  • 解释：
    整个集群中，每个节点保存的数据都是一样的，故称全局一致。
    如何保证 全局数据一致性的呢？
    因为所有的事务性操作都会由leader统一处理,再由leader进行数据同步，即zab协议；

• 可靠性

  • 解释：
    leader发出的消息如果被一台服务器接受，那么将被所有的服务器接受。

• 顺序性

  • 解释：
    • 全局有序： 所有事务性操作都在leader上进行，leader保证了事务的有序性
    • 偏序： leader将消息同步给follower，

• 数据更新原子性

  • 解释：
    数据更新要么成功（半数节点以上更新成功），要么失败，不存在中间状态

集群角色

leader

• 概念：领导者，主节点

• 功能：
  1.按时间顺序负责整个集群事务性请求的任务调度，以保证集群事务处理的顺序性
  2.负责处理集群非事务性请求，以及事务性请求并同步数据给从节点

follower

• 概念：跟随者
• 功能：
  1. 负责处理集群非事务性请求
  2. 转发事务性请求给leader
  3. 参与集群的leader选举

observer

• 概念：观察者，针对访问量较大的集群才有的角色
• 功能：
  1.功能基本同follower但是没有选举和被选举权利，
  2.只是用来提升集群的非事务请求处理能力

选举机制

• 概念：zookeeper的选举机制分为初次选举和恢复选举

选举状态

LOOKING，竞选状态。
FOLLOWING，随从状态，同步leader状态，参与投票。
OBSERVING，观察状态,同步leader状态，不参与投票。
LEADING，领导者状态。

初次选举

• 概括：初次选举以得票最多，id最大为主

• 内容：
  1- 每个节点都是自私的，先把选票投给自己
  2- myid越大，权重越大
  3- 得票过半选举结束

• 解释：
  每个节点顺序启动后，先投出自己的myid，然后对比出其余节点的myid，每个节点启动后，都会进行新一轮的投票，此时已经参与过一次投票的，就会选举自己认为的最大的那个节点id，第一次参与投票的，还是投给自己，最后统计出自己myid的得票数

  e.g-1: 集群启动顺序myid为 1 4 2 3 5 那么1启动后投给myid 1, 其余节点未启动,统计myid 1 得票数 为 1；4启动后投给myid 4 ,统计其他已经启动的节点 4 > 1,则myid 4 得票数 为 2 ,myid 1 得票数 为 1；2 启动后 投给myid 2，统计其他已经启动的节点 4 > 2 > 1,则myid 4 得票数 为 3，myid 2 得票数 为 2，myid 1得票数 为 1； myid 4 得票数 为 3 已经超过半数，被选举为leader 集群选举结束.

  e.g-2: 集群启动顺序myid为 1 2 4 3 5 那么1启动后投给myid 1, 其余节点未启动,统计myid 1 得票数 为 1；2 启动后 投给myid 2，统计其他已经启动的节点 2 > 1,则myid 2 得票数 为 2，myid 1得票数 为 1；4 启动后 投给myid 4，统计其他已经启动的节点 4 > 2 > 1,则myid 4 得票数 为 3，myid 2 得票数 为 2，myid 1得票数 为 1；myid 4 得票数 为 3 已经超过半数，被选举为leader 集群选举结束.

恢复选举

• 概括：当主节点挂掉之后,恢复选举目的是为了优中择优
• 内容：
  1- 数据最新： 时间戳或数据版本号
  2- 健康状态良好: 逻辑时钟
  3- myid最大
• 解释：
  先比较每个节点的数据状态是不是最新的，通过zxid，dataversion等标志，zxid或dataversion越大表示该数据越新，再比较健康状态，通过比较逻辑时钟，逻辑时钟是每参与一次投票，逻辑时钟就会增加一次，数值越大表示节点越健康，最后再比较myid；

原子广播

• 介绍：
  zookeeper的核心是原子广播，这个机制保证了zookeeper的每个server 之间的同步，实现原子广播的是Zab协议，Zab协议有恢复和同步两种模式，恢复模式是选举leader、同步模式是保证leader和各个server之间状态同步
• 概括：
  原子广播是一种以zab协议为基础，保证了leader与follower之间状态同步及leader恢复的机制

Znode结构

• 介绍：
  znode结构是一种类目录树结构，每个znode既具有文件夹的功能（每个节点可以拥有子节点，路径标识），又具有文件的功能（可以存储数据、元数据，ACL访问控制列表,时间戳）

节点类型

• 介绍：节点类型可以分为 /有序SEQUENTIAL/无序 ;
  临时EPHEMERAL/永久PERSISTENT 4种组合；

• 补充：临时节点不允许拥有子节点，临时节点是会话级别的。会话结束后不会立马删除，而是在固定的时间间隔后自动删除；永久节点需要客户端手动显示执行删除操作才会被删除；有序的序列号对于该父节点下唯一的，用来记录该父节点下每个子节点创建的先后顺序.

节点属性

• version 版本号
  dataVersion，cversion(子节点版本号)，aversion(ACL版本号)
• Zxid
  cZxid(节点创建时间)，mZxid(节点修改时间)，pZxid(子节点最新更改时间)，ctime,mtime,
  ephemeralOwner (如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id. 如果不是,ephemeralOwner值为0)

路径标识

都是以斜杠字符开头，每个路径标识是唯一的，其中/zookeeper 是默认初始创建的。这里保存了zk集群的管理信息

Watcher机制

• 概念：监听机制，类似于发布订阅功能，即被监听节点发生变化时，会通知所有监听者。
• 补充：
  1. 先注册再触发，
  2. 一次性（只会触发一次），
  3. 异步发送，
  4. 事件封装WatchedEvent有三个属性（keeperStat，EventType，path）

分布式锁

• 概念： zookeeper的分布式锁分为独占锁和控制时序锁

独占锁

zookeeper保证只有一个进程可以成功创建znode，谁成功创建了这个znode，谁就拥有此锁，通过sessionid

控制时序锁

创建临时有序的节点，谁的序号小，即谁创建的时间早，谁就拥有此锁，释放锁即删除此锁

相关端口

2181 节点通讯端口
2888 节点心跳端口
3888 节点选举端口

Zookeeper介绍补充

• 介绍： zk和一般的集群具有不同之处，所有被称为特殊的主从模式集群
• 解释：
  1. 一般主从集群，主节点和从节点是不同的进程，从节点不能转换成为主节点，主节点存在spof问题，需要主备机制来保证集群的高可用，但是zk不一样，zk集群的从节点当主节点下线以后，从节点可以通过选举机制来成为主节点
  2. 一般主从集群，都是主节点来接收客户端请求，从节点进行处理，从节点不负责接收客户端请求，但是zk不一样，zk集群的主从节点都可以接收客户端请求，但是只有主节点负责处理写请求，从节点负责处理读请求，实现读写分离
  3. 一般主从集群，各个从节点上存储的数据是不一样的，为分布式的文件块，各个节点上的文件块组成一个整体文件。但是zk不一样，zk集群各个节点是数据同步的，即通过原子广播协议，将数据的写操作全部广播到各个节点上，各个节点上到数据都是一个整体，都是一样的