HDFS HA QJM源码分析

       Hadoop QJM的实现用到了paxos算法，pasos算法是是莱斯利·兰伯特于1990年提出的一种基于消息传递的一致性算法。 这个算法被认为是类似算法中最有效的。pasos算法用在hadoop HA的实现里面就是要确保active namenode和standby namenode的状态保持一致。

       在hadoop的源码里的ha包下有一个EditLogTailer类，这个类里有一个线层类EditLogTailerThread，standby 状态下的namenode运行的时候会启动EditLogTailerThread。这个线层会周期性的发送消息去触发active namenode回滚edits，默认的时间间隔是2分钟，发送这个消息后EditLogTailerThread会阻塞等待active的响应。

       Active接收到这个消息后会调用到NameNodeRpcServer的rollEditLog()方法，进而调用到FSImage的rollEditLog()方法，最后才调用到FSEditLog的rollEditLog()方法。下面是FSEditLog的rollEditLog()方法实现：

 

可以看出在这个方法里面会先结束当前的logSegment,然后计算下次的TxId,并用这个TxId开始下一次的logSegment。在endCurrentLogSegment()方法里面会先检查当前fsEditLog的状态是否是in_segment状态，如果是才进行后续的操作。接着active会向journalNode发送edits。这里要注意一点，active首先向journalNode发送edit而不是写本地edits是非常重要的，因为有可能active本地的eidts已经持久化到磁盘上了，而在发送到journalNode之前active宕掉了，当namenode发生主从切换后，原来的active变成了standby,但是它读磁盘上的edits获得的Txid比journalNode上的靠后，现在的active的txid比standby的txid要小，所以会造成active和standby状态不一致。因此active在向journalNode写edits时会确定同步到多数journalNode的磁盘上时才会写本地的edits,为了保证active namenode能接收到绝大多数的响应，而不会出现成功的rolledits和失败的rolledits个数相同，所以journalnode必须配置成基数个,active在收到大多数成功或大多数失败时才会认为这次调用是成功的。当active成功向journalnode传输完edits后，会继续远程调用journalnode的finalizeLogSegment()方法，以确保这次logsegement结束。前面的步骤结束后，FSEditLog对象会进入BETWEEN_LOG_SEGMENTS 状态。接着active还会用下一个Txid远程调用journalnode的startlogSegement()，从而在journalnode上生成下次edits的文件，完了之后FSEditLog对象的状态转为IN_SEGMENT。

     现在我们再回到standby namenode端。Standby 在成功收到active的返回后，会向journalnode发起http请求下载此次roll的edit,发http请求的时候使用的是HttpConnection类,直接访问journalnode的http服务得到输入流；得到本次edit的输入流后，standby会将edit载入到自己维护的fseditslog对象中。另外datanode是会同时向active和standby发送block report的。由于standby内存中维护的edit和active中维护的差不多，只有两分钟的时间差，再加上datanode的block report,所以在active挂掉的时候，standby能很快代替active提供服务。

      另外，standby还有一个checkpoint线层，定期roll edits形成新的fsimage,standby默认会备份一份fsimage,所以standby的目录下通常会有两份不同时间的fsimage文件。Standby在生成fsimage文件后，active会访问standby的web服务讲fsimage文件下载到自己的目录下。

      还有一个问题，就是任何时刻都只能允许一个namenode往journalnode上写数据，另一个只能读。所以在一个namenode成为active状态是会向journalnode写一个新的epoch值，只有持有这个值得namenode才能像journalnode写数据，从而保证了不会出现两个namenode都向journalnode写数据的情况。