zookeeper理论学习(paxos和Zab协议)

为什么要使用zookeeper(chubby开源实现)— 动物园管理员

  • 协调分布式环境下的服务

  • 解决分布式环境中的问题

    1. 分布式环境下无法保证顺序执行

    2. 分布式环境下无法明确执行结果(可能由于网络的波动,无法判断结果是否执行成功)

    3. 无法保证数据一致性

  • 应用

    • 和dubbo配合保证多点服务的可用性

    • hadoop确保整个集群只有一个NameNode,存储配置信息等

    • HBASE确保整个集群只有一个HMaster

  1. Paxos

    1. 文章 https://blog.csdn.net/dajiangtai007/article/details/68488701

      1. 有一个叫做Paxos的小岛(Island)上面住了一批居民,岛上面所有的事情由一些特殊的人决定,他们叫做议员(Senator)。

      2. 议员的总数(SenatorCount)是确定的,不能更改。

      3. 岛上每次环境事务的变更都需要通过一个提议(Proposal),每个提议都有一个编号(PID),这个编号是一直增长的,不能倒退。

      4. 每个提议都需要超过半数((SenatorCount)/2+1)的议员同意才能生效。

      5. 每个议员只会同意大于当前编号的提议,包括已生效的和未生效的。

      6. 如果议员收到小于等于当前编号的提议,他会拒绝,并告知对方:你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号,他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。 现在议会有一个目标:保证所有的议员对于提议都能达成一致的看法。

    2. 理解zookeeper原理

      1. 《zookeeper理论学习(paxos和Zab协议)》 image.png
      2. 角色说明

        1. leader(只有这个角色能提出proposal,保证提议的顺序)

        2. server(议员)

        3. client(客户端)

        4. proposal 提议(znode)

        5. zxid 编号

    3. 场景

      1. client找议员(server)询问(查询)某一条法令,议员回答且同时声明自身数据不一定是最新的,如需最新数据需要clent调用sync方法确认

      2. clent找议员提交一个法令(create),议员将建议提交给leader,由leader发起投票且产生结果,最终告诉client

      3. leader挂了期间,整个服务无法进行,直到选出新的leader

    4. CAP —> CA

  2. zab 原子广播(zookeeper核心)

    1. 数据交互图

      1. 《zookeeper理论学习(paxos和Zab协议)》 image.png
        《zookeeper理论学习(paxos和Zab协议)》 image.png
      2. 角色

        1. server

          1. leader(投票的发起和决议,更新状态)

          2. learner

            1. follower (参与投票,接受客户端请求并返回结果)

            2. observer 和follower功能一致,但不投票 提高读取速度

        2. client

      3. 交互过程

        1. request —> (follower 或者 observer) update操作,query操作会直接返回

        2. request 转给leader , leader自己先更新

        3. leader 向其他的所有follower抛出proposal,

        4. follower向leader 确认ack

        5. leader汇总结果之后,向所有follower 发送commit

    2. Zab协议 zookeeper automatic broadcast 两种模式

      1. 恢复(选主)模式,可用性 – 当服务重启或者在leader崩溃之后,进入恢复模式,当leader被选举出来且大多数server完成了和leader的状态同步后恢复模式结束。

      2. 广播模式(同步)一致性

    3. 选举,不一定非是奇数台

      1. 奇数和偶数台的容错是一样的,没有必要用偶数台,节省资源(4台机器,保障集群运行的情况下,允许有一台挂掉,3台机器,保障集群运行的情况下,允许有一台机器挂掉)

      2. 半数以上就可以选举出leader,如果是三台机器,第二台启动的是leader,类推,5台的话第三个启动的就是leader

    原文作者:qtshe
    原文地址: https://www.jianshu.com/p/d1f164bb6ae6
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞