前面在讲HDFS和HBase架构分析的时候就提到了Zookeeper。在分布式系统里的多台服务器要对数据状态达成一致，其实是一件很有难度和挑战的事情，因为服务器集群环境的软硬件故障随时会发生，多台服务器对一个数据的记录保持一致，需要一些技巧和设计。

今天要讨论的是分布式系统一致性与Zookeeper的架构

通过之前的文章大家应该已经了解了HDFS为了保证整个集群的高可用，需要部署两台NameNode服务器，一台作为主服务器，一台作为从服务器。当主服务器宕机时就切换到从服务器上访问。但是如果不同的应用程序或者DataNode做出的关于主服务器是否可用的判断不同，那么就会导致HDFS集群混乱。

比如两个应用程序都需要对一个文件路径进行写操作，但是如果两个应用程序对于哪台是主服务器的判断不同，就会分别连接到两个不同的NameNode上，这样就会导致文件数据冲突，同一个文件指向了两份不同的数据。

这种情况叫做脑裂，为了防止脑裂产生的根本，需要单独一个专门进行判断的服务器当裁判，让裁判决定哪个服务器是主服务器。。。

但是这个做出判断决策的服务器也有可能出现故障不可访问，同样整个服务器集群也不能正常运行。所以这个判断决策的服务器必须由多台服务器组成，来保证高可用，任意一台服务器宕机都不会影响系统的可用性。

那么问题又来了，这几台做出判断决策的服务器如何防止脑裂？

这个时候比较常用的多台服务器状态一致性的解决方案是Zookeeper。

Paxos算法与Zookeeper架构

比如一个提供锁服务的分布式系统，由多台服务器构成一个集群对外提供锁服务，应用程序连接到任意一台服务器都可以获取或者释放锁，因此这些服务器必须严格保持状态一致，不能一台服务器将锁资源交给一个应用程序而另一台服务器将锁资源交给另一个应用程序，所以像这种分布式系统对数据一致性有更高的要求。

Paxos算法就是用来解决这类问题，多台服务器通过内部投票表决机制决定一个数据的更新与写入。

应用程序连接到任意一台服务器后提起状态修改请求(也可以是获得某个状态所的请求)，从图上看也就是服务器1，会将这个请求发送给集群中其他服务器进行表决。如果某个服务器同时收到了另一个应用程序同样的修改请求，它可能会拒绝服务器1的表决，并且自己也发起一个同样的表决请求，那么其他服务器就会根据时间戳和服务器排序进行表决。

表决结果会发给其他所有服务器，发起表决的服务器会根据收到的表决结果决定请求是否可以执行，从而在收到请求的时候就保证了数据的一致性。

Paxos算法比较复杂，为了简化实现，Zookeeper使用了一种叫ZAB（ZooKeeper Atomic
Broadcast，ZooKeeper原子消息广播协议）的算法协议。基于ZAB算法，Zookeeper集群保证数据更新的一致性，并且通过集群方式保证了Zookeeper系统高可用。但是Zookeeper系统中所有服务器都存储相同的数据，也就是数据没有分片存储，因此不满足分区耐受性。

Zookeeper通过一种树状结构记录数据，如下图：

应用程序可以通过路径的方式访问Zookeeper中的数据，比如/services/YaView/services/stupidname这样的路径方式修改、读取数据。Zookeeper还支持监听模式，当数据发生改变的时候，通知应用程序。

因为大数据系统通常是主从架构，主服务器管理集群的状态和元信息，为了保证集群状态不发生脑裂，所以运行期只能有一个主服务器工作，举HDFS的例子来说，也就是一个Active状态的Namenode，但是为了保证高可用，所以还需要一个Standby状态的Namenode。

那么问题就来了，其他服务器集群怎么知道哪个是active namenode，哪个是standby namenode？

所以很多大数据系统都依赖Zookeeper提供的一致性数据服务，用于选举集群当前工作的主服
务器。一台主服务器启动后向Zookeeper注册自己为当前工作的主服务器，因此另一台服务器
就只能注册为热备主服务器，应用程序运行期都和当前工作的主服务器通信。

因为Zookeeper系统的多台服务器存储相同的数据并且每次数据更新都要所有服务器投票表决， 所以和一般的分布式系统相反，Zookeeper集群的性能会随着服务器数量的增加而下降。

Zookeeper通过Paxos选举算法实现数据强一致性，并为各种大数据系统提高主服务器选举服务。虽然Zookeeper并没有什么特别强大的功能，但是在各类分布式系统和大数据系统中，Zookeeper出镜率非常高，因此也是很多系统的基础设施。