先给大家看一张图：
那么下面我再详细介绍一下：
hdfs 是一个分布式文件系统，有namenode和datanode，我们都知道，一旦namenode荡机，整个集群就会瘫痪，那么这个问题怎么处理：
一般我们都会有两个namenode，我们知道有一个secondary namenode，但是我们知道这个namenode并不能执行namenode的功能，他只是帮namenode做操作日志的合并，所以我们需要另一种部署模式，即HA部署模式
HA部署模式，是一种高可用部署模式，也就是一天24小时都在工作，他有两个namenode。namenode记录的是元数据，这个元数据放在内存中， 在磁盘上有一个镜像文件，这个镜像文件是fsimage+编号，还有大量的操作日志叫做edits+编号，两个编号都是对应起来的，而且内存里面的元数据都是齐全的，两个namenode只有一个是对客户端服务的，另外一个用来备份，对外服务的状态成为active，备份的是standby，如果有一天active namenode荡机了，standby要接管对外服务，但是它还没有元数据，那么这个问题怎么解决的。
如果active namenode荡机，standby要立马接管，意味着这两个的元数据必须要时刻同步，如果是standby namenode经常性的去active拷贝元数据信息，那么这样对active namenode的压力是很大的，所以首先，一开始格式化的时候，生成一个最初的元数据，先给standby拷贝一份，在运行的过程中，日志不仅在自己的磁盘上，还放在一个 日志存储 系统中，standby定期的去从日志存储系统中拿取日志文件，并且和最初的元数据fsimage进行合并，生成一个新的镜像，如果差下那么一点日志没有合并到，就在这一瞬间，active namenode荡机了，然后standby namenode会从日志存储系统拿取缺少的那一块日志，与原来的元数据进行合并，进行更新，这样状态就和active namenode的状态是一致的，这样就可以很快的接手对外服务。
日志存储系统：
这是个很重要的，这个系统是不能挂掉的，这个系统不是一个单节点，这个系统也是一个集群，里面有很多台机器，这个集群也是基数台，而且每台之间会同步日志，这样一来，日志存储系统的可用性就会很高了，数据同步的算法和zookeeper是一样的，即数据在多个节点之间同步，采用的是paxos算法，多数成立则成立，所以这个日志存储系统最多可以挂掉半数以下的机器，这个系统叫做QJournal，底层的功能依赖zookeeper集群，这两个集群在业务上没关系，只是利用zookeeper，就像hbase依赖zookeeper一样。
但是现在有一个问题，就是active namenode这台机器挂掉之后，standby namenode这台机器是怎么知道的，active namenode 可以在zookeeper上记载东西，然后standby去监听，一旦这个active namenode不见了，那么就说明挂了，这是一种方法。
官方是这么做的，提供了一个额外的程序，叫做zkfc，就是基于zookeeper实现的failover controller，故障控制器，运行在namenode机器上监控namenode的进程并且把监控信息记录在zookeeper中，standby 机器也会运行zkfc，监控自己机器上的进程，也会监听zookeeper里面的另一个zkfc写的东西，一旦发生变化，得到zookeeper的通知，就可以调用方法，将自己的状态从standby切换成active状态，然后开始对外服务，但是问题没有那么简单，有时候JVM会冻结这个namenode，zkfc以为namenode挂掉了，其实只是清理以及维护，但是这样的话，zkfc将将状态提交给zookeeper，然后standby namenode会收到zookeeper的通知，那就切换状态了，这就完了，就将存在两个active namenode，这样系统会错乱。
这里还有一个机制，就是当standby namenode收到通知切换状态的时候，先不着急切换，而是先采取措施确保防止这种系统的紊乱，首先会做两件事。
1.通过SSH远程指令，杀掉active namenode 的进程，但是如果不仅仅是namenode挂了，而是整个机器挂了，那发送的指令
就不会有反应，也不会有反馈信息，
2.那么如果SSH没有响应，则帮用户调用一个用户所指定的脚本，脚本运行成功，则切换状态
做完这两件事，状态就切换成功了，这就是HA高可用集群运行机制。
希望我讲清楚了......