大数据入门之Zookeeper相关

Zookeeper相关

简介

Zookeeper是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

Zookeeper相当于一个文件系统加上通知机制

特点

Zookeeper：一个领导者（Leader，多个跟随者（Follower组成的集群。
集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。
全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行。
数据更新原子性，一次数据更新要么成功，要么失败。
实时性，在一定时间范围内，Client能读到最新数据。

Zookeeper的数据模型

Zookeeper的数据模型采⽤的与Unix⽂件系统类似的层次化的树形结构。我们可以
将其理解为⼀个具有⾼可⽤特征的⽂件系统。这个⽂件系统中没有⽂件和⽬录，⽽是
统⼀使⽤"节点"(node)的概念，称之为znode。znode既可以作为保存数据的容器(如
同⽂件),也可以作为保存其他znode的容器(如同⽬录)。所有的znode构成了⼀个层次
化的命名空间。

Zookeeper的安装步骤

1. 将zookeeper-3.4.10.tar.gz上传到/root中
2. 解压
3. 更名为zookeeper
4. 配置环境变量
5. source当前会话
6. 检查

配置文件参数

tickTime=2000： 通信心跳数， Zookeeper 服务器与客户端心跳时间，单位毫秒

Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。

它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。 (session的最小超时时间是2*tickTime)
initLimit=10： LF 初始通信时限

集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。
syncLimit=5： LF 同步通信时限

集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime， Leader认为Follwer死掉，从服务器列表中删除Follwer。
dataDir：数据文件目录+数据持久化路径

主要用于保存 Zookeeper 中的数据。
clientPort =2181：客户端连接端口

监听客户端连接的端口。

选举机制

说明：

1. 基于节点在半数以上才能正常服务的要求，Zookeeper适合装在奇数台机器。
2. Zookeeper没有在配置⽂件中指定leader和follower，⽽是使⽤算法(Paxos)在内部通过选举机制来选择⼀个节点为leader，其他节点为follower。

开机启动时的选举过程：
假设有五台服务器组成的 zookeeper 集群，它们的 id 从 1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这⼀点上，都是⼀样的。假设这些服务器依序启动，来看看会发⽣什么。

1. 服务器1启动
   此时只有它⼀台服务器启动了，它发出去的投票信息没有任何响应，所以它的选举状态⼀
   直是 LOOKING 状态。
2. 服务器2启动
   它与最开始启动的服务器 1 进⾏通信，互相交换⾃⼰的选举结果，由于两者都没有历史
   数据，所以 id 值较⼤ 的服务器 2 胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例⼦中的
   半数以上是 3)，所以 服务器 1、 2 还是继续保持LOOKING 状态。
3. 服务器3启动
   根据前⾯的理论分析，服务器 3 成为服务器 1、 2、 3 中的⽼⼤，⽽与上⾯不同的
   是，此时有三台服务器选
   举了它，所以它成为了这次选举的 leader。
4. 服务器4启动
   根据前⾯的分析，理论上服务器 4 应该是服务器 1、 2、 3、 4 中最⼤的，但是由于
   前⾯已经有半数以上的
   服务器选举了服务器 3，所以它只能接收当⼩弟的命
   了。
5. 服务器5启动
   同 4 ⼀样当⼩弟

选举机制中的概念

Leader:Zookeeper 集群⼯作的核⼼。
事务请求（写操作） 的唯⼀调度和处理者，保证集群事务处理的顺序性；集群内部各个服务
器的调度者。对于 create， setData， delete 等有写操作的请求，需要统⼀转发给leader 处
理， leader 需要决定编号、执⾏操作，这个过程称为⼀个事务。

Follower:处理客户端⾮事务（读操作） 请求，转发事务请求给 Leader；参与集群 Leader 选举投票 2n-1台可以做集群投票。此外，针对访问量⽐较⼤的 zookeeper 集群， 还可新增观察者⻆⾊。

Observer:观察者⻆⾊，观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于⾮事务
请求可以进⾏独⽴处理，对于事务请求，则会转发给 Leader服务器进⾏处理。不会参与任何形式的投票只提供⾮事务服务，通常⽤于在不影响集群事务处理能⼒的前提下
提升集群的⾮事务处理能⼒。

• serverid:服务器id
  ⽐如有三台服务器，编号分别为1，2，3。编号越⼤在选择算法中的权重越⼤

• zxid:数据id
  服务器中存放的最⼤数据ID。值越⼤说明数据越新，在选举算法中的权重越⼤

• Epoch:逻辑时钟
  也可以称之为每个服务器参加投票的次数。同⼀轮投票过程中的逻辑次数
  优先级：Epoch > zxid >serverid

• Server状态：选举状态
  • LOOKING：竞选状态
  • FOLLOWING:随从状态，同步leader状态，参与选票
  • OBSERVING:观察状态，同步leader状态，不参与选票
  • LEADER：领导者状态

#Zookeeper的监听原理

1. ⾸先要有⼀个main()线程
2. 在main线程中创建Zookeeper客户端， 这时就会创建两个线程， ⼀个负责⽹络连接通
   信(connet),⼀个负责监听(listener)。
3. 通过connect线程将注册的监听事件发送给Zookeeper。
4. 在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。
5. Zookeeper监听到有数据或路径变化， 就会将这个消息发送给listener线程。
6. listener线程内部调⽤了process（） ⽅法。

用途：

1. 监听节点数据的变化: get /path watch
2. 监听⼦节点增减的变化 : ls /path watch

写数据流程

Client 向 ZooKeeper 的Server1 上写数据，发送一个写请求。
如果Server1不是Leader，那么Server1 会把接受到的请求进一步转发给Leader，因为每个ZooKeeper的Server里面有一个是Leader。这个Leader 会将写请求广播给各个Server， 比如Server1和Server2，各个Server会将该写请求加入待写队列，并向Leader发送成功信息。
当Leader收到半数以上 Server 的成功信息， 说明该写操作可以执行。Leader会向各个Server 发送提交信息，各个Server收到信息后会落实队列里的写请求， 此时写成功。
Server1会进一步通知 Client 数据写成功了，这时就认为整个写操作成功