Zookeeper数据同步

目录

一、Zookeeper中角色

二、Observer集群搭建配置

传统方式

Docker方式

三、ZAB协议

四、Zookeeper数据同步

---

​​​​​​​

一、Zookeeper中角色

zookeeper服务器集群存在三种节点型

Leader（领导者）：各个节点之间的老大，是集群中的核心。没有leader集群将不能工作。所有的写请求最终都会转交给领导者Leader执行；与跟随者（Follower）和观察者(Observer)进行心跳连接;数据同步到Follower和Observer。

Follower(追随者)：跟随者自己不会执行写的操作，而是会将写的操作转交给Leader执行。负责处理Leader发来的请求和数据，当Leader宕机之后，会进行投票和选举（从剩余的Follwer）,从而选举新的Leader。

观察者（observer）：Observer同Follwer一样，也不能执行写操作，他的功能跟Follwer差不多。observer为用于提高读取吞吐量，减少选举的时候而生，因此Observer不能参与投票和选举。

二、Observer集群搭建配置

在这个基础上修改搭建ZooKeeper3.7.0集群（传统方式&Docker方式）

传统方式

dataDir =/usr/local/zookeeper/data
dataLogDir=/usr/local/zookeeper/logs
#ip对应的是你的ip
server.1=192.168.6.137:2888:3888
server.2=192.168.6.138:2888:3888
server.3=192.168.6.139:2888:3888
server.4=192.168.6.139:2888:3888:observer
server.5=192.168.6.139:2888:3888:observer

Docker方式

#节点1
docker run -d -p 2181:2181 --name zookeeper_node01 --privileged --restart always --network zoonet --ip 172.18.0.2 \
-v /data/zookeeper/cluster/zk1/data:/data \
-v /data/zookeeper/cluster/zk1/datalog:/datalog \
-v /data/zookeeper/cluster/zk1/logs:/logs \
-e ZOO_MY_ID=1 \
-e "ZOO_SERVERS=server.1=172.18.0.2:2888:3888;2181 server.2=172.18.0.3:2888:3888;2181 server.3=172.18.0.4:2888:3888;2181 server.4=172.18.0.5:2888:3888:observer;2181 server.5=172.18.0.6:2888:3888:observer;2181" zookeeper 
#节点2
docker run -d -p 2182:2181 --name zookeeper_node02 --privileged --restart always --network zoonet --ip 172.18.0.3 \
-v /data/zookeeper/cluster/zk2/data:/data \
-v /data/zookeeper/cluster/zk2/datalog:/datalog \
-v /data/zookeeper/cluster/zk2/logs:/logs \
-e ZOO_MY_ID=2 \
-e "ZOO_SERVERS=server.1=172.18.0.2:2888:3888;2181 server.2=172.18.0.3:2888:3888;2181 server.3=172.18.0.4:2888:3888;2181 server.4=172.18.0.5:2888:3888:observer;2181 server.5=172.18.0.6:2888:3888:observer;2181" zookeeper 

#节点3
docker run -d -p 2183:2181 --name zookeeper_node03 --privileged --restart always --network zoonet --ip 172.18.0.4 \
-v /data/zookeeper/cluster/zk3/data:/data \
-v /data/zookeeper/cluster/zk3/datalog:/datalog \
-v /data/zookeeper/cluster/zk3/logs:/logs \
-e ZOO_MY_ID=3 \
-e "ZOO_SERVERS=server.1=172.18.0.2:2888:3888;2181 server.2=172.18.0.3:2888:3888;2181 server.3=172.18.0.4:2888:3888;2181 server.4=172.18.0.5:2888:3888:observer;2181 server.5=172.18.0.6:2888:3888:observer;2181" zookeeper 
#节点4
docker run -d -p 2184:2181 --name zookeeper_node04 --privileged --restart always --network zoonet --ip 172.18.0.5 \
-v /data/zookeeper/cluster/zk4/data:/data \
-v /data/zookeeper/cluster/zk4/datalog:/datalog \
-v /data/zookeeper/cluster/zk4/logs:/logs \
-e ZOO_MY_ID=4 \
-e PEER_TYPE=observer \
-e "ZOO_SERVERS=server.1=172.18.0.2:2888:3888;2181 server.2=172.18.0.3:2888:3888;2181 server.3=172.18.0.4:2888:3888;2181 server.4=172.18.0.5:2888:3888:observer;2181 server.5=172.18.0.6:2888:3888:observer;2181" zookeeper 
#节点5
docker run -d -p 2185:2181 --name zookeeper_node05 --privileged --restart always --network zoonet --ip 172.18.0.6 \
-v /data/zookeeper/cluster/zk5/data:/data \
-v /data/zookeeper/cluster/zk5/datalog:/datalog \
-v /data/zookeeper/cluster/zk5/logs:/logs \
-e ZOO_MY_ID=5 \
-e PEER_TYPE=observer \
-e "ZOO_SERVERS=server.1=172.18.0.2:2888:3888;2181 server.2=172.18.0.3:2888:3888;2181 server.3=172.18.0.4:2888:3888;2181 server.4=172.18.0.5:2888:3888:observer;2181 server.5=172.18.0.6:2888:3888:observer;2181" zookeeper 

 可看到新增的节点已经为Observer角色了。

三、ZAB协议

Zookeeper Atomic Broadcast (ZAB) ：ZooKeeper并没有完全采用Paxos算法，而是使用了一种称为zookeeper原子消息广播协议的协议作为其数据一致性的核心算法。所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。

Zookeeper 的核心是原子广播机制，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。

恢复模式
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server 完成了和 leader 的状态同步以后，退出恢复模式进入广播模式。状态同步保证了 leader 和 server 具有相同的系统状态。

广播模式
一旦 leader 已经和多数的 follower 进行了状态同步后，它就可以开始广播消息了，即进入广播状态。这时候当一个 server 加入 ZooKeeper 服务中，它会在恢复模式下启动，自觉的发现 leader，并和 leader 进行状态同步。待到同步结束，它也退出恢复模式，进入广播模式。ZooKeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的 followers 支持。

四、Zookeeper数据同步

1、leader 接受到消息请求后，将消息赋予给一个全局唯一的64位自增id，叫：zxid。
2、leader 为每个follower 准备了一个FIFO队列（通过TCP协议来实现，以实现了全局有序这个特点）将带有zxid的消息作为一个提案（proposal）分发给所有的follower。
3、当follower接受到proposal，先把proposal写到磁盘，写入成功以后再向leader恢复一个ack
4、当leader 接受到合法数量（超过半数节点）的 ack，leader 就会向这些follower发送commit命令，同时会在本地执行该消息
5、当follower接受到消息的commit命令以后，就会提交该消息。

参考：https://blog.csdn.net/qq_39938758/article/details/105754198