某天程序员小白参加面试：

几番苦战之后，面试进入白热化阶段。面试官大开大合，小白见招拆招。一时之间，难解难分，两人对拆数十回合不分胜负。说时迟，那时快，小白的左手像火焰一般炙热，右手像冰霜一样寒冷…

面试官：我看你简历上写了熟悉zookeeper，你项目里用zookeeper干什么了？

小白：主要用来做dubbo的注册中心、分布式锁以及统一配置等

面试官：那你熟悉zookeeper集群模型吗？

小白：zookeeper集群是一主多从的模型，节点分成三种角色：leader、follower和observer。leader负责写、follower和observer负责读。（小白内心：面试官接下来该问我follower和observer的区别了）

面试官：你说zookeeper是一主多从，那么主挂掉了怎么办（单点故障）？

（小白内心：我勒个擦，怎么不按套路出牌。记得redis主从复制模型中，master挂掉之后是靠sentinel自动完成故障转移的。zookeeper好像没有sentinel…不过这可难不倒我）小白：我们系统的zookeeper非常稳定，leader不会挂

面试官：

可靠性

从zookeeper官网上的描述可以知道，zookeeper自称是高可用的，像这种自带高可用的中间件可不多见。zookeeper一主多从的模型，leader只有一个，注定会成为单点故障。

leader挂了不可怕，可怕的是没有leader。古代皇帝驾崩之后，大臣通常会说这样一句话：国不可一日无君，然后劝太子早承大统。

zookeeper的做法也是一样，就是尽最快的速度，从存活的follower中选出一个新leader。那么现在问题来了，皇帝驾崩之前往往已经立了太子，或者由嫡长子自动继承。但是对zookeeper来说，不可能提前选好下一个预备leader，并且follower之间也没有嫡庶之分，换言之，每个follower的身份都是平等的。

zookeeper采用了ZAB算法来解决选举的问题。

ZAB

ZAB（Zookeeper Atomic Broadcast，zookeeper原子广播），ZAB协议用来保证zookeeper各个节点之间数据的一致性。

ZAB协议包括如下特点：

leader从客户端或者follower那里收到一个写请求

本文链接: https://www.bigbaik.com/network/5152.html
免责声明：本文内容来自互联网，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请联系删除。