ZAB协议

ZAB 广播模式

Leader将所有的更新(写操作)(proposal(建议,提议)),顺序发送给Follower

当Leader收到板书以上Folloer对此proposal的ACK,即向所有的Follower发送commit消息,并在本地commit该消息

Follower收到Proposal后即将该Proposal写入磁盘,写入成功即返回ACK给leader

每个Proposal都有一个唯一的单调递增的proposal ID,即zxid

 

读操作和写操作

如果是读操作的话,那么客户端就直接找到Follower然后请求,follower将读取到的数据返回client

如果是写操作的话,那么client先找到Follower进行一个请求,这时follower会将请求转发给Leader,此时Leader会发送(porposal)给我们的集群,这时,如果超过半数的Follower对proposal进行了ACK,那么就向所有的Follower发送commit消息,进行提交

 

ZAB恢复模式

进入恢复模式

当Leader宕机或者丢失大多数的Folllower后,即进入恢复模式

结束恢复模式

新领导被选举出来,且大多数Follower完成了与Leader的状态同步后,恢复模式结束,从而进入广播模式

恢复模式的意义

1. 发现集群中被commit的proposal的最大zxid

2.建立新的epoch,从而保证之前的Leader不能在commit新的Proposal

3.急群众大部分节点都commit过前一个Leader commit 过的消息,而新的Leader是被大部分节点所支持的, 所以被之前的Leadercommit过的Proposal不会丢失,至少被一个节点保存

4. 新Leader会与所有Follower通信,从而保证大部分节点都拥有新的数据

 

Zookeeper的注意事项

1. 只保证一个客户端单一系统镜像,并不保证多个不同客户端在同一时刻一定看到同一系统镜像,如果要实现这种效果,需要在读取数据之前调用sync操作

2. Zookeeper读性能好于写性能,因为任何Server均可提供读服务,而只有Leader可提供写服务

3. 为了保证Zookeeper本身的leader Election顺利进行,通常将Server设置为奇数

4. 如需要容忍f个server的失败,必须保证有2f+1个以上的Server

你可能感兴趣的:(kafka)