zookeeper-详述

Posted 2021-03-22 brucev

为什么使用Zookeeper？

1、 大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进 程（如资源、任务分配等）
2、 目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制 » 协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器
3、 ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用
Keepalived监控节点不好管理
Keepalive 采用优先级监控
没有协同工作
功能单一
Keepalive可扩展性差

zookeeper优点

特点 说明
最终一致性 为客户端展示同一个视图，这是zookeeper里面一 个非常重要的功能
可靠性 如果消息被到一台服务器接受，那么它将被所有的 服务器接受。
实时性 Zookeeper不能保证两个客户端能同时得到刚更新 的数据，如果需要最新数据，应该 在读数据之前调 用sync()接口。
独立性 各个Client之间互不干预 原子性 更新只能成功或者失败，没有中间状态。
顺序性 所 有Server，同一消息发布顺序一致。

zookeeper的工作原理，

1.每个Server在内存中存储了一份数据；
2.Zookeeper启动时，将从实例中选举一个leader（Paxos 协议）
3.Leader负责处理数据更新等操作
4.一个更新操作成功，当且仅当大多数Server在内存中成功修 改数据

zookeeper能帮我们做什么?

1、Hadoop,使用Zookeeper的事件处理确保整个集群只 有一个NameNode,存储配置信息等.
2、HBase,使用Zookeeper的事件处理确保整个集群只有 一个HMaster,察觉HRegionServer联机和宕机,存储 访 问控制列表等.

zookeeper的特性

1、Zookeeper是简单的
2、Zookeeper是富有表现力的
3、Zookeeper具有高可用性
4、Zookeeper采用松耦合交互方式
5、Zookeeper是一个资源库

Zookeeper的安装和配置（集群模式）

创建myid文件，server1机器的内容为：1，

server2 机器的内容为：2，

server3机器的内容为：3 ，

在conf目录下创建一个配置文件zoo.cfg，

 tickTime=2000
 dataDir=/Users/zdandljb/zookeeper/data
 dataLogDir=/Users/zdandljb/zookeeper/dataLog
 clientPort=2181 
 initLimit=5 
 syncLimit=2
 server.1=server1:2888:3888 
 server.2=server2:2888:3888 
 server.3=server3:2888:3888

tickTime：发送心跳的间隔时间，单位：毫秒 • dataDir：zookeeper保存数据的目录。 • clientPort：客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客 户端的访问请求。 • initLimit： 这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端不是用户连 接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的 时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表 明这个客户端连接失败。总的时间长度就是 52000=10 秒 • syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最 长不能超过多少个 tickTime 的时间长度，总的时间长度就是 22000=4 秒 • server.A=B：C：D：其 中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一 集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这 个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是 一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号
1、领导者（leader），负责进行投票的发起和决议，更 新系统状态
2、学习者（learner），包括跟随者（follower）和观察 者（observer），follower用于接受客户端请求并想 客户端返回结果，在选主过程中参与投票 ，Observer可以接受客户端连接，将写请求转发给 leader，但observer不参加投票过程，只同步leader 的状态，observer的目的是为了扩展系统，提高读取 速度
3、客户端（client），请求发起

原子广播模式

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协 议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者 崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后 ，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
• 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（ proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识 leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的 统治时期。低32位用于递增计数。
• 每个Server在工作过程中有三种状态：
• LOOKING：当前Server不知道leader是谁，正在搜寻
• LEADING：当前Server即为选举出来的leader
• FOLLOWING：leader已经选举出来，当前Server与之同步

zookeeper读写机制

1、Zookeeper是一个由多个server组成的集群
2、一个leader，多个follower
3、 每个server保存一份数据副本 » 全局数据一致
4、 分布式读写 » 更新请求转发，由leader实施
5、 更新请求顺序进行，来自同一个client的更新请求按其 发送顺序依次执行
6、 数据更新原子性，一次数据更新要么成功，要么失败
7、 全局唯一数据视图，client无论连接到哪个server，数据 视图都是一致的
8、实时性，在一定事件范围内，client能读到最新数据

Follower主要有四个功能：

1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消 息）；
   2 .接收Leader消息并进行处理；
   3 .接收Client的请求，如果为写请求，发送给Leader进行投票；
   4 .返回Client结果。
   Follower的消息循环处理如下几种来自Leader的消息：
   1 .PING消息： 心跳消息；
   2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；
   3 .COMMIT消息：服务器端最新一次提案的信息；
   4 .UPTODATE消息：表明同步完成；
   5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的 session还是允许其接受消息；
   6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制 得到最新的更新；

Zookeeper leader选举

半数通过 – 3台机器 挂一台 2>3/2 – 4台机器 挂2台 2！>4/2
1、A提案说，我要选自己，B你同意吗？C你同意吗？B说，我同意选A；C说，我同意选A。(注 意，这里超过半数了，其实在现实世界选举已经成功了。但是计算机世界是很严格，另外要 理解算法，要继续模拟下去。)
2、接着B提案说，我要选自己，A你同意吗；A说，我已经超半数同意当选，你的提案无效；C 说，A已经超半数同意当选，B提案无效。 • 接着C提案说，我要选自己，A你同意吗；A说，我已经超半数同意当选，你的提案无效；B 说，A已经超半数同意当选，C的提案无效。
3、选举已经产生了Leader，后面的都是follower，只能服从Leader的命令。而且这里还有个小 细节，就是其实谁先启动谁当头

zxid

1、znode节点的状态信息中包含czxid, 那么什么是zxid呢?
2、ZooKeeper状态的每一次改变, 都对应着一个递增的 Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果 zxid1小于zxid2, 那么zxid1肯定先于zxid2发生. 创建任意节点 , 或者更新任意节点的数据, 或者删除任意节点, 都会导致 Zookeeper状态发生改变, 从而导致zxid的值增加.
3、Zookeeper的核心是原子广播，这个机制保证了各个 server之间的同步。实现这个机制的协议叫做Zab协 议。Zab协议有两种模式，它们分别是恢复模式和广 播模式。当服务启动或者在领导者崩溃后，Zab就进 入了恢复模式，当领导者被选举出来，且大多数 server的完成了和leader的状态同步以后，恢复模式 就结束了。状态同步保证了leader和server具有相同 的系统状态。

Paxos数据一致性

据说Paxos算法的难理解与算法的知名度一样令人敬仰，所以我们先看如何保持数据的一致性，这里有个原则就是：
1、在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致 的状态。
2、 Paxos算法解决的什么问题呢，解决的就是保证每个节点执行相同的操作序列。好吧，这还不简单，master维护一个 全局写队列，所有写操作都必须 放入这个队列编号，那么无论我们写多少个节点，只要写操作是按编号来的，就能保证一 致性。没错，就是这样，可是如果master挂了呢。
3、 Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票， 只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一 轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排 序。编号严格递增，当一个节点接受了一个 编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己 数据 不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂 掉大于n台）。
4、 总结 Zookeeper 作为 Hadoop 项目中的一个子项目，是 Hadoop 集群管理的一个必不可少的模块，它主要用来控制集群 中的数据，如它管理 Hadoop 集群中的 NameNode，还有 Hbase 中 Master Election、Server 之间状态同步等。
更生动的例子参考：屁民的故事

zookeeper节点

1、 Znode有两种类型，短暂的（ephemeral）和持久的（persistent）
2、 Znode的类型在创建时确定并且之后不能再修改 » 短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短 暂znode不可以有子节点 » 持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode 时才会被删除

Znode有四种形式的目录节点

1、 PERSISTENT （永久节点）
2、 EPHEMERAL（临时节点）
3、 PERSISTENT_SEQUENTIAL（永久有序节点）
4、 EPHEMERAL_SEQUENTIAL（临时有序节点）

Watcher

Watcher 在 ZooKeeper 是一个核心功能，Watcher 可以 监控目录节点的数据变化以及子目录的变化，一旦这 些状态发生变化，服务器就会通知所有设置在这个目 录节点上的 Watcher，从而每个客户端都很快知道它所 关注的目录节点的状态发生变化，而做出相应的反应 ； 可以设置观察的操作：exists,getChildren,getData ；可以触发观察的操作：create,delete,setData