https://mirror.bit.edu.cn/apache/zookeeper/
https://www.cnblogs.com/sakura-yxf/p/12020348.html
1 Zookeeper集群的角色：Leader和follower（Observer）
只要集群中有半数以上节点存活，集群就能提供服务
- 状态（Looking)：选举状态，包括 Leader，Follower，Observer
Looking：寻找Leader，当服务器出现这个状态时，它会认为当前集群没有Leader，因此需要进入选举
Leader：为客户端提供读和写服务
follower：能提供读服务，不能提供写服务
Observer：能提供读服务，不能提供写服务；不参与 Leader 选举过程，也不参与写操作的"过半写成功"策略，因此 Observer 可以在不影响写性能的情况下提升集群的读性能。
zookeeper 选举
zookeeper 的选举过程分为两个阶段：
数据恢复阶段：每台服务器在启动前，都会从本地目录找自己所拥有的 Zxid（最大事务id），每一次对 Zookeeper 的操作都是一个事务，每次事务都会递增事务 id，事务 id 越大，则事务越新。
选举阶段：zookeeper 集群开始选举时，每个节点都会提交一个选举协议，协议中包括如下内容：
- 当前节点的 Zxid
- 选举 id（myid 文件中的值）
- 逻辑时钟值（和选举轮数有关），作用是确保每台 zk 服务器处于同一轮选举中
- 状态（Looking)：选举状态，包括 Leader，Follower，Observer
在选举过程中，会遵循如下原则：
首先比较 Zxid，哪个节点的 Zxid 最大就选择谁作为 leader
在所有节点的 Zxid 全都一致的情况下，则比较选举 id，选举 id 较大的节点会作为 leader
由于zookeeper只允许 myid 大的节点连接到 myid 小的节点，所以启动 zookeeper 的顺序应该按照 myid 从小到大启动，最后再启动leader节点。
2. zookeeper集群机制
半数机制：集群中半数以上机器存活，集群可用。 zookeeper适合装在奇数台机器上
Zookeeper是一个为分布式应用提供分布式、开源的调度服务。它暴露一组简单的基本架构，分布式应用可以在其上面来实现高层次服务用于同步、维护配置、分组和命名。它被设计得容易编程，在相似的文件系统树结构目录下使用一个数据模型。它运行在java环境上和绑定Java和C。
ZooKeeper允许分布式进程通过一个共享的跟标准文件系统相似的架构的层级命名空间来互相调度。命名空间包含称为znodes的数据寄存器（在ZooKeeper的说法中），这些类似于文件和目录。不像传统的文件系统被设计用于存储，ZooKeeper数据是保存在内存中，那就意味着ZooKeeper能够获得高吞吐量和低延迟。
ZooKeeper实现高性能、高可能性和严格的访问命令。性能方面意味着它可以用在大型分布式系统。可靠性方面使它避免了单点故障。严格的访问命令意味着复杂的同步原语可以在客户端实现。
https://www.cnblogs.com/ultranms/p/9585191.html
在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。
配置管理
在我们的应用中除了代码外，还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式，在代码中引入这些配置文件。但是当我们只有一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，而且还可能是动态的话使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。比如我们可以把配置放在数据库里，然后所有需要配置的服务都去这个数据库读取配置。但是，因为很多服务的正常运行都非常依赖这个配置，所以需要这个集中提供配置服务的服务具备很高的可靠性。一般我们可以用一个集群来提供这个配置服务，但是用集群提升可靠性，那如何保证配置在集群中的一致性呢？ 这个时候就需要使用一种实现了一致性协议的服务了。Zookeeper就是这种服务，它使用Zab这种一致性协议来提供一致性。现在有很多开源项目使用Zookeeper来维护配置，比如在HBase中，客户端就是连接一个Zookeeper，获得必要的HBase集群的配置信息，然后才可以进一步操作。还有在开源的消息队列Kafka中，也使用Zookeeper来维护broker的信息。在Alibaba开源的SOA框架Dubbo中也广泛的使用Zookeeper管理一些配置来实现服务治理。
名字服务
名字服务这个就很好理解了。比如为了通过网络访问一个系统，我们得知道对方的IP地址，但是IP地址对人非常不友好，这个时候我们就需要使用域名来访问。但是计算机是不能是别域名的。怎么办呢？如果我们每台机器里都备有一份域名到IP地址的映射，这个倒是能解决一部分问题，但是如果域名对应的IP发生变化了又该怎么办呢？于是我们有了DNS这个东西。我们只需要访问一个大家熟知的(known)的点，它就会告诉你这个域名对应的IP是什么。在我们的应用中也会存在很多这类问题，特别是在我们的服务特别多的时候，如果我们在本地保存服务的地址的时候将非常不方便，但是如果我们只需要访问一个大家都熟知的访问点，这里提供统一的入口，那么维护起来将方便得多了。
分布式锁
其实在第一篇文章中已经介绍了Zookeeper是一个分布式协调服务。这样我们就可以利用Zookeeper来协调多个分布式进程之间的活动。比如在一个分布式环境中，为了提高可靠性，我们的集群的每台服务器上都部署着同样的服务。但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要协调，编程起来将非常复杂。而如果我们只让一个服务进行操作，那又存在单点。通常还有一种做法就是使用分布式锁，在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。比如HBase的Master就是采用这种机制。但要注意的是分布式锁跟同一个进程的锁还是有区别的，所以使用的时候要比同一个进程里的锁更谨慎的使用。
集群管理
在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中其他机器需要感知到这种变化，然后根据这种变化做出对应的决策。比如我们是一个分布式存储系统，有一个中央控制节点负责存储的分配，当有新的存储进来的时候我们要根据现在集群目前的状态来分配存储节点。这个时候我们就需要动态感知到集群目前的状态。还有，比如一个分布式的SOA架构中，服务是一个集群提供的，当消费者访问某个服务时，就需要采用某种机制发现现在有哪些节点可以提供该服务(这也称之为服务发现，比如Alibaba开源的SOA框架Dubbo就采用了Zookeeper作为服务发现的底层机制)。还有开源的Kafka队列就采用了Zookeeper作为Cosnumer的上下线管理。