安全模式 #
安全模式是Namenode的一种状态，处于安全模式中的Namenode不接受任何对于
命名空间的修改操作，同时也不触发任何复制和删除数据块的操作
HDFS High Availability #
HDFS的高可用（High Availability,HA）方案就是为了解决上述问题而产生的，在HA HDFS集群中会同时运行两个Namenode,一个作为活动的（Active）Namenode,一个作为备 份的（Standby）Namenode。备份Namenode的命名空间与活动Namenode是实时同步的，所 以当活动Namenode发生故障而停止服务时，备份Namenode可以立即切换为活动状态，而不 影响HDFS集群的服务。
配置 #
Quorum Journal #
HDFS Namenode高可用性支持，但是所有的HA实现
方案都依赖于一个保存editlog的共享存储。这个共享存储必须是高可用的，并且能够被集群
中的所有Namenode 同时访问。
在Quorum Journal模式之前，HDFS中使用最多的共享存储方案是NAS+NFS。但是这种
方案有个缺点，就是为了预防脑裂的情况，它要求有一个互斥脚本在Namenode发生故障切
换时关闭上一个活动节点，或者阻止上一个活动节点访问共享存储。为了解决这个问题，
cloudera提供了Quorum Journal设计方案，这是一个基于Paxos算法实现的HA方案
Quorum Journal实现的HA方案的优点
- JN进程可以运行在普通的PC上，而无须配置专业的共享存储硬件。
- 不需要实现单独的fencing机制，Quorum Journal模式中内置了fencing功能。
- Quorum Journal不存在单点故障，集群中有
2N+1个JournalNode,可以允许有N个JournalNode死亡。- JN不会因为其中一台机器的延迟而影响整体的延迟，而且也不会因为JN数量的增多而影响性能（因为Namenode向JournalNode发送日志是并行的）。
QuorumJournalManager 源码 #
类 接口 #
初始化 #
写入日志 #
互斥机制 #
当HA集群发生Namenode异常切换时，需要在共享存储上fencing上一个活动节点以保 证该节点不能再向共享存储写入editlog。基于Quorum Journal模式的HA 提供了epoch number 来解决互斥（fencing）问题，这个概念在很多分布式文献中都能找到（例如Paxos、ZAB等）。 epoch number具有如下一些性质。
- 当一个Namenode变为活动状态时，会分配给它一个epoch number。
- 每个epoch number都是唯一的，没有任意两个Namenode有相同的epoch number。
- epoch number定义了Namenode写editlog文件的顺序。对于任意两个Namenode,拥有更大epoch number的Namenode被认为是活动节点
写流程 #
- 将editlog输出流中缓存的数据写入JN，对于集群中的每一个JN都存在一个独立的线程调用RPC接口QJournalProtocol.journal()向JN写入数据。
- 当JN收到QJournalProtocol.journal()请求后，JN 会执行如下操作：
①验证 epochnumber是否正确；
②确认写入数据对应的txid是否连续；
③将数据持久化到JN的本地磁盘；
④向QJM发送正确的响应。 - QJM等待集群JN的响应，如果多数JN返回成功，则写操作成功；否则写操作失败，QJM会抛出异常。