Zookeeper学习笔记

概述

分布式协调服务框架。与操作系统相同的是，均是通过不同进程访问共享资源。操作系统通过pv操作上锁，而解决不同的主机也要互斥访问共享文件的问题，是通过网络，即用zookeeper。

Zookeeper主要用来解决分布式集群中应用系统的一致性问题和数据管理问题。

zookeeper的特点

分布式文件系统：多台主机进行整合成一个统一的文件系统，对外提供路径直接访问。也可理解为数据库。

• 在上图左侧, Zookeeper 中存储的其实是一个又一个 Znode, Znode 是 Zookeeper 中的节点

  • Znode 是有路径的, 例如 /data/host1, /data/host2, 这个路径也可以理解为是 Znode 的 Name
  • Znode 也可以携带数据, 例如说某个 Znode 的路径是 /data/host1, 其值是一个字符串 "192.168.0.1"

• 正因为 Znode 的特性, 所以 Zookeeper 可以对外提供出一个类似于文件系统的试图, 可以通过操作文件系统的方式操作 Zookeeper

  • 使用路径获取 Znode

  • 获取 Znode 携带的数据

  • 修改 Znode 携带的数据

  • 删除 Znode

  • 添加 Znode

zookeeper的架构

基于主从结构的高可用集群。（思想：读写分离）

有一个主服务器leader，其他服务器为follwer。
每个服务器承担以下三种角色。

• Leader一般只有一个，会发起并维护follower和observer间的心跳。所有的写操作必须通过leader完成再由leader将写操作广播给其他服务器。集群核心 负责投票选取 处理写操作请求 参与集群投票
• Follwer 一个集群存在多个follawer，响应leader的心跳。接收并向客户端返回结果 处理读操作请求 转发事务请求给leader 参与集群投票
• Observer角色与Follower类似，但是没有投票权。和follower类似，但不参与投票 扩展follower的功能，增加集群的处理能力。

zookeeper的应用场景

数据发布/订阅

类似于网络中的关注，发布者将数据发布到节点上，供订阅者进行数据订阅。
一般的发布/订阅有两种模式，推模式和拉模式。推模式即服务器主动将数据更新推送到订阅客户端。客户端主动要求获取最新数据为拉模式。
zookeeper采用推拉结合的模式，客户端向服务端注册需要关注的节点，watch机制一直处于监听状态。一旦数据变更，watch机制就发给响应的客户端推送Watcher事件通知，客户端接收通知后，主动到服务端获取最新的数据。

命名服务

客户端可以根据指定的名字来获取资源实体。通过唯一路径来获取资源。可以实现分布式全局唯一ID的分配机制。树状图机制。
　通过调用Zookeeper节点创建的API接口就可以创建一个顺序节点，并且在API返回值中会返回这个节点的完整名字，利用此特性，可以生成全局ID，其步骤如下

1. 客户端根据任务类型，在指定类型的任务下通过调用接口创建一个顺序节点，如"job-"。

2. 创建完成后，会返回一个完整的节点名，如"job-00000001"。

3. 客户端拼接type类型和返回值后，就可以作为全局唯一ID了，如"type2-job-00000001"。

分布式协调/通知

Zookeeper中特有的Watcher注册于异步通知机制，能够很好地实现分布式环境下不同机器，甚至不同系统之间的协调与通知，从而实现对数据变更的实时处理。通常的做法是不同的客户端都对Zookeeper上的同一个数据节点进行Watcher注册，监听数据节点的变化（包括节点本身和子节点），若数据节点发生变化，那么所有订阅的客户端都能够接收到相应的Watcher通知，并作出相应处理。
在绝大多数分布式系统中，系统机器间的通信无外乎[心跳检测、工作进度汇报和系统调度]。

• 心跳检测：不同机器需要检测彼此是否正常运行，可以使用zookeeper实现机器间的心跳检测，基于临时节点特性（生存周期是客户端会话，客户端若宕机，临时节点不复存在），可以让不同机器在zookeeper的一个指定节点下创建子节点，不同机器根据临时节点来判断客户端机器是否存活，可以大大减少系统耦合。
  
• 工作进度汇报：实时将任务执行进度给分发系统，可以在zookeeper上选择一个节点，每个任务客户端都在这个节点下面创建临时子节点，不仅判断机器存活，还将任务执行进度写到临时节点中，以便中心系统能实时获取任务的执行进度。
• 系统调度：服务器与客户端之间的相应的业务逻辑，指令操作。

分布式锁

分为排他锁和共享锁。

• 排他锁又称为写锁或者独占锁。若事务T1对数据对象O1加了排他锁，这只允许事务T1对O1进行读取和更新，直到T1释放。

　① 获取锁，在需要获取排它锁时，所有客户端通过调用接口，在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。Zookeeper可以保证只有一个客户端能够创建成功，没有成功的客户端需要注册/exclusive_lock节点监听。

② 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此时，所有在/exclusive_lock节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获取。

• [共享锁又称为读锁]，若事务T1对数据对象O1加上共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。在需要获取共享锁时，所有客户端都会到/shared_lock下面创建一个临时顺序节点。
  

分布式队列

有一些时候，多个团队需要共同完成一个任务，比如，A团队将Hadoop集群计算的结果交给B团队继续计算，B完成了自己任务再交给C团队继续做。这就有点像业务系统的工作流一样，一环一环地传下 去.

分布式环境下，我们同样需要一个类似单进程队列的组件，用来实现跨进程、跨主机、跨网络的数据共享和数据传递，这就是我们的分布式队列。

Zookeeper的选举机制

Leader选举是保证分布式[数据一致性]的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。

服务器启动时期的Leader选举

若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下

(1) 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid（相当于服务器编号，值越大，权利越大，越占优势）和ZXID（事务ID，值越大，数据越新，越占优势），使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。

(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下

· 优先检查ZXID。ZXID比较大的服务器优先作为Leader。

· 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。

对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。

(5) 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。

服务器运行时期的Leader选举

在Zookeeper运行期间，Leader与非Leader服务器各司其职，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致过程相同。

zookeeper的安装

zookeeper伪集群的安装
集群规划

服务器IP	主机名	myid的值
127.0.0.1:2222:2223	server.1	1
127.0.0.1:3333:3334	server.2	2
127.0.0.1:4444:4445	server.3	3

集群启动的时候会去zoo.cfg配置文件的dataDir目录下查找myid，检查编号是否一致。

关于为何zookeeper集群集群必须至少3个节点机器的原因，是因为zookeeper集群提供服务的机制决定的。zookeeper集群认为超多半数集群内部机器正常，就认为集群是正常的，可对外提供协调服务。