1. What is Zookeeper
It is to be defined in one sentence: It is a high throughput of the distributed coordination system . We can know Zookeeper have at least the following characteristics:
- 1.Zookeeper's main role is to provide coordination services for distributed systems , including but not limited to: Distributed Lock, unified naming service, configuration management, load balancing, the master server from the elections and the main switching.
- 2.Zookeeper itself usually exist in a distributed form . Zookeeper a service usually consists of multiple server nodes, as long as more than half of the surviving node, you can normally provide services Zookeeper, Zookeeper it also implies high availability characteristics. The client may be connected via the TCP protocol to a server in any cluster node requests Zookeeper services, and how to communicate within the cluster and how to maintain the consistency of distributed data and other details of the client transparent. As shown below
- 3.Zookeeper is designed for high-throughput target, and therefore has a very good performance in the case of reading and writing less.
Zookeeper main reason for having a high throughput characteristics are the following :
1.Zookeeper cluster any server node can direct the client in response to a read request (write request is not the same as these, the following will discuss in detail), and can be laterally extended by adding node. This is the main reason for high throughput
2.Zookeeper the full amount of data stored in memory , read data from memory is not required disk IO, much faster.
3.Zookeeper relaxed strong consistency requirements of distributed data, that does not guarantee real-time data consistency, allow the distributed data through a window of time to reach a final agreement , which has to raise its throughput to some extent.
Written request, or that the transaction request, because it will affect the throughput to be synchronized, to a certain extent between different server nodes on the state. Zookeeper therefore simply increasing the number of server nodes to enhance its throughput does not necessarily have a positive effect. Server node, is advantageous to improve the throughput of a read request, the server node will extend the time synchronization data, as the case may have to strike a balance between the two.
2. Zookeeper role cluster
In Zookeeper cluster, respectively, Leader, Follower and Observer are three types of server roles.
-
Leader
Leader server during normal operation of the entire one and only one cluster will be elected Leader server by way of elections, scheduled by processing it with a unified cluster transactional requests, and each server in the cluster. - Follower
main responsibilities Follower are the following:- 1. Participation in elections Leader
- 2. Proposal of transaction requests to vote
- 3. handle customer requests (read), and forwards the transaction request (write) to the non-transactional Leader server.
-
The Observer
the Observer is a weaker version of Follower. Follower able to handle the same as its non-transaction is a read request, and forwards the request to the Leader transaction server, but it does not participate in the vote of any kind, whether voting or elections Leader of transaction requests Proposal. The introduction of this role is mainly to enhance the throughput of non-transaction processing cluster in the cluster without affecting the transaction processing capabilities.
How 5. Zookeeper distributed to ensure data consistency --ZAB agreement
Zookeeper using ZAB (Zookeeper Atomic Broadcast) protocol to ensure distributed data consistency. ZAB is not a general-purpose distributed consensus algorithm, but an atomic message broadcasting algorithm designed specifically for the collapse Zookeeper designed recoverable. ZAB protocol includes two basic modes: crash recovery mode and broadcast mode messages. Crash recovery mode is mainly used in the cluster startup process, the server crashes or Leader withdraw a new Leader of the election server and data synchronization; news broadcast mode is mainly used for processing the transaction request. Here to introduce these two aspects
5.1 transaction request processing flow
ZAB core protocol is the definition of the handling of the transaction request, the whole process can be summarized as follows:
- 1. All transaction requests are referred Leader server clusters to handle, Leader server will convert a transaction request to a Proposal (the proposal), and generates a unique ID for a global incremental, this transaction ID is ID, namely ZXID , Leader server Proposal is their ZXID the order to sort and process.
- 2. After the server sends Leader Follower Proposal placed into each corresponding queue (Leader will assign a separate queue for each Follower), and sent to a FIFO manner Follower server.
- After the server receives 3.Follower Proposal transaction, the transaction log is first written to the local disk of the embodiment, and the server returns an ACK response Leader after successful.
- 4.Leader received more than half as long as the server Follower of ACK response, it will broadcast a message to the Follower Commit to notify submit Proposal, while Leader itself will complete the submission of the Proposal.
The whole process as shown in FIG.
5.2 Leader Election Process Server
When the Leader server does not exist in the cluster cluster will conduct elections Leader server, which is usually present in the two cases: 1. When the cluster 2. Cluster has just started running, but for some reason the server Leader exit. Cluster server will send all other Follower server message, the message can be visualized called ballot, the ballot consists of two main information composed of the elected ID Leader server (that is configured in digital myid file) and the server's transaction ID, transaction indicates the operation to change the state of the server, the server ID of a larger transaction, the more it new data. The entire process is as follows:
- 1.Follower server to cast ballots (SID, ZXID), for the first time each Follower will elect themselves as Leader server, which means that each Follower first votes are cast out of their server ID and transaction ID.
- 2. Each Follower will receive votes from other Follower, it will regenerate a ballot based on the following rules: Comparison of votes received and their size ZXID, and select one of the greatest; if you select the SID that is the same as ZXID server ID largest. Each server will eventually regenerate a ballot, and cast out the ballot.
After so many rounds of voting, if one of the servers got more than half of the votes, it will present selected as Leader. From the above analysis, Zookeeper cluster has a biased selection of Leader server, biased in favor of those more ZXID, ie, data updated machine.
The whole process as shown in FIG.
6. Zookeeper how fault tolerant server failure
Zookeeper by the transaction log and data snapshots to avoid the data loss caused by server failure.
- The transaction log refers to the first server to the transaction log of operations written to disk before updating memory data, Leader and Follower server records the transaction log.
- Periodic data snapshot is traversed by the depth of the tree structure data memory mode is transferred to the external memory snapshot. But note that this snapshot is a "fuzzy" because the memory data may have changed when making snapshot. But because the transaction itself Zookeeper operations carried out idempotency guarantee, so after the snapshot data is loaded into memory will be restored to the latest state by way of execution of the transaction log terms.
在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。那这些服务又到底是什么呢？我们为什么需要这样的服务？我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统中使用了。
配置管理
在我们的应用中除了代码外，还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式，在代码中引入这些配置文件。但是当我们只有一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，而且还可能是动态的话使用配置文件就不是个好主意了。这个时候往往需要一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。比如我们可以把配置放在数据库里，然后所有需要配置的服务都去这个数据库读取配置。但是，因为很多服务的正常运行都非常依赖这个配置，所以需要这个集中提供配置服务的服务具备很高的可靠性。一般我们可以用一个集群来提供这个配置服务，但是用集群提升可靠性，那如何保证配置在集群中的一致性呢？ 这个时候就需要使用一种实现了一致性协议的服务了。Zookeeper就是这种服务，它使用Zab这种一致性协议来提供一致性。现在有很多开源项目使用Zookeeper来维护配置，比如在HBase中，客户端就是连接一个Zookeeper，获得必要的HBase集群的配置信息，然后才可以进一步操作。还有在开源的消息队列Kafka中，也使用Zookeeper来维护broker的信息。在Alibaba开源的SOA框架Dubbo中也广泛的使用Zookeeper管理一些配置来实现服务治理。
假设我们的程序是分布式部署在多台机器上，如果我们要改变程序的配置文件，需要逐台机器去修改，非常麻烦，现在把这些配置全部放到zookeeper上去，保存在 zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 zookeeper 的通知，然后从 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的上下线管理。
自己的一些理解：
Leader可以接受client请求，也接收其他Server转发的写请求，负责更新系统状态。 Follower也可以接收client请求，如果是写请求将转发给Leader来更新系统状态，读请求则由Follower的内存数据库直接响应。
事物操作
在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求，ZooKeeper都会为其分配一个全局唯一的事务ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID对应一次更新操作，从这些 ZXID 中可以间接地识别出 ZooKeeper 处理这些事务操作请求的
全局顺序。
Watcher(事件监听器)
ZooKeeper 中一个很重要的特性。ZooKeeper允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去。该机制是 ZooKeeper 实现分布式协调服务的重要特性。
ZooKeeper数据模型的结构整体上可以看作是一棵树，每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识在每个ZNode上可存储少量数据(默认是1M, 可以通过配置修改, 通常不建议在ZNode上存储大量的数据)
ZooKeeper支持一种Watch操作，Client可以在某个ZNode上设置一个Watcher，来Watch该ZNode上的变化。如果该ZNode上有相应的变化，就会触发这个Watcher，把相应的事件通知给设置Watcher的Client。需要注意的是，ZooKeeper中的Watcher是一次性的，即触发一次就会被取消，如果想继续Watch的话，需要客户端重新设置Watcher
节点状态
每个集群中的节点都有一个状态 LOOKING, FOLLOWING, LEADING, OBSERVING。都属于这4种，每个节点启动的时候都是LOOKING状态，如果这个节点参与选举但最后不是leader，则状态是FOLLOWING，如果不参与选举则是OBSERVING，leader的状态是LEADING。
关于ZooKeeper集群服务器数
ZooKeeper 官方确实给出了关于奇数的建议，但绝大部分 ZooKeeper 用户对于这个建议认识有偏差。一个 ZooKeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。基于这个特性，如果想搭建一个能够允许 N 台机器 down 掉的集群，那么就要部署一个由 2*N+1 台服务器构成的 ZooKeeper 集群。因此，一个由 3 台机器构成的 ZooKeeper 集群，能够在挂掉 1 台机器后依然正常工作，而对于一个由 5 台服务器构成的 ZooKeeper 集群，能够对 2 台机器挂掉的情况进行容灾。注意，如果是一个由6台服务器构成的 ZooKeeper 集群，同样只能够挂掉 2 台机器，因为如果挂掉 3 台，剩下的机器就无法实现过半了。
zookeeper有这样一个特性：
【集群中只要有超过过半的机器是正常工作的，那么整个集群对外就是可用的】
也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；
同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；
同理你多列举几个：2->0;3->1;4->1;5->2;6->2会发现一个规律，2n和2n-1的容忍度是一样的，
都是n-1，所以为了更加高效，何必增加那一个不必要的zookeeper呢。
ZooKeeper可伸缩性
那么，ZooKeeper为什么要引入Observer这个角色呢？其实在ZooKeeper中引入Observer，主要是为了使ZooKeeper具有更好的可伸缩性。那么，何为可伸缩性？关于伸缩性，对于不同的人意味着不同的事情。 而在这里是说，如果我们的工作负载可以通过给系统分配更多的资源来分担，那么这个系统就是可伸缩的；一个不可伸缩的系统却无法通过增加资源来提升性能，甚至会在工作负载增加时，性能会急剧下降。
在Observer出现以前，ZooKeeper的伸缩性由Follower来实现，我们可以通过添加Follower节点的数量来保证ZooKeeper服务的读性能。但是随着Follower节点数量的增加，ZooKeeper服务的写性能受到了影响。
简单来说，Zab协议规定：来自Client的所有写请求，都要转发给ZK服务中唯一的Server—Leader，由Leader根据该请求发起一个Proposal（请求）。然后，其他的Server对该Proposal（请求）进行Vote（投票）。之后，Leader对Vote（投票）进行收集，当Vote数量过半时Leader会向所有的Server发送一个通知消息。最后，当Client所连接的Server收到该消息时，会把该操作更新到内存中并对Client的写请求做出回应。
ZK 写请求工作流程图
从图中我们可以看出， ZooKeeper 服务器在上述协议中实际扮演了两个职能。它们一方面从客户端接受连接与操作请求，另一方面对操作结果进行投票。这两个职能在 ZooKeeper集群扩展的时候彼此制约。例如，当我们希望增加 ZK服务中Client数量的时候，那么我们就需要增加Server的数量，来支持这么多的客户端。然而，从Zab协议对写请求的处理过程中我们可以发现，增加服务器的数量，则增加了对协议中投票过程的压力。因为Leader节点必须等待集群中过半Server响应投票，于是节点的增加使得部分计算机运行较慢，从而拖慢整个投票过程的可能性也随之提高，写操作也会随之下降。这正是我们在实际操作中看到的问题——随着 ZooKeeper 集群变大，写操作的吞吐量会下降。
所以，我们不得不得在增加Client数量的期望和我们希望保持较好吞吐性能的期望间进行权衡。要打破这一耦合关系，我们引入了不参与投票的服务器，称为Observer。 Observer可以接受客户端的连接，并将写请求转发给Leader节点。但是，Leader节点不会要求 Observer参加投票。相反，Observer不参与投票过程，仅仅在上述第3歩那样，和其他服务节点一起得到投票结果。
zookeeper有这样一个特性：
【集群中只要有超过过半的机器是正常工作的，那么整个集群对外就是可用的】
也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；
同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；
同理你多列举几个：2->0;3->1;4->1;5->2;6->2会发现一个规律，2n和2n-1的容忍度是一样的，
都是n-1，所以为了更加高效，何必增加那一个不必要的zookeeper呢。
ZooKeeper可伸缩性
那么，ZooKeeper为什么要引入Observer这个角色呢？其实在ZooKeeper中引入Observer，主要是为了使ZooKeeper具有更好的可伸缩性。那么，何为可伸缩性？关于伸缩性，对于不同的人意味着不同的事情。 而在这里是说，如果我们的工作负载可以通过给系统分配更多的资源来分担，那么这个系统就是可伸缩的；一个不可伸缩的系统却无法通过增加资源来提升性能，甚至会在工作负载增加时，性能会急剧下降。
在Observer出现以前，ZooKeeper的伸缩性由Follower来实现，我们可以通过添加Follower节点的数量来保证ZooKeeper服务的读性能。但是随着Follower节点数量的增加，ZooKeeper服务的写性能受到了影响。
简单来说，Zab协议规定：来自Client的所有写请求，都要转发给ZK服务中唯一的Server—Leader，由Leader根据该请求发起一个Proposal（请求）。然后，其他的Server对该Proposal（请求）进行Vote（投票）。之后，Leader对Vote（投票）进行收集，当Vote数量过半时Leader会向所有的Server发送一个通知消息。最后，当Client所连接的Server收到该消息时，会把该操作更新到内存中并对Client的写请求做出回应。
ZK 写请求工作流程图
从图中我们可以看出， ZooKeeper 服务器在上述协议中实际扮演了两个职能。它们一方面从客户端接受连接与操作请求，另一方面对操作结果进行投票。这两个职能在 ZooKeeper集群扩展的时候彼此制约。例如，当我们希望增加 ZK服务中Client数量的时候，那么我们就需要增加Server的数量，来支持这么多的客户端。然而，从Zab协议对写请求的处理过程中我们可以发现，增加服务器的数量，则增加了对协议中投票过程的压力。因为Leader节点必须等待集群中过半Server响应投票，于是节点的增加使得部分计算机运行较慢，从而拖慢整个投票过程的可能性也随之提高，写操作也会随之下降。这正是我们在实际操作中看到的问题——随着 ZooKeeper 集群变大，写操作的吞吐量会下降。
所以，我们不得不得在增加Client数量的期望和我们希望保持较好吞吐性能的期望间进行权衡。要打破这一耦合关系，我们引入了不参与投票的服务器，称为Observer。 Observer可以接受客户端的连接，并将写请求转发给Leader节点。但是，Leader节点不会要求 Observer参加投票。相反，Observer不参与投票过程，仅仅在上述第3歩那样，和其他服务节点一起得到投票结果。