Hadoop的元数据主要作用是维护HDFS文件系统中文件和目录的相关信息。元数据存储形式主要由三类：内存镜像、磁盘镜像（fsImage）、日志（EditLog）。在Namenode启动时，会加载磁盘镜像到内存中以进行元数据的管理，存储在Namenode内存；磁盘镜像是某一时刻HDFS元数据信息的快照，包含所有相关Datanode节点文件块的映射关系和命名空间信息，存储在Namenode本地文件系统。日志记录文件记录client发起的每一次操作，用于定期和fsImage合并为最新镜像，保证namenode元数据信息的完整，存储在NameNode本地和共享存储系统（QJM）中。
如下所示为NameNode本地的EditLog和fsImage文件格式。CheckPoitn过程在SNN上进行，SNN定期将本地fsImage和从QJM拉回的ANN的editLog合并，合并后再通过RPC传回ANN
data/hbase/runtime/namespace
├── current
│ ├── VERSION
│ ├── edits_0000000003619794209-0000000003619813881
│ ├── edits_0000000003619813882-0000000003619831665
│ ├── edits_0000000003619831666-0000000003619852153
│ ├── edits_0000000003619852154-0000000003619871027
│ ├── edits_0000000003619871028-0000000003619880765
│ ├── edits_0000000003619880766-0000000003620060869
│ ├── edits_inprogress_0000000003620060870
│ ├── fsimage_0000000003618370058
│ ├── fsimage_0000000003618370058.md5
│ ├── fsimage_0000000003620060869
│ ├── fsimage_0000000003620060869.md5
│ └── seen_txid
└── in_use.lock
HA本质上就是保证主备NN元数据的一致，即保证fsimage和editlog在备NN上也是完整的。，元数据的同步很大程度取决于EditLog的同步，而这步骤的关键就是共享文件系统。
QJM原理
QJM全称是Quorum Journal Manager, 由JournalNode（JN）组成，一般是奇数点结点组成。每个JournalNode对外有一个简易的RPC接口，以供NameNode读写EditLog到JN本地磁盘。当写EditLog时，NameNode会同时向所有JournalNode并行写文件，只要有N/2+1结点写成功则认为此次写操作成功，遵循Paxos协议。其内部实现框架如下：
1.FSEditLog # 所有EditLog操作的入口
2.JournalSet # 集成本地磁盘和JournalNode集群上EditLog的相关操作
3.FileJournalManager # 实现本地磁盘上 EditLog 操作
4.QuorumJournalManager # 实现JournalNode 集群EditLog操作
5.AsyncLoggerSet # 实现JournalNode 集群 EditLog 的写操作集合
6.AsyncLogger # 发起RPC请求到JN，执行具体的日志同步功能
7.JournalNodeRpcServer # 运行在 JournalNode 节点进程中的 RPC 服务，接收 NameNode 端的AsyncLogger 的 RPC 请求。
8.JournalNodeHttpServer # 运行在 JournalNode 节点进程中的 Http 服务，用于接收处于 Standby 状态的 NameNode 和其它 JournalNode 的同步 EditLog 文件流的请求。
QJM写操作
上面提到EditLog，NameNode会把EditLog同时写到本地和JournalNode。写本地由配置中参数dfs.namenode.name.dir控制，写JN由参数dfs.namenode.shared.edits.dir控制，在写EditLog时会由两个不同的输出流来控制日志的写过程，分别为：EditLogFileOutputStream(本地输出流)和QuorumOutputStream(JN输出流)。写EditLog也不是直接写到磁盘中，为保证高吞吐，NameNode会分别为EditLogFileOutputStream和QuorumOutputStream定义两个同等大小的Buffer，大小大概是512KB，一个写Buffer(buffCurrent)，一个同步Buffer(buffReady)，这样可以一边写一边同步，所以EditLog是一个异步写过程，同时也是一个批量同步的过程，避免每写一笔就同步一次日志。
这个是怎么实现边写边同步的呢，这中间其实是有一个缓冲区交换的过程，即bufferCurrent和buffReady在达到条件时会触发交换，如bufferCurrent在达到阈值同时bufferReady的数据又同步完时，bufferReady数据会清空，同时会将bufferCurrent指针指向bufferReady以满足继续写，另外会将bufferReady指针指向bufferCurrent以提供继续同步EditLog。上面过程用流程图就是表示如下：
这里有一个问题，既然EditLog是异步写的，怎么保证缓存中的数据不丢呢,其实这里虽然是异步,但实际所有日志都需要通过logSync同步成功后才会给client返回成功码，假设某一时刻NameNode不可用了，其内存中的数据其实是未同步成功的，所以client会认为这部分数据未写成功。
隔离双写
EditLog怎么在多个JN上保持一致的呢。在ANN每次同步EditLog到JN时，先要保证不会有两个NN同时向JN同步日志。这里面涉及一个很重要的概念Epoch Numbers，很多分布式系统都会用到。Epoch有如下几个特性：
1.当NN成为活动结点时，其会被赋予一个EpochNumber
2.每个EpochNumber是唯一的，不会有相同的EpochNumber出现
3.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的发起的所有同步请求都会拒绝，实现隔离功能，防止了脑裂。
恢复in-process日志
如果写过程失败，可能各个JN上的EditLog的长度不一样，需要在开始写之前将不一致的部分恢复。
恢复机制
ANN先向所有JN发送getJournalState请求；
JN会向ANN返回一个Epoch（lastPromisedEpoch)；
ANN收到大多数JN的Epoch后，选择最大的一个并加1作为当前新的Epoch，然后向JN发送新的newEpoch请求，把新的Epoch下发给JN；
JN收到新的Epoch后，和lastPromisedEpoch对比，若更大则更新到本地并返回给ANN自己本地一个最新EditLogSegment起始事务Id,若小则返回NN错误；
ANN收到多数JN成功响应后认为Epoch生成成功，开始准备日志恢复；
ANN会选择一个最大的EditLogSegment事务ID作为恢复依据，然后向JN发送prepareRecovery； RPC请求，对应Paxos协议2p阶段的Phase1a，若多数JN响应prepareRecovery成功，则可认为Phase1a阶段成功；
ANN选择进行同步的数据源，向JN发送acceptRecovery RPC请求，并将数据源作为参数传给JN。
JN收到acceptRecovery请求后，会从JournalNodeHttpServer下载EditLogSegment并替换到本地保存的EditLogSegment，对应Paxos协议2p阶段的Phase1b，完成后返回ANN请求成功状态。
ANN收到多数JN的响应成功请求后，向JN发送finalizeLogSegment请求，表示数据恢复完成，这样之后所有JN上的日志就能保持一致。
QJM读过程
这个读过程是面向备NN(SNN)的，SNN定期检查JournalNode上EditLog的变化，然后将EditLog拉回本地。SNN上有一个线程StandbyCheckpointer，会定期将SNN上FSImage和EditLog合并，并将合并完的FSImage文件传回主NN（ANN）上，就是所说的Checkpointing过程。下面我们来看下Checkpointing是怎么进行的。
总的来说，就是在SNN上先检查前置条件，前置条件包括两个方面：距离上次Checkpointing的时间间隔和EditLog中事务条数限制。前置条件任何一个满足都会触发Checkpointing，然后SNN会将最新的NameSpace数据即SNN内存中当前状态的元数据保存到一个临时的fsimage文件( fsimage.ckpt）然后比对从JN上拉到的最新EditLog的事务ID，将fsimage.ckpt_中没有，EditLog中有的所有元数据修改记录合并一起并重命名成新的fsimage文件，同时生成一个md5文件。将最新的fsimage再通过HTTP请求传回ANN。通过定期合并fsimage有什么好处呢，主要有以下几个方面：
1. 可以避免EditLog越来越大，合并成新fsimage后可以将老的EditLog删除
2. 可以避免主NN（ANN）压力过大，合并是在SNN上进行的
3. 可以保证fsimage保存的是一份最新的元数据，故障恢复时避免数据丢失
主备切换机制
要完成HA，除了元数据同步外，还得有一个完备的主备切换机制，Hadoop的主备选举依赖于ZooKeeper。下面是主备切换的状态图：
整个切换过程由ZKFC控制，具体可分为HealthMonitor，ZKFailoverController和ActiveStandbyElector三个组件。
1.ZKFailoverController # 是HealthMontior和ActiveStandbyElector的母体，执行具体的切换操作
2.HealthMonitor # 监控NameNode健康状态，若状态异常会触发回调ZKFailoverController进行自动主备切换
3.ActiveStandbyElector # 通知ZK执行主备选举，若ZK完成变更，会回调ZKFailoverController相应方法进行主备状态切换
故障切换期间，zk的作用
1.失败保护 # 集群中每一个NameNode都会在ZooKeeper维护一个持久的session,机器一旦挂掉，session就会过期，故障迁移就会触发
2.Active NameNode选择 # ZooKeeper有一个选择ActiveNN的机制，一旦现有的ANN宕机，其他NameNode可以向ZooKeeper申请排他成为下一个Active节点
3.防脑裂 # ZK本身是强一致和高可用的，可以用它来保证同一时刻只有一个活动节点
好兄弟画的流程图
