Zookeeper是干嘛的呢？
ZooKeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。 ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。
基本架构：
客户端：可以理解成集群成中每一个节点。
服务器：为客户端提供所有的服务，向客户端发送确认码以告知服务器是活跃的。
Ensemble：Zookeeper服务器组，形成Ensemble最少需要3个节点。
Leader：服务器节点，如果任何连接的节点失败，则执行自动恢复。Leader在服务器启动时被选举。
Follower：跟随leader指令的服务器节点。
Zookeeper节点称为znode，每个znode由一个名称标识。
Znode类型：
Znode被分为持久节点persistent，顺序节点sequential和临时节点ephemeral。
Session会话：
会话对于ZooKeeper的操作非常重要。会话中的请求按FIFO顺序执行。一旦客户端连接到服务器，将建立会话并向客户端分配会话ID 。
Watches监视：
监视是一种简单的机制，使客户端收到关于ZooKeeper集合中的更改的通知。客户端可以在读取特定znode时设置Watches。Watches会向注册的客户端发送任何znode（客户端注册表）更改的通知。
Zookeeper工作流：
启动时，客户端将连接到zookeeper中集合中的一个节点，主从节点均可。连接后发送分配的会话ID并向该客户端发送确认，一旦连接到节点，客户端将发送心跳确保连接不会丢失。
ZooKeeper集合中的节点：
-
如果我们有单个节点，则当该节点故障时，ZooKeeper集合将故障。它有助于“单点故障"，不建议在生产环境中使用。
-
如果我们有两个节点而一个节点故障，我们没有占多数，因为两个中的一个不是多数。
-
如果我们有三个节点而一个节点故障，那么我们有大多数，因此，这是最低要求。ZooKeeper集合在实际生产环境中必须至少有三个节点。
-
如果我们有四个节点而两个节点故障，它将再次故障。类似于有三个节点，额外节点不用于任何目的，因此，最好添加奇数的节点，例如3，5，7。
写入过程比ZooKeeper集合中的读取过程要贵，因为所有节点都需要在数据库中写入相同的数据。因此，对于平衡的环境拥有较少数量（例如3，5，7）的节点比拥有大量的节点要好。
组件：
写入wirte：写入过程由leader节点处理。
读取read：读取由特定连接的znode在内部执行，因此不需要与集群进行交互。
复制数据库（replicated database）：用于在zookeeper中存储数据
Leader：负责处理写入请求的Znode
Follower：follower从客户端接收写入请求，并将它们转发到leader znode。
请求处理器（request processor）：只存在于leader节点。它管理来自follower节点的写入请求。
原子广播（atomic broadcasts）：负责广播从leader节点到follower节点的变化。