首页  思维导图  详情



 



Zookeeper

2021-11-12 11:37:24   4  举报





AI智能生成

分布式协调工具

zookeeper

模板推荐

作者其他创作

大纲/内容

集群

角色

Leader

处理所有的事务请求（写请求），可以处理读请求，集群中只能有一个Leader

Follower

只能处理读请求，同时作为 Leader的候选节点，即如果Leader宕机，Follower节点要参与到新的Leader选举中，有可能成为新的Leader节点

Observer

只能处理读请求。不能参与选举

多层队列架构

选举应用层

消息传输层<br>

启动或leader宕机选举leader流程

选票格式

vote(Myid,Zxid)

ZXID

1.高32位，可以看作epoch 值(leader选举周期)，当一轮新的选举结束后，会对这个值加一，并且事务id又从0开始自增

2.低 32 位可以看作是一个简单的递增的计数器

保证主从节点的状态同步？

ZAB(原子广播机制)

模式

广播模式(Leader可用)

说明

对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行commit 操作

存储

严格保证事务的顺序性，内部采用内存队列进行存放，事务标识为ZXID

备注

Leader收到半数Follower的Ack相应后，再发送Commit指令，再发送inform让Observe存储消息<br>

Leader写数据到自身本地内存后再告知Client，本次事务执行状态<br>

恢复模式(Leader不可用)

假设

1.Leader 在复制数据给所有 Follwer 之后，还没来得及收到Follower的ack返回就崩溃，怎么办？

2.Leader 在收到 ack 并提交了自己，同时发送了部分 commit 出去之后崩溃怎么办？

原则

1.ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务

2. ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交

特征

文件系统

监听通知

 收藏

立即使用

分布式锁

 收藏

立即使用

Zookeeper

 收藏

立即使用

Redis

 收藏

立即使用

puppy

职业：博士

去主页

 Collect

Get Started

Zookeeper

 Collect

Get Started

Zookeeper

 Collect

Get Started

zookeeper

 Collect

Get Started

Zookeeper脑图





0 条评论

下一页