第三阶段：离线场景下的数据存储与计算 3.1 zookeeper详解

应用程序的高可用

“高可用性”（High Availability简称HA）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

举例来说：为了保证学校门口的安保问题，需要许多保安轮流值岗，这样万一有哪个保安因为身体原因无法值岗的话还可以有其他人顶上，这样就可以保证整个学校门口的安保的高度可用。

应用程序高可用的类型

主从方式（也称之为主从冷备）

还是学校门口的安保问题，可以让一个保安长期看门，另一个保安做一些其他的事情（比如一些学校的其他杂事儿）或者闲着（但是要跟长期看门的那个保安保持沟通，以了解门口安保的基本情况），等长期看门的保安由于种种原因无法看门时（可能是长期也可能是短期），就让另一个顶上就好了。

对应到应用程序中，就是如下的方式了：

准备有两个相同的应用程序，一个对外提供服务，称之为主程序，另一个平时不运行（主要负责跟对外提供服务的机器进行数据同步等）称之为从程序或备程序，即从程序是主程序的一个备份，等出问题的时候再顶上。常见的例子，mysql的主从复制。

双主互备（也称之为双主热备或互为热备）

还是学校门口的安保问题，可以让两个保安来同时看门，例如签到进门等工作一人负责一半，就算一个保安临时出现点问题还有另一个保安可以支撑校门口的安保工作（会造成的问题就是剩下的这个保安的工作量会翻倍）。

对应到应用程序中，就是如下的方式了：

准备两个相同的应用程序，同时对外提供服务（这时两个主程序相互作为对方的备份，故称之为双主热备），当其中一个出现问题时，另一个也可以照常对外提供服务（会造成的问题是单个应用程序的效率肯定不如两个程序一起来的效率高）。常见的例子：双tomcat或双nginx。

集群多互备

跟双主互备类似，只不过对外提供服务的程序的数量较多而已。

Hadoop的master角色的单点故障问题

Hadood中的NameNode和ResourcManager是集群中的重要角色，如果这两个角色出现问题将导致整个集群无法使用。所以保证这两个角色的高可用是保证整个hadoop分布式系统高可用的关键。

 

为了保证其高可用，可以想到的一个办法是使用主从冷备或双主热备。但是为了在这两个角色出问题时尽快知晓并解决，还需要使用一个额外的应用程序监控这个两个角色的健康状况，当这两个角色出问题时，自动使用相应的解决方案，以减少系统停用时间，保证hadoop 的高可用。

 

正如上面所说的，这种协助分布式应用程序更好的提供服务的程序，我们称之为分布式协调程序。

 

因为分布式协调程序的重要性，所以其自身必须要保证高可用，才能保证被其协调的分布式应用程序的高可用。

 

目前市面上最流行的（也是唯一的企业级的）分布式协调应用程序就是zookeeper。需要注意的是：上述只是zookeeper能解决的问题之一，zookeeper还能解决很多其他的应用场景。

Zookeeper的官方定义

Welcome to Apache ZooKeeper™

欢迎来到Apache Zookeeper的世界。

 

Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination.

Apache ZooKeeper是一个努力开发和维护的，可以保证可靠的分布式的开源式服务。

 

What is ZooKeeper?

Zookeeper是什么？

 

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them ,which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

 

Zookeeper 分布式一致性协调服务（工具）

 

zookeeper是一个集中的服务，用以维护配置信息,命名,提供分布式同步,提供集团服务。所有这些类型的服务都使用某种形式的分布式应用程序。每次实现它们有很多工作,进入修复bug和竞争条件,是不可避免的。因为难以实现这些服务的应用程序最初通常通过他们,使他们脆弱的变化和难以管理。即使做得对,不同的实现这些服务的应用程序部署时导致管理的复杂性。

 

通俗的来说，ZooKeeper 顾名思义 动物园管理员，他是拿来管大象(Hadoop) 、 蜜蜂(Hive) 、 小猪(Pig)  的管理员， Apache Hbase和 Apache Solr 以及LinkedIn sensei  等项目中都采用到了 Zookeeper。ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，ZooKeeper是以Fast Paxos协议为基础，实现同步服务，配置维护和命名服务等分布式应用。 ZooKeeper 意欲设计一个易于编程的环境，它的文件系统使用我们所熟悉的目录树结构。 ZooKeeper 使用 Java 所编写，但是支持 Java 和 C 两种编程语言。

众所周知，协调服务非常容易出错，但是却很难恢复正常，例如，协调服务很容易处于竞态以至于出现死锁。设计 ZooKeeper 的目的是为了减轻分布式应用程序所承担的协调任务。

 

Zookeeper是怎样保证自身的高可用的？

首先可以想到的是，假如zookeeper只有一个的话，其也无法保证其自身的高可用，所以zookeeper本身也是以集群的形式存在的。对比学校大门的安保问题，我们很容易能都想到的一种方法是可以有多个zookeeper，在某一时刻由一个主要的zookeeper对外提供服务，当其出现问题时，从剩下的多个zookeeper中快速选出来一个继续对外提供服务就可以了。Zookeeper本身就是基于这种思想来设计的。

 

Zookeeper采用了一个称之为ZAB的协议来保证自身的高可用。其来源于Paxos选举协议，其也是一个用来保证分布式一致的一个经典协议。在历史上，Paxos协议是从二阶段提交协议演变到三阶段提交协议之后再演变成的。

 

在分布式系统中，每一个机器节点虽然都能够明确的知道自己在进行事务操作过程中的结果是成功或失败，但是无法直接获取到其他分布式节点的操作结果（需要通过网络进行结果传输）。因此，当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID（原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability））特性，就需要引入一个称之为“协调者（Coordinator）”的组件来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点则被称为“参与者”（Participant）。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正提交。基于这个思想，衍生出了二阶段提交和三阶段提交两种协议两种一致性算法。

生活中大部分工作的形式都是分布式的，比如我们将来最常见的工作情景：项目经理将一个大项目分成了前后台（或者更多的部分），指派给不同的员工，每个人只负责自己的事情，所有干活的员工就是参与者的角色，项目经理就是协调者的角色。

二阶段提交算法

二阶段提交协议简称2PC，即Two-Phase Commit的缩写。

顾名思义，二阶段协议一共分为两个阶段。

如下图所示：

 

阶段一：提交事务请求

协调者向所有参与者询问，是否可以执行事务操作？

如果所有参与者的回答都是可以，那么就进入下一个阶段，真正执行事务提交执行。

注意：如果这个阶段有参与者没有回答，则将一直等待其回答，或者依赖协调者自身的超时机制进行事务中断。

阶段二：执行事务提交

将事务提交执行，各个参与者负责自己的部分，最终都将自己的执行结果反馈给协调者。

注意：如果所有参与者都正确回答，在协调者向所有参与者分配其要提交的任务时网络出现问题，将会造成只有一部分接收到协调者信息的参与者执行自身所负责的那部分事务。这样就会导致整个分布式系统出现数据不一致的情况。俗称脑裂。

生活中常见的例子

辅导员经过课间休息继续给大家讲课，

阶段一：

首先辅导员（协调者）问大家都休息好了吗？（询问所有参与者），大家都回答休息好了

阶段二：

辅导员带领大家一起上课，所有的学生（参与者）一起完成上课这件事。

三阶段提交协议

 

三阶段提交协议对二阶段提交协议进行了改进，将分布式事务操作拆分为了三个阶段。

 

阶段一：询问是否可以执行事务

这个阶段协调者向所有的参与者询问是否可以参加执行事务。参与者接收到来自协调者的请求后如果自身可以执行，就进入准备状态。

阶段二：准备提交事务

如果阶段一中所有参与者回答的结果都是正常的，就执行事务的预提交。

注意：如果有任何一个参与者向协调者反馈的是非正常的，或者在等待超时之后协调者无法接收到所有参与者的反馈响应，那么就会中断事务。

阶段三：执行事务

真正进行事务提交。

注意：如果此时协调者出现问题或者协调者和参与者之间的网络出现问题，参与者都会在等待超时之后，继续进行事务提交。这种情况必然会导致分布式数据的不一致性。

 

Zookeeper的ZAB协议和Paxos协议

二阶段提交和三阶段提交协议和Paxos协议都是分布式应用程序的通用协议，即在大部分的分布式应用程序中都可以使用。ZAB（zookeeper Atomic Broadcast）zookeeper原子消息广播协议）协议是zookeeper设计之初专门为雅虎内部那些高吞吐量、低延迟、健壮、简单的分布式场景设计的。所以ZAB不是一种通用型算法，而是一种特别为zookeeper设计的崩溃可恢复的原子消息广播算法。ZAB算法可是看成是paxos协议的一种具体实现，理解Paxos协议较为困难，我们不做掌握。

Zookeeper中将自己的角色系统设置主要为Leader、Flower、OBServer。Leader和Flower都是zk的server，只不过由Leader（只会存在一个，类似于Hadoop的NameNode）对外提供服务，众多Flower（类似于secondary namenode，不过Flow会有多个）随时准备等Leader出现问题时选举出一个新leader来继续对外提供以保证zk服务的高可用。

Zookeeper集群中的机器数量设置</