zookeeper有两种工作模式,一种是单机方式,另一种是集群方式.

Zookeeper作为一个服务，它本身也可能发生故障，所以我们需要将Zookeeper进行集群，避免单点故障问题，以保证zookeeper本身的高可用性

Zookeeper集群特点
Zookeeper集群有三个角色，一个leader（领导者），一个follower（跟随者），一个observer（观察者）；
集群中只要有 超过半数 的机器是正常工作的，那么整个集群对外就是可用的；
也就是说如果有2个zookeeper，那么只要有1个故障了，zookeeper就不能用了，因为1没有过半，所以2个zookeeper不是高可用的，因为不能容忍任何1台发生故障；

zookeeper集群配置
1、下载安装3个Zookeeper
2、3个zookeeper中conf目录下的zoo_sample.cfg复制一份，改为zoo.cfg并配置：
dataDir=/usr/local/apache-zookeeper-3.5.5-bin-01/data
clientPort=2181

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

如果是在三个linux上搭建：（端口可以重复）
server.1=linux1IP:2888:3888
server.2=linux2IP:2888:3888
server.3=linux3IP:2888:3888

zookeeper内嵌的server服务器的端口，默认是8080

admin.serverPort=3181

格式：
server.A = B：C：D：
server.serverid = serverhost:leader_listent_port:quorum_port
A是一个数字,表示这个是第几号服务器,
B是这个服务器的ip地址
C该端口用于集群成员的信息交换,表示的是该服务器与集群中的Leader服务器交换信息的端口
D是在leader挂掉时专门用来进行选举leader端口
3、创建三个dataDir目录
/usr/local/apache-zookeeper-3.5.5-bin-01/data
/usr/local/apache-zookeeper-3.5.5-bin-02/data
/usr/local/apache-zookeeper-3.5.5-bin-03/data
每个data目录中都创建一个名为myid的文件，3个文件的内容分别写1、2、3；
如果你这个dataDir目录下有原来运行产生的数据，最好是删除一下；
这个1、2、3是对应前面的server.1、 server.2、 server.3
至此一个zookeeper的集群就搭建完成；
注：admin.serverPort=3181 （zookeeper从3.5.x版本开始会占用8080端口，通过此配置修改掉默认的8080，避免和tomcat端口冲突）
验证集群：
./zkServer.sh status
Mode: leader
Mode: follower

zookeeper集群选举leader

Leader选举是保证分布式数据一致性的关键所在，当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。
(1) 服务器初始化启动的时候；
(2) 服务器运行期间无法和Leader保持连接；

下面就两种情况进行分析讲解。
1、服务器启动初始化的时候Leader选举
进行Leader选举的基础条件是至少需要有两个zookeeper，下面我们以3台机器组成的zookeeper集群为例。
在集群初始化阶段，当有一台服务器zookeeper1启动时，其单独无法进行和完成Leader选举；
当第二台服务器zookeeper2启动时，此时两台机器(超过半数)可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程，选举过程如下：
(1) 每个zookeeper发出一个投票，由于是启动初始情况，zookeeper1和zookeeper2都会将自己作为Leader服务器来进行投票，每次投票会包含所推选的服务器的myid和ZXID，使用 (ZXID,myid) 来表示，此时zookeeper1的投票为 (0, 1)，zookeeper2的投票为 (0, 2)，然后各自将这个投票信息发送给集群中其他机器。
(2) 集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。
LOOKING
寻找leader状态
当前服务器处于该状态时，它会认为当前集群中没有leader，因此需要进入leader选举状态。
FOLLOWING
跟随者状态
表示当前服务器的角色是Follower角色
LEADING
领导者状态
表示当前服务器是Leader
OBSERVING
观察者状态
表示当前服务器角色是Observer；
(3) 处理投票，针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下：
优先检查ZXID，ZXID比较大的服务器优先作为Leader；（相等，都是0）
如果ZXID相同，那么就比较myid，myid大的服务器作为Leader服务器；

对于zookeeper1而言，它的投票是 (0, 1)，接收zookeeper2的投票为 (0, 2,)，首先会比较两者的ZXID，均为0，再比较myid，此时zookeeper2的myid最大，zookeeper2成为leader，同时每个zookeeper更新自己的投票为 (0,2)，然后重新投票，对于zookeeper2而言，其无须更新自己的投票，只是再次向集群中所有机器发送上一次投票信息即可；

(4) 统计投票，每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于zookeeper1、zookeeper2而言，都统计出集群中已经有两台机器接受了 (0,2) 的投票信息， 此时便认为已经选出了Leader；
(5) 改变服务器状态，一旦确定了Leader，每台服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。

2、服务器运行期间的Leader选举
在Zookeeper运行期间，Leader与非Leader服务器各司其职，如果有非Leader服务器宕机或新加入，此时不会影响Leader，但是一旦Leader服务器宕机，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致；假设正在运行的有zookeeper1、zookeeper2、zookeeper3三台服务器，当前Leader是zookeeper2，若某一时刻Leader宕机了，此时便开始Leader选举，选举过程如下：
(1) 变更状态，Leader宕机后，余下的服务器都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程；
(2) 每个zookeeper会发出一个投票，在运行期间，每个服务器上的ZXID可能不同，此时假定zookeeper1的ZXID为128，zookeeper3的ZXID为127；在第一轮投票中，zookeeper1和zookeeper3都会将票投给自己，产生投票(128, 1)，(127, 3)，然后各自将投票发送给集群中其他机器；
(3) 接收来自各个服务器的投票，与自己的投票进行比较，此过程与启动时相同；
(4) 处理投票，与启动时过程相同，此时（zookeeper1将会成为Leader）；
(5) 统计投票，与启动时过程相同。
(6) 改变服务器的状态，与启动时过程相同。

Zookeeper有三个角色：领导者、跟随者、观察者，不同角色来执行不同的任务。
首先梳理几个概念：

1. 事务请求：
   在zk中，那些会改变服务器状态的请求称为事务请求（创建节点、更新数据、删除节点、创建会话等等）
2. 非事务请求
   从zk读取数据，但是不对状态进行任何修改的请求称为非事务请求；

leader角色:
leader服务器是zk集群工作的核心,其主要工作有两个,
1.事务请求的唯一调度者和处理者,保证集群事物处理的顺序性.
2.集群内部各个服务器的调度者

Follower是zk集群的跟随者，其主要工作有三个：

1. 处理客户端非事务性请求，转发事务请求给Leader服务器（事务请求都由Leader处理）
2. 参与事务请求的投票 (同步master事物操作,做出回馈,master只有接收到半数以上的回馈投票才认为该事物操作,执行成功,此时的回馈投票就是事物投票)
3. 参与Leader选举投票

Observer充当观察者角色；Observer观察者是另一种跟随者；

1. 观察zk集群的最新状态变化并将这些状态同步过来;
2. 对于非事务请求可以进行独立的处理，对于事务请求，则会转发给Leader服务器进行处理;
3. Observer不会参与任何形式的投票，包括事务请求的投票和Leader选举的投票；

如何配置observer模式？
在任何想变成observer模式的配置文件中加入如下配置：
peerType=observer
并在所有server的配置文件中，配置成observer模式的server的那行配置追加:observer，例如：
peerType=observer
server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890
server.4=localhost:2891:3891:observer

为什么有Observer角色
我们知道ZooKeeper的ZNode变更是要过半数投票通过，随着机器的添加，因为网络消耗等原因必定导致投票成本增加，从而导致写性能的下降。
Observer是一种新型的ZooKeeper节点，能够帮助解决上述问题，提供ZooKeeper的可扩展性。Observer不參与投票，仅仅是简单的接收投票结果。因此我们添加再多的Observer，也不会影响集群的写性能。除了这个区别，其它的和Follower基本上全然一样。比如：Client都能够连接到他们（Observer），而且都能够发送读写请求给他们，收到写请求都会上报到Leader。
Observer有另外一个优势，由于它不參与投票，所以他们不属于ZooKeeper集群的关键部位，即使他们Failed，或者从集群中断开，也不会影响集群的可用性。

zookeeper监控与运维
在zoo.cfg文件最下面加上如下配置开启四字命令白名单：
4lw.commands.whitelist=stat, ruok, conf
或者
4lw.commands.whitelist=* --所有4字命令都可以用
（1）输出server的详细配置信息，（如果没有nc，需要安装：yum install nc -y）
echo conf | nc localhost 2181

image.png

（2）输出指定server上所有客户端连接的详细信息，包括连接信息的总览，连接ip、端口号、该连接的发包数、该连接的收包数、连接的session Id、最后操作方式/命令、连接的时间戳、超时时间（未确认）、最后的zxid、最后、响应时间戳、连接的时间延时信息等；
echo cons | nc localhost 2181

image.png

（3）功能性命令，重置所有连接的统计信息
echo crst | nc localhost 2181

image.png

（4）输出所有等待队列中的会话和临时节点的信息，这个命令针对Leader执行；
echo dump | nc localhost 2181

image.png

（5）输出server简要状态和连接的客户端信息
echo stat | nc localhost 2181

image.png

（6）列出所有watcher信息，以watcher的session为归属单元排列，列出该会话订阅了哪些path；
echo wchc | nc localhost 2181

image.png

（7）输出一些ZK运行时信息,版本、延时、收包、发包、连接数、未完成客户端请求数、leader/follower 状态、znode 数、watch 数、临时节点数、近似数据大小 应该是一个总和的值、打开文件描述符 数、最大文件描述符数、fllower数等等；

image.png

image.png

Zookeeper服务监控

公司有zookeeper的集群环境，如何在线监控，淘宝针对监控Zookeeper的推出的一个开源项目TaoKeeper，不过很久没有更新了；

下载地址：https://github.com/alibaba/taokeeper/downloads

image.png

部署步骤
1.数据库准备
下载taokeeper.sql,初始化mysql数据库;
2.部署程序
下载taokeeper-monitor.tar.gz包，然后解压到tomcat的webapp下;
3.配置文件设置
taokeeper-monitor-config.properties存放到指定路径，比如：tomcat /webapp/项目/taokeeper-monitor-config.properties

image.png

4.Tomcat启动配置

catalina.sh配置（配置在第一行即可）

JAVA_OPTS=”-DconfigFilePath="配置文件路径taokeeper-monitor-config.properties”

浏览器访问：http://192.168.10.128:8080/taokeeper-monitor

image.png