（纯干货）从几个实例出发-----理解zookeeper概念（架构分析）
什么是zookeeper，对于刚接触分布式的朋友（包括我）来说，这都是一个很难解释的问题。我们在网上或者论文亦或是书籍中看到的zookeeper的概念解释都十分生涩难懂。因此这里我们通过几个案例，我们通过分析这些工程的架构以及改进后的架构来引入zookeeper的概念。
1.现在有这样一个需求，有一组（很多台）服务器，他们构成了服务端，主要用来采集网络上的数据，现在客户端也是一组（很多台）服务器，他们用来分析服务端传过来的数据，因为数据是实时源源不断的流入服务端，因此它在进入客户端服务器时也是实时流入的，具体架构如下图：
这时候我们的客户端服务器在分析数据时可能就会出问题，因为数据实时流入，数据量过大就可能使某台客户机宕机。一旦某台客户服务器宕机，则该部分数据就无法分析，而新的数据还继续流入服务端的服务器从而覆盖了未分析的那些数据，可能会引发较为严重的问题。这个时候，我们可能会思考，我们给每一台客户服务器都增加一个slave服务器（从服务器），这样一旦某台服务器宕机，它的slave将会代替原来的服务器继续工作。其架构如下：
但是这样做又会引发一系列的问题，如我们的slave如何才能知道主服务器（原来工作的服务器）的工作进度以实现能够接续它原来的进度工作，如何获取主服务器的配置信息？我们可以考虑引入数据库，将这些记录在数据库中，一旦主服务器宕机，slave就从数据库读取信息继续接着主服务器之后工作。但是在这种环境中配置数据库又成了一件很困难的事，可能会连锁遇到更多的问题，而且每一对主从服务器都需要记录这样的信息，往往集群中有几十台几百台服务器，在添加这些记录时很容易出错且很麻烦。
这时候我们就想，如果有这样一个第三方平台，能够记录下每一台服务器的工作进度，并且可以监控所有的服务器就好了。这时候，zookeeper登场了。它刚好可以做这样两件事，我们来看看它是不是解决了上面的问题。
首先，zookeeper记录了所有的客户服务器的工作进度和配置信息；其次，zookeeper可以帮助我们监控所有的服务。当某一台服务器发生故障时，他能立刻检测到，并给其他的服务器发通知，告知其他正常的服务器：某服务器发生故障不能正常工作，需要求助。这时空闲的服务器或是某负荷小的服务器（可以人为敲代码修改规则）就会从zookeeper读取宕机服务器的工作进度和配置等信息，暂时接管当即服务器的工作。当宕机服务器恢复正常后再将工作交还给该服务器。
其架构如下：
只是在其中加入了一个第三方zookeeper，就完美的解决了上述令人头疼的问题。这是因为zookeeper本身是高可靠的。为什么说它高可靠呢。因为zookeeper本身也是一个分布式集群，它的内部一般有奇数个服务器，只要有半数以上的服务器正常运行就可以保证zookeeper的正常运转。
2.现在我们来看第二个实例，我们将需求反过来，现在有一个客户端，想要访问服务器，服务器有多台，但是在一个时间段工作的服务器（master）只有一台，其他的服务器是为了防止当前工作的服务器宕机时备用的，都是slave。可是在最初的时候我们怎么选取master主机呢。这就涉及到服务器主从选举问题。
我们同样可以引入zookeeper。我们人为编写代码制定一套选举主从服务器的规则（如谁的ip地址大就是主服务器）。指定完之后主服务器的信息以及工作进度就会记录在zookeeper中，并且zookeeper可以监控这些服务器。客户机发送的请求就会进入到master，由master完成交互。一旦master发生故障，其余的slave再次根据制定的规则选出一个新的master并获取原来master的工作记录继续继承原master工作。怎么样，这个是不是不难理解吧！
我们通过上面两个实际的案例分析，可以发现，他们都有一个共同的特点，就是他们都需要一个第三方平台能够保管数据，并且提供节点监听。这正是zookeeper做的核心的两件事。
这样一来，大家应该对zookeeper究竟是做什么的有一个比较直观的了解了吧。关于具体的zookeeper的定义网上资料很多，这里就不重复抄下来了。