zookeeper是一个很强大的分布式协调框架，这点经过很多成熟框架的使用都可以佐证zk的重要性，但是在学习zk之前还是要高明白，为什么我们需要zk。
之前我也有整理过分布式架构的演化方案，我们计算机应用，随着访问的流量越来越大，单机的算力不能满足，那么我们就需要单机变为集群，这里边又分为了应用集群，数据库集群，各种中间件的集群等等。
然而一旦单机演化为集群，虽然解决了单机的算力问题，但是诸多的机器就需要配合工作，比如数据库集群，主从模式，主写从读，我们可以把这个主从的关系写死在配置里，如果集群机器一直运转良好，那么万事大吉。不过一旦出现了一台机器故障，比如主节点故障，那么谁来担任写数据库的角色呢？如果不写死在服务器的配置里，那么这个关系我们又该怎么维护呢？
再比如一个redis集群，仍然是有主从模式，一旦master节点挂掉了，我们怎么重新竞选master呢？
好，到这里我们似乎也可以不使用分布式协调服务，最笨的办法，我们可以把规则持久化到某个数据库表里，序号最小的可用机器就是master，每次请求过来，每台服务器都判断一下自己是不是master节点，然后执行任务就好了。
听起来就很不靠谱吧，如果数据库挂掉了怎么办？如果master刚把写数据库的事务接受，但是还没处理，就挂掉了，怎么办？如果一个从数据库，刚判断自己可以当master了，然后又挂掉了，怎么办？
还有很多种情况，比如
分布式服务的调用顺序问题，我们期待的调用关系是先调用A，在调用B，可是实际情况A的调用延时了，结果B的调用在A之前发生，这怎么解决呢？
调用一个服务，但是返回了超时，那么我们真实的请求是调用成功了？还是失败了？除了重新调用以外，我们我发感知，这怎么办？
分布式数据一致性问题，我们触发了一个写操作，希望这时候所有来读这条变更数据的请求都能读到最新的数据，可是我们没办法保证请求的发起者调用集群的那一台机器，怎么保证数据的一致性同步呢？
所以归根结底，这就是系统调用三种状态导致的结果
- 成功
- 失败
- 超时
在不同的场景下，这些不同的状态在复杂业务场景下的多重组和就会导致千差万别的结果。日益庞大的服务器，亟需一个优异的管理者来进行管理。
所以，分布式协调的框架就是为了解决分布式系统的种种故障应急以及各个服务器之间的状态同步等逻辑处理而存在的。在诸多的分布式框架之中，zookeeper又是表现极为良好的一种。
说到这里，再聊聊zookeeper这个名字，动物园管理者。
其实最开始我接触zookeeper还是从hadoop开始的，hadoop是一头大象，hive是蜜蜂，这些不同的动物的混乱景象都由这个强悍执行力的zookeeper来保持他们的稳定协作。
再回到这个分布式协调框架含义的本身，似乎也是要在不同习性，不同表征的各个集群中，充当好一个动物园管理者的角色，那么这些，也都是zk存在的意义了。
