程序员快速提升：精通Zookeeper的经典应用场景

内容一：(补充)zookeeper集群的工作原理

zookeeper提供了重要的分布式协调服务，它是如何保证集群数据的一致性的?

① ZAB协议的简单描述

ZAB(zookeeper atomic broadcast)---zookeeper 原子消息广播协议是专门为zookeeper设计的数据一致性协议，注意此协议最主要的关注点在于数据一致性，而无关乎于数据的准确性，权威性，实时性。

ZAB协议过程

1.所有事务转发给leader(当我们的follower接收到事务请求)

2.Leader分配全局单调递增事务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的联系，那么就会进入崩溃恢复模式

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

此时第二个port，就是崩溃恢复模式要使用到的

所以此时我们ZAB协议的选举算法应该满足：确保提交已经被leader提交的事务proposal，同时丢弃已经被跳过的事务proposal

如果让leader选举算法能够保证新选举出来的leader拥有集群中所有机器的最高zxid的事务proposal，那么就可以保证这个新选举出来的leader一定具有所有已经提交的提案，同时如果让拥有最高编号的事务proposal的机器来成为leader，就可以省去leader检查事务proposal的提交和丢弃事务proposal的操作。

③ ZAB协议的数据同步

leader选举完成后，需要进行follower和leader的数据同步，当半数的follower完成同步，则可以开始提供服务。

数据同步过程

④ ZAB协议中丢弃事务proposal

zxid=高32位+低32位=leader周期编号+事务proposal编号复制代码

事务编号zxid是一个64位的数字，低32位是一个简单的单调递增的计数器，针对客户端的每一个事务请求，leader产生新的事务proposal的时候都会对该计数器进行+1的操作，高32位代表了leader周期纪元的编号。

每当选举产生一个新的leader，都会从这个leader服务器上取出其本地日志中最大事务proposal的zxid，并从zxid解析出对应的纪元值，然后对其进行+1操作，之后以此编号作为新的纪元，并将低32位重置为0开始生产新的zxid。

基于此策略，当一个包含了上一个leader周期中尚未提交过的事务proposal的服务器启动加入到集群中，发现此时集群中已经存在leader，将自身以follower角色连接上leader服务器后，leader服务器会根据自身最后被提交的proposal和这个follower的proposal进行比对，发现这个follower中有上一个leader周期的事务proposal后，leader会要求follower进行一个回退操作，回到一个确实被集群过半机器提交的最新的事务proposal

⑤ zookeeper的可配置参数

可以从官网上了解zookeeper的可配置参数

zookeeper.apache.org/doc/current…

虽然是全英，但是当大家有需要使用到它们的时候，那英文就自然不成问题了是吧

内容二：zookeeper的典型应用场景

数据发布订阅命名服务master选举集群管理分布式队列分布式锁复制代码

1.分布式队列的应用场景

① 业务解耦

实现应用之间的解耦，这时所有的下游系统都订阅队列，从而获得一份实时完整的数据

解耦的应用非常广泛，比如我们常见的发货系统和订单系统，以前业务串行的时候，发货系统一定要等订单系统生成完对应的订单才会进行发货。这样如果订单系统崩溃，那发货系统也无法正常运作，引入消息队列后，发货系统是正常处理掉发货的请求，再把已发货的消息存入消息队列，等待订单系统去更新并生成订单，但是此时，订单系统就算崩溃掉，我们也不会一直不发货。

② 异步处理

可以看到在此场景中队列被用于实现服务的异步处理，这样做的好处在于我们可以更快地返回结果和减少等待，实现步骤之间的并发，提升了系统的总体性能等

② 流量削峰

2.zk的分布式队列

① 逻辑分析

（编辑：ASP站长网）