1、zookeeper　

　　①背景：
　　　　Zookeeper 最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，
　　　　但是这些系统往往都存在分布式单点问题。所以，
　　　　雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。

　　①定义：Zookeeper是一个开源的分布式协调框架（主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源）

　　③角色：

　　　　1）领导者（Leader） ： 处理所有请求，为客户的提供读和写服务
　　　　2）跟随者（Follower） ： 只提供读服务，有机会通过选举成为leader
　　　　3）观察者（Observer）： 只提供读服务 ，不参与投票，没机会成为leader

　　　　注：由角色可以看出，即便是你对Follower进行写操作，但是它不会写，而是会将请求转发给leader，待leader写成功之后，再同步给其余角色。

　　④特点：

　　　　1） Zookeeper的集群中必须保证半数以上的节点存活才能对外提供服务器
　　　　2) Zookeeper在更新数据的时候存在一个特性：原子性 （数据要么所有角色全部更新成功，要么全部失败）

　　⑤Master选举：

　　　　解决问题：单点故障（几个节点向Zookeeper进行注册，Zookeeper通过选举，得出领导者，如果领导者出现故障，重新选举）

　　　　选举规则：集群（5个）启动时，当启动到第3个时（过半数），找到这三个节点的myid,id最大的那个就是领导者，其余启动的都是跟随者。

　　　　第二次选举规则：第二次选举的时候由于已经存在了数据，则根据节点中数据版本最新的为主。

2、HA

　　1、QJM

　　　　Qurom Journal Manager：解决单点故障问题，即引入双NameNode架构，同时借助共享存储系统来进行元数据的同步。

　　　　RPC: 远程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

　　　　Qurom ：Zookeeper分布式协调服务。

　　　　Journal Node：存储编辑日志，多个Journal Node通过Zookeeper实现共享存储系统。

　　　　Standby NameNode：备份状态的NN

　　　　Active NameNode: 启动状态的NN

　　　　ZKFC(单独进程，每个NN都有)：

　　　　　　a.监控NN的健康状态
　　　　　　b.向ZK定期发送心跳，使自己可以被选举,当自己被ZK选为主时，active FailoverController通过RPC调用使相应的NN转换为active
　　　　　　c.自动备援

　　2、架构原理：

　　　　先找到三个节点（Journal Node），然后通过Zookeeper的Qurom（分布式协调服务），实现Journal Node上存储的编辑日志同步。
　　　　以上就是一个共享存储系统，而名称集群就是共享存储系统所覆盖的几个节点，每个NN都有一个ZKFC，用以解决单点故障。

　　　　运行过程：

　　　　　　①client向Active NN提交操作，先向Active NN中的编辑日志中写。
　　　　　　②如果成功，Active NN会修改元数据，并且Active NN向所有Journal Node请求写编辑日志，只要将请求发给了其中任意一台机器，则表示成功。 （由角色的定义可以看出）

　　　　　　③Standby NameNode 会一直监控JournalNode节点上的编辑日志，当发现编辑日志有所改变后会读取这些编辑日志并合并到自己的namespace中。
　　　　　　④为了尽量减少故障切换所消耗的时间，DataNode会定时向所有NameNode节点发送块的位置信息和心跳

　　　　注：外部访问hdfs变成了名称集群（此处命名MyNNS）

　　　　注：Journal Node + Qurom <==> 共享存储系统