[ 图4.EditLog输出流程图 ]
这里有一个问题，既然EditLog是异步写的，怎么包管缓存中的数据不丢呢,其拭魅这里固然是异步,但实际所有日记都须要经由过程logSync同步成功后才会给client返回成功码，假设某一时刻NameNode弗采取了，其内存中的数据其实是未同步成功的，所以client会认为这部分数据未写成功。
第二个问题是，EditLog怎么在多个JN上保持一致的呢。下面展开介绍。
1.隔离双写：
在ANN每次同步EditLog到JN时，先要包管不会有两个NN同时向JN同步日记。这个隔离是怎么做的。这琅绫擎涉及一个很重要的概念Epoch Numbers，很多分布式体系都邑用到。Epoch有如下几个特点：
- 当NN成为晃荡结点时，其会被付与一个EpochNumber
- 每个EpochNumber是惟一的，不会有雷同的EpochNumber出现
- EpochNumber有严格次序包管，每次NN切换后其EpochNumber都邑自增1，后面生成的EpochNumber都邑大年夜于前面的EpochNumber
QJM是怎么包管膳绫擎特点的呢，重要有以下几点：
- 第一步，在对EditLog作任何修改前，QuorumJournalManager(NameNode上)必须被付与一个EpochNumber
- 第二步， QJM把本身的EpochNumber经由过程newEpoch(N)的方法发送给所有JN结点
- 第三步， 当JN收到newEpoch请求后，会把QJM的EpochNumber保存到一个lastPromisedEpoch变量中并持久化到本地磁盘
- 第四步， ANN同步日记到JN的任何RPC请求(如logEdits(),startLogSegment()等)，都必须包含ANN的EpochNumber
- 第五步，JN在收到RPC请求后，会将之与lastPromisedEpoch比较，如不雅请求的EpochNumber小于lastPromisedEpoch,将会拒绝同步请求，反之，会接收同步请求并将请求的EpochNumber保存在lastPromisedEpoch
如许就能包管主备NN产生切换时，就算同时向JN同步日记，也能包管日记不会写乱，因为产生切换后，原ANN的EpochNumber肯定是小于新ANN的EpochNumber，所以原ANN向JN的提议的所有同步请求都邑拒绝，实现隔离功能，防止了脑裂。
数据恢复后，ANN上会将本地处于in-process状况的日记改名为finalized状况的日记，情势如edits[start-txid][stop-txid]。
3.日记同步
这个步调膳绫擎有介绍到关于日记大年夜ANN同步到JN的过程,具体如下：
- 履行logSync过程，将ANN上的日记数据放到缓存队列中
- 精华存中数据同步到JN，JN有响应线程来处理logEdits请求
- JN收到数据后，先确认EpochNumber是否合法，再验证日记事务ID是否正常，将日记刷稻磁逄，返回ANN成功码
- ANN收到JN成功请求后返回client写成功标识，若掉败则抛出异常
经由过程膳绫擎一些步调，日记能包管成功同步到JN，同时包管JN日记的一致性，进而备NN上同步日记时也能包管数据是完全和一致的。
这个读过程是面向备NN(SNN)的，SNN按期检查JournalNode上EditLog的变更，然后将EditLog拉回本地。SNN上有一个线程StandbyCheckpointer，会按期将SNN上FSImage和EditLog归并，并将归并完的FSImage文件传回主NN(ANN)上，就是所说的Checkpointing过程。下面我们来看下Checkpointing是怎么进行的。
在2.x版本中，已经将本来的由SecondaryNameNode主导的Checkpointing调换成由SNN主导的Checkpointing。下面是一个CheckPoint的流向图:
[ 图5.Checkpointing流向图 ]
总的来说，就是在SNN上先检查前置前提，前置前提包含两个方面：距离前次Checkpointing的时光距离和EditLog中事务条数限制。前置前提任何一个知足都邑触发Checkpointing，然后SNN会将最新的NameSpace数据即SNN内存中当缁ご态的元数据保存到一个临时的fsimage文件( fsimage.ckpt)然后比对大年夜JN上拉到的最新EditLog的事务ID，将fsimage.ckpt_中没有，EditLog中有的所有元数据修改记录归并一路并重定名成新的fsimage文件，同时生成一个md5文件。将最新的fsimage再经由过程HTTP请求传回ANN。经由过程按期归并fsimage有什么好处呢，重要有以下几个方面：
可以避免主NN(ANN)压力过大年夜，归并是在SNN长进行的
可以包管fsimage保存的是一份最新的元数据，故障恢复时避免数据损掉
三、主备切换机制
要完成HA，除了元数据同步外，还得有一个完全的主备切换机制，Hadoop的主备选举依附于ZooKeeper。下面是主备切换的状况图：
[ 图6.Failover流程图 ]
大年夜图中可以看出，全部切换过程是由ZKFC来控制的，具体又可分为HealthMonitor、ZKFailoverController和ActiveStandbyElector三个组件。
- ZKFailoverController: 是HealthMontior和ActiveStandbyElector的母体，履行具体的切换操作
- HealthMonitor: 监控NameNode健康状况，若状况异常会触发还调ZKFailoverController进行主动主备切换
- ActiveStandbyElector: 通知ZK履行主备选举，若ZK完成变革，会回调ZKFailoverController响应办法进行主备状况切换
在故障切换时代，ZooKeeper主如果发挥什么感化呢，有以下几点：
- 掉败保护：集群中每一个NameNode都邑在ZooKeeper保护一个持久的session,机械一旦挂掉落，session就会过时，故障迁徙就会触发
- Active NameNode选择：ZooKeeper有一个选择ActiveNN的机制，一旦现有的ANN宕机，其他NameNode可以向ZooKeeper申请排他成为下一?Active节点
- 防脑裂： ZK本身是强一致和高可用的，可以用它来包管同一时刻只有一个晃荡节点
那在哪些场景会触发主动切换呢，大年夜HDFS-2185中归纳了以下几个场景：
网友点评
精彩导读
科技快报
品牌展示