为什么要使用zookeeper(chubby开源实现)— 动物园管理员
-
协调分布式环境下的服务
-
解决分布式环境中的问题
-
分布式环境下无法保证顺序执行
-
分布式环境下无法明确执行结果（可能由于网络的波动,无法判断结果是否执行成功）
-
无法保证数据一致性
-
-
应用
-
和dubbo配合保证多点服务的可用性
-
hadoop确保整个集群只有一个NameNode,存储配置信息等
-
HBASE确保整个集群只有一个HMaster
-
-
Paxos
-
文章 https://blog.csdn.net/dajiangtai007/article/details/68488701
-
有一个叫做Paxos的小岛(Island)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)。
-
议员的总数(SenatorCount)是确定的，不能更改。
-
岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒退。
-
每个提议都需要超过半数((SenatorCount)/2+1)的议员同意才能生效。
-
每个议员只会同意大于当前编号的提议，包括已生效的和未生效的。
-
如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号，他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。 现在议会有一个目标：保证所有的议员对于提议都能达成一致的看法。
-
-
理解zookeeper原理
-
image.png
-
角色说明
-
leader（只有这个角色能提出proposal，保证提议的顺序）
-
server（议员）
-
client（客户端）
-
proposal 提议（znode）
-
zxid 编号
-
-
-
场景
-
client找议员（server）询问（查询）某一条法令，议员回答且同时声明自身数据不一定是最新的，如需最新数据需要clent调用sync方法确认
-
clent找议员提交一个法令（create），议员将建议提交给leader，由leader发起投票且产生结果，最终告诉client
-
leader挂了期间，整个服务无法进行，直到选出新的leader
-
-
CAP —> CA
-
-
zab 原子广播（zookeeper核心）
-
数据交互图
-
image.png
image.png
-
角色
-
server
-
leader（投票的发起和决议,更新状态）
-
learner
-
follower （参与投票，接受客户端请求并返回结果）
-
observer 和follower功能一致，但不投票 提高读取速度
-
-
-
client
-
-
交互过程
-
request —> (follower 或者 observer) update操作,query操作会直接返回
-
request 转给leader ， leader自己先更新
-
leader 向其他的所有follower抛出proposal，
-
follower向leader 确认ack
-
leader汇总结果之后，向所有follower 发送commit
-
-
-
Zab协议 zookeeper automatic broadcast 两种模式
-
恢复(选主)模式，可用性 - 当服务重启或者在leader崩溃之后，进入恢复模式，当leader被选举出来且大多数server完成了和leader的状态同步后恢复模式结束。
-
广播模式（同步）一致性
-
-
选举，不一定非是奇数台
-
奇数和偶数台的容错是一样的，没有必要用偶数台，节省资源（4台机器，保障集群运行的情况下，允许有一台挂掉，3台机器，保障集群运行的情况下，允许有一台机器挂掉）
-
半数以上就可以选举出leader，如果是三台机器，第二台启动的是leader，类推，5台的话第三个启动的就是leader
-
-
网友评论