直接干货,后续讲解!!!
使用教程:
第一步:
-
创建data目录
命令：cd zookeeper (进入zookeeper目录)
命令：mkdir data
第二步:
-
修改conf/zoo.cfg
命令：cd conf （进入conf目录）
命令：cp zoo_sample.cfg zoo.cfg（复制zoo_sample.cfg，文件名为zoo.cfg）##目的是为了保留原文件不至于改错了以后没有原文件可以参考修改回来
第三步:
- 命令：vim zoo.cfg (修改zoo.cfg)
内容修改：
dataDir = /usr/local/zookeeper/data
内容添加：(此处ip为你服务器的本地ip)
server.1=192.168.174.128:2182:3182
server.2=192.168.174.129:2182:3182
server.3=192.168.174.130:2182:3182
如图所示:
第四步:
- 在data目录创建创建myid
命令：cd .. (退出conf目录)
命令： cd data （进入data目录）
命令：vim myid（修改myid文件,分别设置三台服务器的文件内容为1,2,3）##此处比较重要,涉及到ZooKeeper选举机制
第五步:
- 启动ZooKeeper
命令：cd .. （退出data目录）
命令：cd bin(进入bin路径)
命令: ./zkServer.sh start ##分别在三台服务器启动
第六步:
-
查看zookeeper状态
命令：./zkServer.sh status
如果三台的服务器都出现这个返回,证明ZooKeeper启动成功了!!!
第七步:
想要在线上部署后使用还得在代码的配置文件中配置zookeeper的ip和端口号,如下图所示:
完成项目部署
**********************************************分隔符*********************************************************
详情讲解:
为什么是3台?
Zookeeper 集群搭建指的是 ZooKeeper 分布式模式安装。 通常由 2n+1台 servers 组成。 这是因为为了保证 Leader 选举（基于 Paxos 算法的实现） 能或得到多数的支持，所以 ZooKeeper 集群的数量一般为奇数。
角色分类：
Leader:Zookeeper(领导者):集群工作的核心
事务请求（写操作） 的唯一调度和处理者，保证集群事务处理的顺序性； 集群内部各个服务器的调度者。 对于 create， setData， delete 等有写操作的请求，则需要统一转发给leader 处理， leader 需要决定编号、执行操作，这个过程称为一个事务。
Follower（跟随者）
处理客户端非事务（读操作） 请求，转发事务请求给 Leader；参与集群 Leader 选举投票 2n-1台可以做集群投票。
Observer:观察者角色
针对访问量比较大的 zookeeper 集群， 还可新增观察者角色。观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给 Leader服务器进行处理。 不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。
ZooKeeper集群搭建有两种方式：
-
伪分布式集群搭建：
所谓伪分布式集群搭建ZooKeeper集群其实就是在一台机器上启动多个ZooKeeper，在启动每个ZooKeeper时分别使用不同的配置文件zoo.cfg来启动,每个配置文件使用不同的配置参数(clientPort端口号、dataDir数据目录.
在zoo.cfg中配置多个server.id，其中ip都是当前机器，而端口各不相同，启动时就是伪集群模式了。
这种模式和单机模式产生的问题是一样的。也是用在测试环境中使用。
-
完全分布式集群搭建：
多台机器各自配置zoo.cfg文件，将各自互相加入服务器列表，每个节点占用一台机器
Zoo.cfg参数详解：
1）tickTime：通信心跳数，Zookeeper服务器心跳时间，单位毫秒
Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。
它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime)
2）initLimit：LF初始通信时限
集群中的follower跟随者服务器(F)与leader领导者服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。
投票选举新leader的初始化时间
Follower在启动过程中，会从Leader同步所有最新数据，然后确定自己能够对外服务的起始状态。
Leader允许F在initLimit时间内完成这个工作。
3）syncLimit：LF同步通信时限
集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，
Leader认为Follwer死掉，从服务器列表中删除Follwer。
在运行过程中，Leader负责与ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。
如果L发出心跳包在syncLimit之后，还没有从F那收到响应，那么就认为这个F已经不在线了。
4）dataDir：数据文件目录+数据持久化路径
保存内存数据库快照信息的位置，如果没有其他说明，更新的事务日志也保存到数据库。
5）clientPort：客户端连接端口
监听客户端连接的端口
6）集群中服务的列表
server.1=192.168.174.128:2182:3182
server.2=192.168.174.129:2182:3182
server.3=192.168.174.130:2182:3182
server.* 后面的数据对应myid中的数字
ip地址对应每台虚拟机的ip地址
2182：表示的是这个服务器与集群中的 Leader 服务器交换信息的端口
3182：表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口leader选举：
在领导者选举的过程中，如果某台ZooKeeper获得了超过半数的选票，则此ZooKeeper就可以成为Leader了。
-
服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。
-
服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，
每个Server发出一个投票由于是初始情况，1和2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时1的投票为(1, 0)，2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。 接受来自各个服务器的投票集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器
处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下
· 优先检查ZXID。ZXID比较大的服务器优先作为Leader。
· 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器
对于服务器1而言，由于服务器2的编号大，更新服务器1的投票为(2, 0)，然后重新投票，对于2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可，此时集群节点状态为LOOKING。
统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息
-
服务器3启动，进行统计后，判断是否已经有过半机器接受到相同的投票信息，对于1、2、3而言，已统计出集群中已经有3台机器接受了(3, 0)的投票信息，此时投票数正好大于半数，便认为已经选出了Leader，
改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING
ZXID: 即zookeeper事务id号。ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
