zookeeper的定义

zookeeper是分布式应用程序的高性能协调服务，顾名思义，zookeeper用来保存分布式应用程序的多个节点之间的状态、配置等信息，以确保分布式程序的正确、高速运行。

创新互联是一家专业提供芦淞企业网站建设,专注与成都网站制作、做网站、H5建站、小程序制作等业务。10年已为芦淞众多企业、政府机构等服务。创新互联专业网站设计公司优惠进行中。

zookeeper集群角色：leader、follower、观察者（集群访问量大时，增加Observer角色）

1 客户端访问zookeeper时，连接到leader与连接到follower之间的区别？

• leader可处理事务操作（增删改），且所有的事务操作只能由leader处理，其他角色接收到事务请求时，需转发给leader；
• follower只能处理非事务型操作（读操作）；
• follower可参与集群leader选举；
• Observer功能：增加非事务型请求（读操作）的横向扩展性；当读操作的需求量特别大时，可通过增减观察者节点的方式来提高集群性能。

2 集群搭建

• 机器数量：zookeeper集群选举leader时使用posix算法，所以一般选择奇数台机器（2n+1）
• zookeeper集群需要配置sun java环境（sun JDK）
• 部署leader+follower集群（https://www.cnblogs.com/wrong5566/p/6056788.html）
  • 集群的主机间设置每台机器的hosts
  • 修改zookeeper的配置zoo.cfg（zookeeper启动时，如果未显示指定配置文件，则默认读取conf目录下的zoo.cfg配置文件）
  • 新建myid文件
  • 配置zookeeper目录及配置的环境变量

zookeeper数据模型

zookeeper的数据模型是树（猜测是b+树，但未进行确认），
1 树上每个节点被称为Znode；Znode由3部分组成：stat（znode的状态信息）、data（znode中的数据信息）和children（znode子节点的信息）
2 节点Znode的特点：

• Znode 既可以作为文件存储数据，也可以作为目录；
• Znode 上的操作具有原子性；
• Znode 节点限制存放文件的大小（最大1M）；
• Znode 的访问需要使用绝对路径。

3 Znode节点的属性：

• dataVersion：局部值，当前节点的数据版本；每次对当前节点设置值后，当前节点的dataVersion值都加1，默认为0;
• cversion：局部值，当前节点的子节点版本号；子节点每次发生变化后，cversion的值都加1，默认为0;
• cZxid：全局值，创建当前节点的事务id；每当创建一个新的znode后，cZxid的值都加1;
• mZxid：全局值，当前节点最近一次被修改的事务id；任意Znode被修改后，mzxid的值加1，其中mZxid与cZxid没有必然的联系;
• pZxid：全局值，Znode子节点最近一次被创建时的cZxid;
• ephemeralOwner：局部值，记录临时节点的session id，如果非临时节点，值为0;
• dataLength：局部值，当前节点的数据长度（字节）;
• numChildren：子znode的数量;

zookeeper节点类型

1. 临时节点：临时节点依赖于会话，创建临时节点的会话结束时，临时节点将被删除;且临时节点不允许拥有子节点;
2. 永久节点：永久节点的生命周期不依赖于会话，可以拥有子节点;

zookeeper shell

- jps查看zookeeper进程：QuorumPeerMain
- 连接zookeeper集群：zkCli.sh -server zookeeper:2181
- 创建节点：create [-s] [-e] path data acl; -s表示顺序节点、-e表示临时节点
- 读取节点：ls path [watch] 获取节点的子节点、get path [watch] 获取节点保存的数据和节点属性信息、ls2 path [watch] 获取节点的子节点和当前节点属性信息
- 更新节点数据：set path data [version] 
- 删除节点：delete path [version]、rmr path 递归删除数据

zookeeper选举机制

- 算法：FastLeaderElection
- 选举算法用到的概念：
    服务器ID：数值型，编号越大权重越大
    选举状态：
        LOOKING，观望状态
        FOLLOWING，随从状态，
        OBSERVING，观察者状态，同步leader状态，不参与选举
        LEADING，领导者状态
    数据ID：最新写入的数据的ID
    逻辑时钟：每轮投票，逻辑时钟的次数相同;（根据逻辑时钟判断集群中的节点是否不稳定）
- 新集群选举：
    1. 前提：
        1.1. 每个机器都给自己投票;
        1.2. 投票数过半，选举结束; 
    2. 思路：集群中的机器启动后，给自己投一票，然后开始与其他机器交换投票结果，如果没有其他机器可以交换，则进入LOOKING状态；如果有其他机器可以交换投票，则根据服务器ID大小，服务器ID小的机器将自己的票投给服务器ID大的机器;当有一台机器拿到过半的票数时，将结束选举；同一集群中，先启动服务的机器将有更大的机会获得leader。
- 运行中的集群选举：
    1. 前提同上;此时选举需要用数据ID、服务器ID、逻辑时钟
    2. 思路：首先，同一逻辑时钟，逻辑时钟小的被淘汰，逻辑时钟相同的机器将重新投票；然后，机器中数据ID大的胜出；如果数据ID相同，那么服务器ID大的胜出。

zookeeper的应用场景：

1. 数据发布与订阅;
2. 命名服务;
3. 分布式锁;

数据发布与订阅中心（配置中心）

- 发布者将数据发布到zookeeper中，订阅者来获取新的数据更新自己的配置;
- 注意点：
    1. 统一管理的数据不能太大;
- 原理：
    1. 所有订阅者首次启动时，访问zk指定的节点获取相关的订阅信息;
    2. 获取数据的同时，设置对节点数据变化的监听; zk.getData(path, true);设置对指定path的监听
    3. 被监听的path上的节点数据发生改变时，监听被触发，所有对次path的订阅者将收到zookeeperde通知，然后访问zookeeper获取新的配置信息;
    4. 获取数据时，再次对path设置监听;
- 疑问：zookeeper中的数据发生改变时，zookeeper如何通知订阅者？给订阅者发送了什么通知？

文章标题：bigdata-zookeeper笔记（一）
转载源于：http://cdweb.net/article/pcsiie.html