HDFS QJM机制分析
一 Adtive NameNode / Standby NameNode的读写editlog
ActiveNameNode负责往JournalNode写editlog,Standby NameNode负责从这些JournalNameNode读取editlog,然后同步到自己的内存中，保证和Active NameNode的元数据一致
二 StandbyNameNode如何定期到JournalNode上进行同步editlog
EditLogTailer是一个会定期读取edit 日志并且应用事务的线程。
logRollPeriodMs：ActiveNameNode写入新editlog最长容忍时间，如果距离上次写完的时间已经超过此间隔时间，超过此时间限制，就会触发ActiveNameNode进行一个rollEditLog操作，此时间可以通过
dfs.ha.log-roll.period配置，默认120s,滚动写editlog
sleepTimeMs：StandbyNameNode同步editlog的周期时间，默认60s,可以通过dfs.ha.tail-edits.period设置
三 QJM机制背景介绍
我们知道HDFS NameNode宕机恢复到以前状态，需要通过读取FSImage文件，就能还原。SecondaryNameNode负责合并editlog到FSImage文件。但是这样的单节点会有单点问题，不能保证NameNode
高可用。如果需要高可用，我们需要配置HA。HA状态下，我们并不能只把日志文件保存到一个节点，如果这个机器宕机，那么备份节点，是没有办法获取到和之前Active节点相同的元数据，所以可能导致数据不一致。
所以QJM应运而生，核心思想就是用2N+1台机器写editlig,只要有N个以上的机器写操作成功就是认为该次写成功。如果少于N台就认为失败
四 读写日志的机制分析
NameNode启动之后，会根据HA的状态判断是active还是standby状态。如果是Active状态，调用FSNamesystem的startActiveServices
否则调用StartStandbyServices.
4.1Active NameNode写日志
调用FSNamesystem.startActiveServices：
4.1.1获取FSEditlog,判断editlog是否处于打开写状态，如果没有则初始化Journal。
4.1.2设置editlog下一个事务id
4.1.3开始写editlog： 首先获取所有的JN 的 editlog输出流，然后开始将segment写到日志；最后刷新并异步向其他JouranlNode写日志。ActiveNameNode会标记返回失败的JN,下一次日志不再写该节点，直到下一次调用滚动日志操作，如果此时JN节点恢复正常，才开始写日志，虽然该节点丢失部分日志，但是主节点写了多分。
4.2Standby NameNode读取editlog并更新fsimage文件
调用FSNamesystem.startStandbyServices：
4.2.1检查editlog是否可以打开读，如果不行，则需要初始化共享存储目录，然后读取
4.2.2创建EditlogTailer对象，调用其run方法，开始读取editlog并更新fsimage文件。流程如下：
首先：检查Active NameNode日志滚动是否到期，如果到期，触发日志滚动，标记为Finalized状态，然后打开一个新的segment用于记录editlog
然后：开始做StandbyNamenode的taileditlog操作：获取FSImage，获取editlog输出流；然后加载editlog