精通Zookeeper的经典应用场景

r分配全局单调递增事务id(zxid，也就是类似于paxos算法的编号n)，广播协议提议

3.Follower处理提议，作出反馈(也就是承诺只接受比现在的n编号大的

4.leader收到过半数的反馈，广播commit，把数据彻底持久化(和2pc不同的是，2pc是要等待所有小弟反馈同意)5.leader对原来转发事务的followe进行响应，follower也顺带把响应返回给客户端复制代码

还记得我们说过zookeeper比较适合读比较多，写比较少的场景吗，为什么我们说它效率高，我们可以知道，所有的事务请求，必须由一个全局唯一的服务器进行协调，这个服务器也就是现在的leader，leader服务器把客户端的一个写请求事务变成一个提议，这个提议通过我们的原子广播协议广播到我们服务器的其他节点上去，此时这个协议的编号，也就是zxid肯定是最大的。

由于我们的zxid都是由leader管理的，在上一节也是讲过，leader之所以能成为leader，本来就是因为它的zxid最大，此时的事务请求过来，leader的zxid本身最大的基础上再递增，这样新过来的事务的zxid肯定就是最大的。那么一连串的事务又是如何在leader中进行处理，leader中会内置一个队列，队列的作用就是用来保证有序性(zxid有序且队列先进先出原则)，所以后面来的事务不可能跳过前面来的事务。所以这也是ZAB协议的一个重要特性---有序性

② Leader崩溃时的举措

leader服务器崩溃，或者说由于网络原因导致leader失去了与过半follower的联系，那么就会进入崩溃恢复模式

我们回到上一节配置集群节点配置时，提到了在配置各节点时

（编辑：南昌站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!