bigdata - zookeeper笔记（一）

zookeeper的定义

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

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集群（http://www.javashuo.com/article/p-tyencviy-by.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如何通知订阅者？给订阅者发送了什么通知？