分布式环境下需要解决的问题

  1. 各个节点的数据一致性
  2. 保证某一个任务只在一个节点执行,比如说定时任务
  3. 如果集群的机器中有一台挂掉,怎么告知其他节点并接替任务
  4. 一些共享资源需要保证互斥和安全性,不能同时修改
  5. 所以需要引入分布式协调服务解决上述问题

分布式协调服务设计猜想

  1. 所有节点统一到协调服务注册,然后让协调服务管理节点的调用
  2. 因为所有节点都要调用协调服务,所以协调服务需要使用集群,提高可用性,防止单点故障导致所有节点挂掉,而且可以分担请求带来的流量
  3. 协调服务做集群的话,如果要保证每个节点都收到请求,并且处理的话,就要面临着数据一致性的问题,所以需要选出一台 leader 节点负责协调节点和数据同步的操作
  4. 如果 leader 挂了怎么办,所以在 zookeeper 中引入了基于 paxos 理论衍生的 ZAB 协议

zookeeper 的集群角色

image

  1. 有三种角色 Leader、Follower、Observer
  2. Leader
    • 是事务请求的唯一调度和处理者,保证集群事务处理的顺序序性
    • 是集群内部各服务器的调度者
  3. Follower
    • 处理客户端非事务请求,转发事务请求给 Leader 服务器
    • 参与事务请求 Proposal 的投票
    • 参与 Leader 的选举投票
  4. Observer
    • 处理客户端非事务请求,转发事务请求给 Leader 服务器
    • 不参加任何形式的投票,包括选举和事务投票 (超过半数确认)
    • 它的存在是为了提高 zk 集群对外提供读性能的能力
  5. 当收到非事务请求时,任意一个节点收到都可以直接处理
  6. 当收到事务请求时:
    • 如果是 Follower 或者 Observer,都需要把请求转发给 Leader
    • 然后 Leader 把事务转发给所有 Follower 节点(Observer 不需要)
    • 所有 Follower 节点会返回 Leader 节点答复,告知是否可以执行,当收到过半数的 Follower 节点同意执行事务的请求,则会提交当前事务

ZAB 协议

  1. 支持崩溃回复的原子消息广播协议、主要用于实现 zk 集群数据的一致性
  2. 消息广播模式
    • Leader 服务器对事务请求生成一个全局的的递增事务 ZXID,保证每个消息的因果关系的顺序(64 位自增 ID)
    • Leader 为每一个 Follower 服务器都各自分配一个单独的队列,然后将需要广播的带有 zxid 的消息作为事务 Proposal 依次放入这些队列中去,并根据 FIFO 策略进行消息发送
    • 每一个 Follower 服务器在接收到这个事务 Proposal 之后,首先以日志形式写入本地磁盘,并且成功写入后反馈给 Leader 服务器一个 Ack 响应
    • 当 Leader 服务器接收超过半数的 Follower 的 Ack 响应,Leader 自身也会完成对事务的提交。同时就会广播一个 Commit 消息给所有的 Follower 服务器以通知进行事务提交。每一个 Follower 服务器在接收到 Commit 消息后,也会完成对事务的提交。
  3. 崩溃恢复
    • 当 Leader 失去过半的 Follower 节点的联系或者自己挂了的时候,集群就会进入崩溃恢复阶段
    • 崩溃恢复要保证已被处理的消息不能被丢失,假设 Leader 在自己提交事务后,通知 Follower 节点提交事务时挂掉,需要保证这个数据在重新选出 Leader 后一样能同步到各节点
    • 崩溃恢复还需要保证丢弃那些只在 Leader 服务器上被提出的事务。假设 Leader 在收到事务请求准备通知 Follower 投票时挂掉了,需要保证重新选出 Leader 后这条消息需要被丢弃

感谢    关注    收藏    赞同    反对    举报    分享