Zookeeper

Posted 2021-03-24 zfy0098

 理论篇

• 概述

1. Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。
2. Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责储存和管理大家都关心的数据，然后接受观察者注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式
3. Zookeeper = 文件系统 + 通知机制

• 应用场景
  1. 提供服务包括：分布式消息同步和协调机制，服务器节点动态上下线，统一配置管理，负载均衡，集群管理等
• 本地模式安装部署
  • 安装准备：
    • 安装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数据模型的结构与linux文件系统很类似，整体上可以看做是一棵树，每个节点称作一个Node
    • 很显然zookeeper集群自身维护了一条数据结构，这个储存结构示是一个树形结构，其上的每一个节点，我们称之为“znode”，每一个znode默认能储存1mb的数据，每个znode都可以通过其路径唯一标识
  • 节点类型
    • znode有两种类型：
      • 短暂： 客户端和服务器断开连接后，创建的节点自己删除
      • 持久： 客户端和服务器端断开连接后，创建的节点不删除
  • 选举机制
    • 半数机制： 集群中半数以上机器存活，集群可用，所以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