Zookeeper集群及EFAK

在上一篇单机配置的基础上，假设我们做三台服务器的集群.

分别在三台服务器上进行安装.zookeeper-3.8.0

1.修改conf/zoo.cfg添加如下内容

dataDir=/home/zookeeper/zkData
dataLogDir=/home/zookeeper/zkLog
server.1=192.168.2.40:2182:2183
server.2=192.168.2.41:2182:2183
server.3=192.168.2.42:2182:2183:observer

语法：server.id=host:port1:port2

server固定。
id：集群中节点的唯一标志，是一个整形数字。
host：可以是ip，也可以是IP的映射。
port1：集群中进行leader选举的端口号。
port2：集群中服务器进行通信的端口。
集群中每个节点的zoo.cfg配置文件都要加上这段修改，这段修改就好比一个通信录，然集群中的每一个节点都能互相知道其他节点的存在。

集群中一台服务器需要三个端口，面向客户端连接的端口，集群中进行leader选举的端口、集群中服务器进行通信的端口。

指定某节点为Observer：

要设置为Observer节点的配置文件添加配置peerType=observer
在server.id=host:port1:port2 后面加observer ，比如server.3=192.168.2.42:2182:2183:observer
 

2.zookeepr数据目录添加myid文件，内容就是上面配置文件配置的server.id中的id.

代表集群服务器的唯一id。比如192.168.2.40服务器的id为1,192.168.4.21的id为2

分别在3台配置服务器上进行如上配置.

3.启动zookeeper查看服务状态.

./zkServer.sh start
./zkServer.sh status

状态如图:

至此zookeeper集群配置完毕.

3.修改kafka的confg/server.properties

zookeeper.connect=192.168.2.40:2181,192.168.2.41:2181,192.168.2.42:2181

 重新启动kafka即可。

4.修改efak的conf/system-config.properties文件

cluster1.zk.list=192.168.2.40:2181,192.168.2.41:2181,192.168.2.42:2181

 重启动efak服务.

bin/ke.sh restart

 5.打开efak后台如图所示:

 附集群角色介绍:

Leader：领导者，一个Zookeeper集群同一时间只能有一个Leader，，Leader服务器是整个Zookeeper集群工作制中的核心，其主要工作有以下：

事务请求的唯一调度和处理者，保证集群事务处理的顺序性。Zookeeper中所有事务操作都是由leader服务器进行处理。
集群内部服务器的调用者。
接受所有的Follower的提案请求并统一协调发起提案投票，负责与所有Follower进行内部数据交换（同步）。
Follower：跟随者，主要工作：

处理客户端的非事务请求，并转发事务请求给Leader服务器。
参与事务请求的同步提交投票。同时与Leader进行数据交换（同步）。
参与Leader选举投票。
Observer：观察者，从Zookeeper3.3.0引入的一个全新的服务器角色，该服务器充当一个观察者角色，观察Zookeeper集群的最新状态变化，并将这些状态变更同步过来。Observer服务器在工作原理上和Follower基本一致，对于非事务请求，可以直接独立处理，而对于事务请求，则会转发给Leader服务器进行处理。和Follower唯一区别是，Observer不参与任何形式投票，包括事务请求提交投票、Leader选举投票。仅仅观察集群状态变化并把变化同步过来。

Observer不属于Zookeeper的关键部位，通常用于在不影响集群事务处理能力的前提下提升进去非事务处理的能力，就是不影响集群写性能的情况下，提高集群读性能。因为使用增加Follower固然会提高集群的读性能，但是也会降低集群事务处理的写性能。因为Follower太多的话，会把时间浪费在事务投票同步过程和Leader选举过程中，因为要通信、投票的机器多了。而Observer不参与任何形式投票，仅仅只是进行读操作。所以增加再多Observer也不会影响集群的写性能，反而能够提升集群的读性能。但是Observer太多，而Follower太少的话会降低系统的可用性。

Zookeeper集群中有一半以上的机器正常工作的话，集群对外提供的服务就是可用的。假如有1个Leader，100个Follower，那么就算有50台机器宕机，集群照样可用。假设现在采用1个Leader，10个Follower，90个Observer的话，只要集群里面有大于5台机器宕机，集群就会处于不可用状态，至少处理不了事务请求，因为事务投票需要一半以上的同意，而可用的Leader加Follower已经不足一半了。