zookeeper笔记

1 ZooKeeper基础
1.1 为什么使用ZooKeeper？

1. Nginx作为负载均衡管理大量服务器时，管理起来比较麻烦，可以通过zookeeper注册服务与发现服务协作管理。
2. 以前大部分应用需要开发私有的协调程序，缺乏一个通用的机制协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器。
3. 使用分布式部署后，多线程安全的问题，以前学的同步代码块、重构锁、读写锁等通通失效，怎么办？
4. 大数据分布式集群中，集群的服务器如何管理？
   1.2 ZooKeeper概述
   1.2.1 ZooKeeper简介
   ZooKeeper英语意思是动物园管理员，ZooKeeper是分布式应用程序的协调服务框架，是Hadoop的重要组件。ZooKeeper是Google的Chubby一个开源的实现，是Hadoop的分布式协调服务，包含一个简单的原语集，分布式应用程序可以基于它实现。
   扩展：zk是根据Google的一篇论文
   《The Chubby lock service for loosely coupled distributed systems》
   1.2.2 Zookeeper大数据应用场景
   1．Hadoop,使用ZooKeeper的事件处理确保整个集群只有一个NameNode,存储配置信息等。

2．HBase,使用ZooKeeper的事件处理确保整个集群只有一个HMaster,察觉HRegionServer联机和宕机,存储访问控制列表等。
1.3 分布式编程容易出现的问题
分布式的思想就是人多干活快，即用多台机器同时处理一个任务。分布式的编程和单机的编程思想是不同的，随之也带来新的问题和挑战。

1. 需要考虑集群的管理问题，需要有一套机制来检测到集群里节点的状态变化。
2. 管理集群里Leader的选举问题（要根据一定的算法和规则来选举），包括要考虑Leader挂掉之后，如何从剩余的follower里选出Leader，避免单点故障问题。
3. 活锁
   活锁定义：在程序里，由于某些条件的发生碰撞，导致重新执行，再碰撞->再执行，如此循环往复，就形成了活锁。活锁的危害：多个线程争用一个资源，但是没有任何一个线程能拿到这个资源。（死锁是有一个线程拿到资源，但相互等待互不释放造成死锁），活锁是死锁的变种。补充：活锁更深层次的危害，很耗尽Cpu资源（在做无意义的调度）。
4. 分布式锁的实现，用之前学的重入锁，同步代码块是做不了的。
   1.4 Paxos的小岛故事
   那么ZooKeeper最基础的东西是什么呢？不得不提Paxos，它是一个基于消息传递的一致性算法，Leslie Lamport（莱斯利·兰伯特）在1990年提出，近几年被广泛应用于分布式计算中，Google的Chubby，Apache的ZooKeeper都是基于它的理论来实现的，Paxos还被认为是到目前为止唯一的分布式一致性算法，其它的算法都是Paxos的改进或简化。有个问题要提一下，Paxos有一个前提：没有拜占庭将军问题。就是说Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。
   Paxos描述了这样一个场景，有一个叫做Paxos的小岛(Island)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)。议员的总数(Senator Count)是确定的，不能更改。岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒退。每个提议都需要超过半数((Senator Count)/2 +1)的议员同意才能生效。每个议员只会同意大于当前编号的提议，包括已生效的和未生效的。如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编
   号，他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。现在议会有一个目标：保证所有的议员对于提议都能达成一致的看法。
   好，现在议会开始运作，所有议员一开始记事本上面记录的编号都是0。有一个议员发了一个提议：将电费设定为1元/度。他首先看了一下记事本，嗯，当前提议编号是0，那么我的这个提议的编号就是1，于是他给所有议员发消息：1号提议，设定电费1元/度。其他议员收到消息以后查了一下记事本，哦，当前提议编号是0，这个提议可接受，于是他记录下这个提议并回复：我接受你的1号提议，同时他在记事本上记录：当前提议编号为1。发起提议的议员收到了超过半数的回复，立即给所有人发通知：1号提议生效！收到的议员会修改他的记事本，将1好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并告诉对方：1元/度。
   现在看冲突的解决：假设总共有三个议员S1-S3，S1和S2同时发起了一个提议:1号提议，设定电费。S1想设为1元/度, S2想设为2元/度。结果S3先收到了S1的提议，于是他做了和前面同样的操作。紧接着他又收到了S2的提议，结果他一查记事本，咦，这个提议的编号小于等于我的当前编号1，于是他拒绝了这个提议：对不起，这个提议先前提过了。于是S2的提议被拒绝，S1正式发布了提议: 1号提议生效。S2向S1或者S3打听并更新了1号法令的内容，然后他可以选择继续发起2号提议。
   好，我觉得Paxos的精华就这么多内容。现在让我们来对号入座，看看在ZK Server里面Paxos是如何得以贯彻实施的。
   小岛(Island)——ZK Server Cluster
   议员(Senator)——ZK Server
   提议(Proposal)——ZNode Change(Create/Delete/SetData…)
   提议编号(PID)——Zxid(ZooKeeper Transaction Id)
   正式法令——所有ZNode及其数据
   貌似关键的概念都能一一对应上，但是等一下，Paxos岛上的议员应该是人人平等的吧，而ZK Server好像有一个Leader的概念。没错，其实Leader的概念也应该属于Paxos范畴的。如果议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”（所谓活锁我的理解是大家都没有死，都在动，但是一直解决不了冲突问题）。Paxos的作者Lamport在他的文章”The Part-Time Parliament“中阐述了这个问题并给出了解决方案——在所有议员中设立一个总统，只有总统有权发出提议，如果议员有自己的提议，必须发给总统并由总统来提出。
   好，我们又多了一个角色：总统。
   总统——ZK Server Leader。
   1.5 ZooKeeper集群
   Zookeeper集群中建议由奇数台的ZkServer组成，这些节点中会有一台节点是Leader，集群建议奇数台主要是zookeeper集群中有半数以上的节点正常运行，zookeeper集群就正常，那么假设集群有4台节点，当集群中正常节点大于2台时，zookeeper集群正常运行；当集群中有3台节点时，当集群中正常节点大于2台时，zookeeper集群正常运行，由以上对比来看，使用奇数台效果与使用偶数台效果一样，所以在保证zookeeper集群能正常运行下，使用奇数台可以节约1台节点的成本。
   在负责管理zookeeper集群，zookeeper集群中的节点有四种状态:
    looking：服务器处于寻找Leader的状态
    leadering:服务器作为Leader的状态
    following:服务器作为follower节点
    observing:服务器作为observer状态
   在Zookeeper集群中，选择那些节点为Leader分为两种情况：

1. 集群启动时

每个zkServer都有两种标记，一个是选举ID和事务ID，如上图：（选举ID，事务ID）,当zookeeper三台节点同时启动时，会比较三台节点的事务ID，哪个事务ID大，选择哪个节点为Leader，如果一样大，则比较选举ID，选举ID大的被选择当做Leader。
一般在启动Zookeeper集群节点时，可能不是三台节点同时启动，可能是一台一台启动，例如：启动Server1,Server2,Server3,那么当Server1，Server2启动后，两台节点中会选择Server2节点当做Leader,那么当Server3启动后自动成为follower。

2. 集群工作时，Leader挂掉
   假设在zookeeper集群运行了一段时间后，集群中的Server状态如下：

以上Server2代表Leader挂掉，在Server1和Server3中如何选举Leader呢，会直接比较两台节点的事务ID，大的被选择成Leader,这里就是Server3。如果事务ID相同，那么比较选举ID，会选择选举ID大的为Leader。
2 ZooKeeper集群分布式安装
2.1 五台服务器之间免密登录
这里需要搭建的五台服务器之间互相均可以免密登录.

1. 首先在五台服务器上都要执行：
   ssh-keygen -t rsa -P ‘’ -f ~/.ssh/id_rsa
2. 将其他节点的公钥copy到mynode1节点上
   ssh-copy-id mynode1 #注意，这里在mynode1-mynode5都执行此命令
3. 将mynode1节点的authorized_keys拷贝到mynode2、3、4、5节点上：
   scp ~/.ssh/authorized_keys mynode2:/root/.ssh/ #注意，这里mynode2,mynode3,mynode4,mynode5都要发送
   经过以上步骤，两两节点免密完成，可以测试。
   2.2 JDK安装环境变量配置
   mynode1-mynode5节点上执行如下命令，创建目录：
   mkdir /software/
   将jdk-8u181-linux-x64.rpm上传到mynode1 /software/目录下
   将/software/下的jdk*.rpm scp到mynode2、mynode3、mynode4、mynode5的对应目录中
   scp jdk-8u181-linux-x64.rpm mynode2:/software/
   scp jdk-8u181-linux-x64.rpm mynode3:/software/
   scp jdk-8u181-linux-x64.rpm mynode4:/software/
   scp jdk-8u181-linux-x64.rpm mynode5:/software/
   在mynode1、mynode2、mynode3、mynode4、mynode5上安装jdk并配置profile文件
   rpm -ivh jdk-8u181-linux-x64.rpm
   mynode1上修改环境变量
   vim /etc/profile
   export JAVA_HOME=/usr/java/jdk1.8.0_181-amd64
   export PATH=$PATH:$JAVA_HOME/bin
   source /etc/profile
   将mynode1的/etc/profile拷贝到mynode2、mynode3、mynode4、mynode5上并执行 source /etc/profile，完成JDK安装。
   scp /etc/profile mynode[2345]:pwd

2.3 ZooKeeper集群搭建
在安装zookeeper之前还需关闭各个节点的防火墙，并设置开机不启动：
firewall-cmd --state #查看防火墙状态
systemctl stop firewalld #关闭防火墙
systemctl disable firewalld #设置开机不启动
将以上各个节点的防火墙关闭之后，可以进行zookeeper的安装。

1. 将ZooKeeper.tar.gz上传到mynode3

2.  解压到/software
   

tar -zxvf apache-zookeeper-3.6.3-bin.tar.gz -C /software
3) 配置环境变量：
export ZOOKEEPER_HOME=/software/zookeeper-3.6.3
export PATH=$PATH:$JAVA_HOME/bin:$ZOOKEEPER_HOME/bin
然后./etc/profile让配置生效，最后将该文件scp到mynode4和mynode5上，并分别./etc/profile让配置生效。
scp /etc/profile mynode4:/etc/
scp /etc/profile mynode5:/etc/

4. 到$ZooKeeper_HOME/conf下
   复制zoo_sample.cfg为zoo.cfg
   cp zoo_sample.cfg zoo.cfg

5. 编辑zoo.cfg
   补充：参数说明
   tickTime=2000 #发送心跳的间隔时间，单位：毫秒
   dataDir=/opt/data/zookeeper #ZooKeeper保存数据的目录
   dataLogDir=/var/msbjy/zookeeper/datalog #日志目录
   clientPort=2181
   initLimit=5
   syncLimit=2
   server.1=mynode3:2881:3881
   server.2=mynode4:2881:3881
   server.3=mynode5:2881:3881 #observer（表示对应节点不参与投票）
   clientPort：客户端连接 ZooKeeper 服务器的端口，ZooKeeper 会监听这个端口，接受客户端的访问请求。
   initLimit： 这个配置项是用来配置 ZooKeeper 接受客户端（这里所说的客户端不是用户连接ZooKeeper服务器的客户端，而是 ZooKeeper 服务器集群中连接到 Leader的Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的时间（也就是 tickTime）长度后 ZooKeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 52000=10秒
   syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个tickTime 的时间长度，总的时间长度就是 22000=4 秒
   server.A=B：C：D：其 中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的ip地址；C 表示的是这个服务器与集群中的Leader服务器交换信息的端口；D表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于B都是一样，所以不同的ZooKeeper实例通信端口号不能一样，所以要给它们分配不同的端口号。

6. 创建/opt/ZooKeeper-3.4.6/data目录，并在该目录下放一个文件：myid
   在myid中写下当前ZooKeeper的编号
   mkdir /opt/data/zookeeper
   mkdir /var/msbjy/zookeeper/datalog
   echo 1 > /opt/data/zookeeper /myid

7. 将配置好ZooKeeper拷贝到mynode4、mynode5上
   scp -r ZooKeeper-3.6.3/ mynode3:/opt/
   scp -r ZooKeeper-3.6.3/ mynode4:/opt/

8. 在node3和node4上分别修改：myid
   mynode4
   echo 2 > /opt/data/zookeeper /myid
   2
   mynode5
   echo 3 > /opt/data/zookeeper /myid
   3

9. 分别启动ZooKeeper
   zkServer.sh start 启动zk
   zkServer.sh stop 停止zk
   zkServer.sh status 查看zk状态
   zkServer.sh start|stop|status

3 ZooKeeper进阶
3.1 Znode数据结构
3.1.1 目录结构

1. ZK有一个最开始的节点 /。
2. ZK的节点叫做znode节点。
3. 每个znode节点都可存储数据。
4. 每个znode节点（临时节点除外）都可创建自己的子节点。
5. 多个znode节点共同形成了znode树。
6. Znode树的维护是在内存中，目的是供用户快速的查询。
7. 每个znode节点都是一个路径（通过路径来定位这个节点）。
8. 每个路径名都是唯一的。
   目录结构是有层次的目录型结构，便于管理逻辑关系，znode信息中包含最大1MB的数据信息，这些信息也包含记录zxid等元数据信息。
   3.1.2 节点（目录）类型
    znode有两种类型，临时的（ephemeral）和持久的（persistent）
    临时znode
   客户端会话结束时，ZooKeeper将该临时znode删除，临时znode没有子节点
    持久znode
   不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除
    znode的类型在创建时确定并且之后不能再修改。
    znode支持序列SEQUENTIAL
   有序znode节点被分配唯一单调递增的整数。比如：客户端创建有序znode，路径为/task/task-，则ZooKeeper为其分配序号1，并追加到znode节点： /task/task-000000001。有序znode节点唯一，同时也可根据该序号查看znode创建顺序。

 znode有四种形式的目录节点
PERSISTENT：普通持久
EPHEMERAL：普通临时
PERSISTENT_SEQUENTIAL：顺序持久
EPHEMERAL_SEQUENTIAL：顺序临时

我们创建以上各种节点类型，需要首先启动Zookeeper服务器，进入到Zookeeper的客户端之后，再执行对应的创建删除命令：
./zkServer.sh start:启动zk服务器端
./zkCli.sh：启动zk客户端
3.2 ZK客户端命令行操作
指令 示例
ls查看指令 ls /
create创建节点指令，注意，在创建节点时，要分配初始数据。 create /zk01 hello
create /zk02 “”
get查看节点数据指令 get /zk01
set更新节点数据指令 set /zk01 hellozk
delete删除节点 delete /zk01
quit退出zk客户端 直接在客户端中执行quit命令。

3.3 ZooKeeper会话
1、客户端通过TCP协议与独立服务器或者一个集群中的某个服务器建立会话连接。
2、会话提供顺序保障，即同一个会话中的请求以FIFO的顺序执行。如果客户端有多个并发会话，FIFO顺序在多个会话之间未必能够保持。
3、如果连接的Server出现问题，在没有超过Timeout时间时，可以连接其他节点。ZooKeeper客户端透明地转移一个会话到不同的服务器。
4、同一session期内的特性不变
5、当一个会话因某种原因终止，在这个会话期间创建的临时节点将会消失。

Session是由谁来创建的？
Leader：产生一个唯一的session，放到消息队列，让所有server知道
过半机制：保证session创建成功或者失败
3.4 广播模式
ZooKeeper的核心是原子广播，这个机制保证了各个server之间的信息同步。实现这个机制的协议叫做ZAB协议。
ZAB协议有两种模式：

1. 恢复模式
   当服务启动或者在领导者崩溃后，ZAB就进入了恢复模式。当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和follower以及observer具有相同的系统状态。
   2.广播模式
   广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid(比如：0x1000000300000002)。
   epoch也称为纪元数字。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，低32位是个递增计数。

广播模式：

3.5 事件监听原理

我们可以使用zookeeper可以实现事件监听，从而根据监听变化客户端作出相应的操作。
 通过网络轮询，代价很大

 基于通知（notification）的机制
客户端向ZooKeeper注册需要接收通知的znode，通过对znode设置监视点（watch）来接收通知。监视点是一个单次触发的操作，意即监视点会触发一个通知。
为了接收多个通知，客户端必须在每次通知后设置一个新的监视点。

事件监听Watcher
Watcher 在 ZooKeeper 是一个核心功能，Watcher 可以监控目录节点的数据变化以及子目录的变化，一旦这些状态发生变化，服务器就会通知所有设置在这个目录节点上的Watcher，从而每个客户端都很快知道它所关注的目录节点的状态发生变化，而做出相应的反应。
可以设置观察点的操作：exists,getChildren,getData
可以触发观察的操作：create,delete,setData

3.6 Zookeeper集群的特点

实时性解释：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口
4 实例问题
1、创建zookeeper 的时候，必须在父节点存在的时候 ，才能创建子节点。。如果父节点不存在则不能创建子节点。类似于 必须先创建 /app1 才能创建 /app1/p_1 .
不能直接创建/app1/p_1, 直接创建会报错，找不到节点