Zookeeper

 理论篇

• 概述
  • Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。
  • Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责储存和管理大家都关心的数据，然后接受观察者注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式
  • Zookeeper = 文件系统 + 通知机制
• 特点
  • Zookeeper 一个领导者 （leader） 多个跟随者 Follower 组成的集群
  • 集群只要有半数以上的节点存货，Zookeeper集群就能正常服务
  • 全局数据一致性：每个Server保存一份相同的数据副本，Client无论链接到哪个Server数据都是一致的
  • 更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行
  • 数据更新原子性，一次数据更新要么成功，要么失败
  • 实时性，在一定时间范围内，Client能读到最新数据　
• 应用场景
  • 提供服务包括：分布式消息同步和协调机制，服务器节点动态上下线，统一配置管理，负载均衡，集群管理等
    • 统一命名服务    在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。  
    • 统一配置管理   
      • 在分布式环境下，配置文件同步非常常见
        • 一般要求一个集群中，所有节点的配置信息是一致的，比如kafka集群
        • 对于配置文件修改后，希望能够快速同步到各个节点上
      • 配置管理可交由Zookeeper实现
        • 可将配置信息写入Zookeeper上的一个Znode
        • 各个客户端服务器监听这个Znode
        • 一旦Znode中的数据被修改Zookeeper将通知各个客户端服务器
    • 统一集群管理
      • 分布式环境中，实时掌握每一个阶段的状态是必要的 
        • 根据节点实时状态做出一些调整
      • Zookeeper可以实现实时监空节点状态变化
        • 可将节点信息写入Zookeeper上的一个znode
        • 监听这个znode可获取他的实时状态变化
    • 负载均衡
      • 在Zookeeper中记录每台服务器的访问数，让访问最少的服务器去处理最新的客户端请求
• 本地模式安装部署
  • 安装准备：
    • 安装JavaJDK
    • 将下载zookeeper安装tar包上传到linux系统中
    • 解压tar包并修改文件权限
    • 修改配置文件
      • 将zookeeper/conf这个目录下的zoo_sample.cfg修改为zoo.cfg
      • 制定datadir目录 并在服务器中创建对应的文件夹
    • 启动  bin/zkServer.sh start
    • 关闭  bin/zkServer.sh stop
    • 查询状态   bin/zkServer.sh status   或 jps  存在 QuorumPeerMain进程
  • 参数说明
    • tickTime  通信心跳数   Zookeeper服务器心跳时间，单位毫秒
      • Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒
      • 它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间 session最小超时时间是 2*tickTime
    • initLimit   LF初始通信时限
      • 集群中的follower跟随者服务器(F)与leader服务器（L）之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连到Leader的时限。投票选举新的leader的初始时间。 Follower在启动过程中，会从Leader同步所有最新数据，然后确定自己能够对外服务的初始状态。 Leader允许F在initLimit时间内完成这个工作
    • syncLimit  LF同步通信时限
      • 集群中leader与follower之间的最大响应时间单位，假如响应超过synLimit * tickTime，leader 认为 Follower 死掉，从服务器列表中删除Follower。在运行过程中，Leader负责ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。 如果L发出心跳在synLimit之后，还没有从F那收到响应，那么就认为这个F已经不在线了
    • dataDir     数据文件目录 + 数据持久化路径
      •  保存内存数据库快照信息的位置，如果没有其他说明，更新的事物日志也存到数据库
    • clientPort  客户端连接端口                                         

• 选举机制
  • 半数机制： 集群中半数以上机器存活，集群可用，所以zookeeper适合状态奇数台机器上
  • zookeeper虽然在配置文件中没有指定master和slave。 但是， zookeeper工作时，是有一个节点为leader 其他则为follower， leader是通过内部选举机制临时产生的
  • 以一个简单的例子来说明整个选举的过程

　　　　　　　　　　  假设有5台服务器组成zookeeper集群，他们的id从1-5，同时他们都是最新启动的，也就没有历史数据，在存放数据量一点上，都是一样的，假设这些服务器依序启动，会发生什么

1. 1. 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，所以他只能成为follower
      5. 服务器5启动，同4一样成为follower

• 数据结构
  • Zookeeper数据模型的结构与linux文件系统很类似，整体上可以看做是一棵树，每个节点称作一个Node
  • 很显然zookeeper集群自身维护了一条数据结构，这个储存结构示是一个树形结构，其上的每一个节点，我们称之为“znode”，每一个znode默认能储存1mb的数据，每个znode都可以通过其路径唯一标识
  • 节点类型
    • znode有两种类型：
    • 短暂： 客户端和服务器断开连接后，创建的节点自己删除
    • 持久： 客户端和服务器端断开连接后，创建的节点不删除

　　　　　　　　  持久化目录节点   客户端与Zookeeper断开连接后，该节点依旧存在

                                          持久化顺序编号目录节点 ： 客户端与Zookeeper断开连接后，改节点依旧存在，只是Zookeeper给改节点名称进行顺序编号

                                          临时目录节点 客户端与Zookeeper断开连接后，该节点被删除

                                          临时顺序编号目录节点 ： 客户端与Zookeeper断开连接后，改节点被删除，只是Zookeeper给该节点名称进行顺序编号

                                          说明：创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护

                                          在分布式系统中，顺序号可以被用于为所有的时间进行全局排序，这样客户端可以通过顺序号推断时间的顺序 

• 监听器原理
  • 监听器原理详解
    • 首先要有一个main()线程
    • 在main()线程中创建Zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信(connet) , 一个负责监听 (listener)
    • 通过connet线程将注册的监听时间发送给Zookeeper
    • 在Zookeeper的注册监听器列表中将注册的监听时间添加到列表中
    • Zookeeper监听到有数据或路径变化，就会将整个消息发送给listener线程
    • listener线程内部调用了precess()方法
  • 常见的监听
    • 监听节点数据的变化    get path[watch]
    • 监听子节点增减的变化  ls path[watch]　
• 写数据流程
  • Client向Zookeeper的Server1上写数据，发送一个写请求
  • 如果server1不是leader， 那么server1会把接收到的请求进一步转发给leader， 因为每个Zookeeper的Server里面有一个是leader，这个Leader会将写请求广播给各个Server，不如Server1和Server2， 各个Server写成功后就会通知Leader
  • 当Leader收到大多数Server数据写成功了，那么就说明写成功了，如果有三个节点的话，只要有两个节点数据写成功了没那么就认为数据写成功了，写成功之后，leader告诉Server数据写成功了
  • Server1会进一步通知Client数据写成功了，这时就认为整个写操作成功
• Stat结构体
  • czxid-创建节点的事物 zxid   每次修改zookeeper状态都会收到一个zxid形式的时间戳，也就是zookeeper事物ID 事物id是zookeeper中所有修改总的次序，每个修改都唯一的zxid 如果zxid1小于2 那么zxid1在2之前发生
  • ctime - znode 被创建的毫秒数 从1970年开始
  • mzxid - znode 最后更新的事物zxid
  • mtine - znode 最后修改的毫秒数
  • pZxid - znode  最后更新的子节点zxid
  • cversion-znode 子节点变化好，znode子节点修改次数
  • dataversion-znode 数据变化好
  • ephemeralOwner 如果是临时节点，这个是znode拥有这的session id，如果不是临时节点则是0
  • dataLength-znode 数据长度
  • numChildren - znode 子节点数量