大数据学习-Zookeeper

大数据学习-Zookeeper

---

(一) Zookeeper

ZooKeeper是一个分布式的，开源的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。

大部分应用需要开发私有的一个主控、协调器或控制器的协调程序来管理物理分布的子进程（如资源、任务分配等）。而协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器,所以zookeeper应用而生。

Zookeeper是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用。
Keepalived： 监控节点不好管理，采用优先级监控没有协同工作；功能单一；可扩展性差。

学习和使用ZooKeeper。可以学习了解Paxos算法

(二) Zookeeper的角色

领导者（leader），负责进行投票的发起和决议，更新系统状态。

学习者（learner），包括跟随者（follower）和观察者（observer）， follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票。

Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。

1. Zookeeper需保证高可用和强一致性；
2. 为了支持更多的客户端，需要增加更多Server；
   Server增多，投票阶段延迟增大，影响性能；
3. 权衡伸缩性和高吞吐率，引入Observer
   Observer不参与投票；
   Observers接受客户端的连接，并将写请求转发给leader节点；
   加入更多Observer节点，提高伸缩性，同时不影响吞吐率。

客户端（client），是请求发起方。

(三)Zookeeper的特点

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

(四)Zookeeper的安装配置

1. 下载安装包并解压
   

2. 配置zoo.cfg文件
   
   

    tickTime=2000  发送心跳的间隔时间，单位：毫秒
    dataDir=/opt/data 
    dataLogDir=/Users/zdandljb/zookeeper/dataLog
    clientPort=2181    户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
    initLimit=5
    syncLimit=2
    server.1=node01:2888:3888
    server.2=node02:2888:3888
    server.3=node03:2888:3888
   

initLimit： 这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的心跳时间长度，总的时间长度就是 2*2000=4 秒
server.A=B：C：D：其 中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号

3. 在dataDir目录中创建一个myid的文件，文件内容分别为1，2，3

创建myid文件，
server1机器的内容为：1，
server2机器的内容为：2，
server3机器的内容为：3

4. 环境变量
   
   
   
5. 将配置复制到其他zk节点
   
   
   
   

(五) 深入zookeeper原理（paxos算法）

详见：paxos算法

(六) zookeeper的节点及工作原理

• 工作原理：

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

Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。

Zab协议有两种模式，它们分别是恢复模式和广播模式。

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。

广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。

当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。

• Znode节点
  Znode有两种类型，短暂的（ephemeral）和持久的（persistent）
  Znode的类型在创建时确定并且之后不能再修改

  短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点

  持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除

  Znode有四种形式的目录节点:

  PERSISTENT 持久的
  EPHEMERAL 短暂的
  PERSISTENT_SEQUENTIAL 持久且有序的
  EPHEMERAL_SEQUENTIAL 短暂且有序的

(七) zookeeper方法及RMI实现

参考：Zookeeper的方法（API）

(八) zookeeper应用场景

• 数据发布与订阅（配置中心）
• 负载均衡
• 命名服务(Naming Service)
• 分布式通知/协调
• 集群管理与Master选举
• 分布式锁
• 分布式队列
• …

(九) 总结

Zookeeper 作为 Hadoop 项目中的一个子项目，是Hadoop 集群管理的一个必不可少的模块，它主要用来控制集群中的数据，如它管理 Hadoop 集群中的NameNode，还有 Hbase 中 Master、 Server 之间状态同步等。

Zoopkeeper 提供了一套很好的分布式集群管理的机制，就是它这种基于层次型的目录树的数据结构，并对树中的节点进行有效管理，从而可以设计出多种多样的分布式的数据管理模型。