深入理解与应用Zookeeper(五)zookeeper集群

深入理解与应用Zookeeper(五)zookeeper集群

image.png

  • 顺序一致性 客户端的更新顺序与它们被发送的顺序相一致。
  • 原子性 更新操作要么成功要么失败,没有第三种结果。
  • 单一视图 无论客户端连接到哪一个服务器,客户端将看到相同的 ZooKeeper 视图。
  • 可靠性 一旦一个更新操作被应用,那么在客户端再次更新它之前,它的值将不会改变。
  • 实时性 连接上一个服务端数据修改,所以其他的服务端都会实时的跟新,不算完全的实时,有一点延时的
  • 角色轮换避免单点故障 当leader出现问题的时候,会选举从follower中选举一个新的leader

2. 集群中的角色

  • Leader 集群工作机制中的核心 事务请求的唯一调度和处理者,保证集群事务处理的顺序性 集群内部个服务器的调度者(管理follower,数据同步)
  • Follower 集群工作机制中的跟随者 处理非事务请求,转发事务请求给Leader 参与事务请求proposal投票 参与leader选举投票
  • Observer 观察者
    3.30以上版本提供,和follower功能相同,但不参与任何形式投票 处理非事务请求,转发事务请求给Leader 提高集群非事务处理能力

3. zk集群的配置

image.png

修改zoo_sample.cfg文件

cd /usr/local/zookeeper/conf
mv zoo_sample.cfg zoo.cfg

修改conf: vi zoo.cfg 修改两处

(1)在zk中创建data目录 并且添加一行配置信息:

dataDir=/usr/local/zookeeper/data

(2)最后面添加:

server.0=192.168.212.154:2888:3888
server.1=192.168.212.156:2888:3888
server.2=192.168.212.157:2888:3888

创建服务器标识

在data文件夹下 创建文件myid并填写内容为0:

vi myid #(内容为服务器标识 : 0)

复制zookeeper

复制zookeeper到node1和node2
把node1、 node2中的myid文件里的值修改为1和2

启动zookeeper

cd /usr/local/zookeeper/bin
zkServer.sh start

(注意这里3台机器都要进行启动)
使用./zkServer.sh status命令查看节点的状态
(在三个节点上检验zk的mode,一个leader和俩个follower) zk集群中 只有大多数节点运行正常 集群才能正确运行。所以集群中节点数需要设置为奇数个。

4. Zookeeper集群一致性协议ZAB解析

image.png (1)懂了paxos算法,其实zab就很好理解了。很多论文和资料都证明zab其实就是paxos的一种简化实现,但Apache 自己的立场说zab不是paxos算法的实现,这个不需要去计较。

(2)zab协议解决的问题和paxos一样,是解决分布式系统的数据一致性问题

(3)zookeeper就是根据zab协议建立了主备模型完成集群的数据同步(保证数据的一致性),前面介绍了集群的各种角色,这说所说的主备架构模型指的是,在zookeeper集群中,只有一台leader(主节点)负责处理外部客户端的事务请求(写操作),leader节点负责将客户端的写操作数据同步到所有的follower节点中。 image.png (4)zab协议核心是在整个zookeeper集群中只有一个节点既leader将所有客户端的写操作转化为事务(提议proposal).leader节点再数据写完之后,将向所有的follower节点发送数据广播请求(数据复制),等所有的follower节点的反馈,在zab协议中,只要超过半数follower节点反馈ok,leader节点会向所有follower服务器发送commit消息,既将leader节点上的数据同步到follower节点之上。 image.png 发现,整个流程其实和paxos协议其实大同小异。说zab是paxos的一种实现方式其实并不过分。 Zab再细看可以分成两部分。第一的消息广播模式,第二是崩溃恢复模式。 image.png 正常情况下当客户端对zk有写的数据请求时,leader节点会把数据同步到follower节点,这个过程其实就是消息的广播模式 在新启动的时候,或者leader节点奔溃的时候会要选举新的leader,选好新的leader之后会进行一次数据同步操作,整个过程就是奔溃恢复。

4.1 消息广播模式

image.png

为了保证分区容错性,zookeeper是要让每个节点副本必须是一致的

1.在zookeeper集群中数据副本的传递策略就是采用的广播模式 2.Zab协议中的leader等待follower的ack反馈,只要半数以上的follower成功反馈就好,不需要收到全部的follower反馈。

image.png

zookeeper中消息广播的具体步骤

  1. 客户端发起一个写操作请求
  2. Leader服务器将客户端的request请求转化为事物proposql提案,同时为每个proposal分配一个全局唯一的ID,即ZXID。
  3. leader服务器与每个follower之间都有一个队列,leader将消息发送到该队列
  4. follower机器从队列中取出消息处理完(写入本地事物日志中)毕后,向leader服务器发送ACK确认。
  5. leader服务器收到半数以上的follower的ACK后,即认为可以发送commit
  6. leader向所有的follower服务器发送commit消息。

zookeeper采用ZAB协议的核心就是只要有一台服务器提交了proposal,就要确保所有的服务器最终都能正确提交proposal。这也是CAP/BASE最终实现一致性的一个体现。

回顾一下:前面还讲了2pc协议,也就是两阶段提交,发现流程2pc和zab还是挺像的, zookeeper中数据副本的同步方式与二阶段提交相似但是却又不同。二阶段提交的要求协调者必须等到所有的参与者全部反馈ACK确认消息后,再发送commit消息。要求所有的参与者要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题,但paxos和2pc没有这要求。

为了进一步防止阻塞,leader服务器与每个follower之间都有一个单独的队列进行收发消息,使用队列消息可以做到异步解耦。leader和follower之间只要往队列中发送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多

4.2 崩溃恢复

image.png

背景(什么情况下会崩溃恢复)

  • zookeeper集群中为保证任何所有进程能够有序的顺序执行,只能是leader服务器接受写请求,即使是follower服务器接受到客户端的请求,也会转发到leader服务器进行处理。

  • 如果leader服务器发生崩溃(重启是一种特殊的奔溃,这时候也没leader),则zab协议要求zookeeper集群进行崩溃恢复和leader服务器选举。

最终目的(恢复成什么样)

ZAB协议崩溃恢复要求满足如下2个要求: 确保已经被leader提交的proposal必须最终被所有的follower服务器提交。 确保丢弃已经被leader出的但是没有被提交的proposal。

新选举出来的leader不能包含未提交的proposal,即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时,新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。

  • 每个Server会发出一个投票,第一次都是投自己。投票信息:(myid,ZXID)
  • 收集来自各个服务器的投票
  • 处理投票并重新投票,处理逻辑:优先比较ZXID,然后比较myid
  • 统计投票,只要超过半数的机器接收到同样的投票信息,就可以确定leader
  • 改变服务器状态

5. java客户端连接集群

image.png

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×