Zookeeper的几个应用场景与解决方法

场景一有这样一个场景：系统中有大约100w的用户，每个用户平均有3个邮箱账号，每隔5分钟，每个邮箱账需要收取100封邮件，最多3亿份邮件需要下载到服务器中(不含附件和正文)。用20台机器划分计算的压力，从多个不同的网路出口进行访问外网，计算的压力得到缓解，那么每台机器的计算压力也不会很大了。

每个子目录项如NameService都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。

3、集群管理所谓集群管理无在乎两点：是否有机器退出和加入、选举master。对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。

4、分布式锁有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建/distribute_lock节点，最终成功创建的那个客户端也即拥有了这把锁。

5、队列管理两种类型的队列：1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。2、队列按照FIFO方式进行入队和出队操作。第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。

系统模型如图所示：

1.2设计目的1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。2.可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。3.实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

fastpaxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。其流程图如下所示：

2.2同步流程选完leader以后，zk就进入状态同步过程。1.leader等待server连接；2.Follower连接leader，将最大的zxid发送给leader；3.Leader根据follower的zxid确定同步点；4.完成同步后通知follower已经成为uptodate状态；5.Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

2.3工作流程2.3.1Leader工作流程Leader主要有三个功能：1.恢复数据；2.维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；3.Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。

2.3.2Follower工作流程Follower主要有四个功能：1.向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；2.接收Leader消息并进行处理；3.接收Client的请求，如果为写请求，发送给Leader进行投票；4.返回Client结果。

对于observer的流程不再叙述，observer流程和Follower的唯一不同的地方就是observer不会参加leader发起的投票。附录：ZooKeeper典型使用场景一览ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得zookeeper能够应用于很多场景。