Zookeeper集群搭建和简介(二)

本文主要涉及一下知识.
1.linux虚拟机安装和linux基本设置
2.linux间免密登录
3.linux搭建zookeeper环境
4.zookeeper的介绍

书接上回

3.linux搭建zookeeper环境

在搭建zookeeper之前.我们先做些准备工作
修改linux之间的名称和配置hosts文件. 当我们远程连接时,就不用输入密码了.
在linux1中,修改/etc/hosts文件
192.168.1.1(linux1的ip) znode1
192.168.1.2(linux2的ip) znode2
192.168.1.3(linux3的ip) znode3
如果我们想链接znode2,就可以ssh znode2 就可以.不用再输入ip啦.

第一步:
把zookeeper的压缩包上传到/export/software/目录下.
解压 tar zxvf zookeeper.jar.gz /export/server/(解压文件到/export/server/目录下)
进入到conf目录下.看到zoo_sample.cfg文件 修改名称
mv zoo_sample.cfg zoo_sample.cfg
修改zoo.cfg文件
执行命令 : vim z00.cfg
找到dataDir,后面修改成这个路径 . zookeeper的日志文件就会输出到这个目录下.
dataDir=/export/data/zookeeper
光标移动到最后,添加如些内容 . znode1-znode3是linux的名称 2888,3888是通讯端口号和选举端口号.保存退出
server.1=znode1:2888:3888
server.2=znode2:2888:3888
server.3=znode3:2888:3888

第二步:
进入到/export/data目录下.创建zookeeper目录,进入到目录中
执行 echo 1 > myid . 这个1就是上面server后面的数字,上面写几,这就写几,要对应上.

第三步:
修改环境变量. 执行 vim /etc/profile
在最后添加
export ZOOKEEPER_HOME=/export/server/zookeeper #(zookeeper安装目录路径)
export PATH=$PATH:$ZOOKEEPER_HOME/bin
保存退出,刷新下文件 source /etc/profile

第四步:
把/export/server/zookeeper 文件拷贝到znode2和znode3一份
scp -r /export/server/zookeeper znode2:/export/server
scp -r /export/server/zookeeper znode3:/export/server
再把/etc/profile文件拷贝一下,这样就不用再添加环境变量了
scp /etc/profile znode2:/etc/
scp /etc/profile znode3:/etc/
注意,在znode2和znode3里要刷新文件哦.要不环境变量不生效

第五步:
进入到znode2 /export/data/zookeeper目录下.
执行 echo 2 > myid
进入到znode3 /export/data/zookeeper目录下.
执行 echo 3 > myid

到现在,zookeeper安装基本完成了.
启动zookeeper.znode1,znode2,znode3都要启动起来
zkServer.sh start
查看zookeeper状态,zkServer.sh status

Zookeeper介绍

一 zookeeper认识:

1.Zookeeper是一个分布式协调服务的开源框架。主要用来解决分布式集群中应用系统的一致性问题，

2.ZooKeeper本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。诸如：统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能

二 zookeeper特性

1. 全局数据一致：集群中每个服务器保存一份相同的数据副本，client无论连接到哪个服务器，展示的数据都是一致的，这是最重要的特征
2. 可靠性：如果消息被其中一台服务器接受，那么将被所有的服务器接受
3. 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
4. 数据更新原子性：一次数据更新要么成功（半数以上节点成功），要么失败，不存在中间状态
5. 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

   三 zookeeper集群角色

6. Leader : Zookeeper集群工作的核心.事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性； 集群内部各个服务器的调度者。
7. Follower : 处理客户端非事务（读操作）请求，转发事务请求给Leader； 参与集群Leader选举投票
8. Observer : 观察者角色. 观察Zookeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader服务器进行处理.不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力

四 zookeeper shell操作

1. 链接zookeeper zkCli.sh -server ip. 运作zk shell,会提示用法.
2. 创建节点
   create [-s] [-e] path data acl
   -s或-e分别指定节点特性，顺序或临时节点，若不指定，则表示持久节点；acl用来进行权限控制
   例如 : create -s /Test 2018 -s表示节点是序列化节点,/Test表示在根目录下创建Test节点, 2018是节点存储的值

   
   创建临时节点
   create -e /Test01 2018
   创建永久节点
   create /Test02 2019

1. 节点读取
   ls 命令可以列出Zookeeper指定节点下的所有子节点，只能查看指定节点下的第一级的所有子节点
   get 命令可以获取Zookeeper指定节点的数据内容和属性信息。
   查看zookeeper根节点目录 : ls /
   查看节点详细信息: get /Test02
2. 更新节点
   set /Test02 2020
3. 删除节点 . 若删除节点存在子节点，那么无法删除该节点，必须先删除子节点，再删除父节点
   delete /Test02
   递归删除节点 rmr path
4. quota 对节点添加限制
   setquota -n|-b val path
   n:表示子节点的最大个数 b:表示数据值的最大长度 val:子节点最大个数或数据值的最大长度 path:节点路径
5. listquota 查看指定节点限制 listquota path
   delquota [-n|-b] path 删除quota
6. history 列出历史命令
   redo : 该命令可以重新执行指定命令编号的历史命令,命令编号可以通过history查看

三 zookeeper数据模型

1. ZooKeeper的数据模型，在结构上和标准文件系统的非常相似，拥有一个层次的命名空间，都是采用树形层次结构，ZooKeeper树中的每个节点被称为—Znode。和文件系统的目录树一样，ZooKeeper树中的每个节点可以拥有子节点。
2. Znode兼具文件和目录两种特点 既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子Znode。用户对Znode具有增、删、改、查等操作（权限允许的情况下）。
3. Znode具有原子性操作 读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作
4. Znode存储数据大小有限制. Znode存储的配置文件信息、状态信息、汇集位置等等都很小,通常以KB为大小单位,ZooKeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小最多1M.
5. Znode通过路径引用,路径必须是绝对的,因此他们必须由斜杠字符来开头

四 zookeeper数据结构

1. 每一个节点都可以创建子节点,每个子节点还可以保存信息,所有节点形成树形结构树.每个节点叫znode,每个znode有三部分组成
   stat：此为状态信息, 描述该Znode的版本, 权限等信息
   data：与该Znode关联的数据
   children：该Znode下的子节点

五 zookeeper 节点类型

1. Znode有两种，分别为临时节点和永久节点
2. 节点的类型在创建时即被确定，并且不能改变。
3. 临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。
4. 永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除
5. Znode还有一个序列化的特性，如果创建的时候指定的话，该Znode的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为“%10d”(10位数字，没有数值的数位用0补充，例如“0000000001”)。
6. 这样便会存在四种类型的Znode节点，分别对应：
   PERSISTENT：永久节点
   EPHEMERAL：临时节点
   PERSISTENT_SEQUENTIAL：永久节点、序列化
   EPHEMERAL_SEQUENTIAL：临时节点、序列化

六 zookeeper 节点属性
每个znode都包含了一系列的属性，通过命令get，可以获得节点的属性

1. dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。
2. cversion ：子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1。
3. aclVersion ：ACL的版本号。
4. cZxid ：Znode创建的事务id。
5. mZxid ：Znode被修改的事务id，即每次对znode的修改都会更新mZxid。 对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id）。通过zxid，可以确定更新操作的先后顺序。
6. ctime：节点创建时的时间戳.
7. mtime：节点最新一次更新发生时的时间戳.
8. ephemeralOwner:如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id. 如果不是, ephemeralOwner值为0.

七 ZooKeeper Watcher
概念: ZooKeeper提供了分布式数据发布/订阅功能，一个典型的发布/订阅模型系统定义了一种一对多的 订阅关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处
ZooKeeper中，引入了Watcher机制来实现这种分布式的通知功能。ZooKeeper允许客户端向服务端注册一个Watcher监听，当服务端的一些事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等.
总的来说可以概括Watcher为以下三个过程：客户端向服务端注册Watcher、服务端事件发生触发Watcher、客户端回调Watcher得到触发事件情况

1. Watch机制特点
   一次性触发 : 事件发生触发监听，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发
   事件封装 : ZooKeeper使用WatchedEvent对象来封装服务端事件并传递。 WatchedEvent包含了每一个事件的三个基本属性： 通知状态（keeperState），事件类型（EventType）和节点路径（path）
   event异步发送 : atcher的通知事件从服务端发送到客户端是异步的。
   先注册再触发 : Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。
2. 通知状态和事件类型. 同一个事件类型在不同的通知状态中代表的含义有所不同.看图
   ![图片上传中...]

3. Shell 客户端设置watcher

1. 设置节点数据变动监听
   
2. 改节点数据
   ![图片上传中...]
3. 此时设置监听的节点收到通知：
   ![图片上传中...]

八 ZooKeeper选举机制

1. zookeeper默认的算法是FastLeaderElection，采用投票数大于半数则胜出的逻辑。
2. 服务器ID : 比如有三台服务器，编号分别是1,2,3。 编号越大在选择算法中的权重越大。

3. 选举状态 :

   LOOKING，竞选状态
           FOLLOWING，随从状态,同步leader状态，参与投票 
           OBSERVING，观察状态,同步leader状态，不参与投票 
           LEADING，领导者状态

4. 数据ID : 服务器中存放的最新数据version。 值越大说明数据越新，在选举算法中数据越新权重越大。
5. 逻辑时钟 : 也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。

全新集群选举
假设目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

1. 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
2. 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
3. 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
4. 服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
5. 服务器5启动，后面的逻辑同服务器4成为小弟。

非全新集群选举
对于运行正常的zookeeper集群，中途有机器down掉，需要重新选举时，选举过程就需要加入数据ID、服务器ID和逻辑时钟。

1. 数据ID：数据新的version就大，数据每次更新都会更新version。
2. 服务器ID：就是我们配置的myid中的值，每个机器一个。
3. 逻辑时钟：这个值从0开始递增,每次选举对应一个值。 如果在同一次选举中,这个值是一致的。
   这样选举的标准就变成：
   1、逻辑时钟小的选举结果被忽略，重新投票；
   2、统一逻辑时钟后，数据id大的胜出；
   3、数据id相同的情况下，服务器id大的胜出；