zookeeper集群

环境:

  • 拥有三台服务器,假设三台服务器的Ip地址为 172.18.19.143,172.18.19.15,172.18.19.129
  • 开放三台服务器的2287,3387端口

集群搭建步骤:

1. 修改zookeeper服务器对应的配置文件:添加

server.1=172.18.19.143:2287:3387
server.2=172.18.19.15:2287:3387
server.3=172.18.19.129:2287:3387

说明:

#集群配置信息
#server.A=B:C:D
# A:是一个数字,表示这个是服务器编号
# B:是这个服务器的ip地址
# C:zk服务器之间的通信端口
# D:Leader选举的端口

2. 在zk的新建的data目录下新建文件myid,将步骤1中的数字A添加到文件中

3. 使用./zkCli.sh -server 172.18.19.143:2181 登录指定的服务器

至此,集群已搭建完成。

zookeeper一致性协议:

zab协议全称为Zookeeper Atomic Broadcat(zk原子广播)。zk是通过zab协议来保证分布式事务的最终一致性。

基于zab协议,zk集群中的角色主要有以下三类:

  • Leader: 领导者负责进行投票的发起和决议,更新系统状态。
  • Learner:
    • Follower: Follower用于接收客户请求并向客户端返回结果,在选举过程中参与投票
    • Observer: Observer可以接收客户端连接,将写请求转发给leader节点。但Observer不参与投票过程,只同步leader的状态。Observer的目的是为了扩展系统,以提高读取速度。
  • Client:请求发起方

写请求保持一致性过程:

  1. leader从客户端收到一个写请求
  2. leader生成一个新的事务并为这个事务生成一个唯一的ZXID
  3. leader将这个事务提议(propose)发送给所有的follows节点
  4. follower节点将收到的事务请求加入到历史队列(history queue)中,并发送ack给leader
  5. 当leader收到大多数follower(半数以上节点)的ack消息,leader会发送commit请求
  6. 当follower收到commit请求时,从历史队列中将事务请求commit

zookeeper的leader选举:

服务器状态:

  • looking:寻找leader状态。当服务器处于该状态时,它会认为当前集群没有leader,因此需要进入leader选举状态。
  • leading:领导者状态。表明当前服务器角色是leader.
  • following: 跟随者状态。表明当前服务器角色是follower。
  • observing: 观察者状态。表明当前服务器角色是Observer。

服务器启动时期的leader选举:

在集群初始化阶段,当有一台服务器server1启动时,其单独无法进行和完成leader选举,当第二台服务器server2启动时,此时两台机器可以相互通信,每台机器都试图找到leader,于是进入leader选举过程。选举过程如下:

  1. 每个server发出一个投票。由于是初始情况,server1和server2都会将自己作为leader服务器来进行投票,每次投票会包含所推举的服务器的myid和zxid,使用(myid,zxid)来表示,此时server1的投票为(1,0),server2的投票为(2,0),然后各自将这个投票发给集群中的其它机器。
  2. 集群中的每台服务器接收来自集群中各个服务器的投票。
  3. 处理投票。针对每一个投票,服务器都需要将别人的投票和自己的投票进行Pk,pk规则如下:  
    • 优先检查zxid。zxid比较大的服务器优先作为leader。
    • 如果zxid相同,那么就比较myid。myid较大的服务器作为leader服务器。
    • 对于server1而言,它的投票是(1,0),接收server2的投票为(2,0),首先会比较两者的zxid,均为0,再比较myid,此时server2的myid最大,于是更新自己的投票为(2,0),然后重新投票;对于server2而言,其无需更新自己的投票,只是再次向集群中所有机器发出上一次投票信息即可
  4. 统计投票。每次投票后,服务器都会统计投票信息,判断是否已经有过半机器接收到相同的投票信息,对于server1、server2而言,都统计出集群中已经有两台机器接收了(2,0)的投票信息,此时便认为已经选举出了leader。
  5. 改变服务器状态。一旦确定了leader,每个服务器就会更新自己的状态,如果是follower,那么就变更为following,如果是leader,就会变更为leading。

服务器运行时期的Leader选举:

在zk运行期间,leader与非leader服务器各司其职,即便当有非leader服务器宕机或者新加入,此时也不会影响leader,但是一旦leader服务器宕机了,那么整个集群将会暂停对外服务,进入新一轮leader选举,其过程和启动时期的Leader选举过程基本一致。

假设正在运行的有server1,server2,server3三台服务器,当前leader是server2,若某一时刻leader挂了,此时便开始leader选举。选举过程如下:

  1. 变更状态。leader挂后,余下的服务器会将自己的服务器状态变更为looking,然后开始进入leader选举过程。
  2. 每个server会发出一个投票。在运行期间,每个服务器上的zxid可能不同,此时假定server1的zxid为122,server3的zxid为122,在第一轮投票中,server1和server3都会投自己,产生投票(1,122),(3,122),然后各自将自己的投票发送给集群中的所有机器。
  3. 接收来自各个服务器的投票.与启动过程相同。
  4. 处理投票。与启动过程相同。此时,server3将会成为leader.
  5. 统计投票。与启动时过程相同。
  6. 改变服务器的状态。与启动时过程相同。

observer角色及其配置:

observer角色特点:

  1. 不参与集群的leader选举
  2. 不参与集群中写数据时的ack反馈

配置步骤:

  1. 为了使用observer角色,在任何想编程observer角色的配置文件中加入如下配置:
    • peerType=observer

    • 在所有server的配置文件中,配置成observer模式的server的那行配置追加:observer,例如:

      server.3=192.168.60.130:2289:3389:observer

  

上一篇:关于GitHub 服务中断 24 小时 11 分钟事故


下一篇:哄上面应付下面,分身乏术,刚升职的人如何当好一线领导?