这里是大数据小白系列，这是本系列的第三篇，介绍HDFS中NameNode选举，JournalNode等概念。
上一期我们说到了为解决NameNode(下称NN)单点失败问题，HDFS中使用了双NN的机制，一个Active NN，一个Standby NN。
现实常常是，解决一个问题的同时，免不了又引入了另外的问题。
谁来担任Active，谁来担任Standby？
两个NN谁也说服不了谁，这个时候需要引入一个外部角色：一个Zookeeper(下称ZK)集群。
ZK也是个很有趣的东西，大数据小白系列后续会专门介绍。
这里，ZK集群扮演了类似裁判的角色，如果两个NN同时申请成为Active，由ZK决定谁将获胜。
两台NN机器上都分别存在一个ZKCF(Zookeeper Failover Controller)进程，该进程相当于ZK的一个客户端。
ZKFC定期检查NN进程的状态，如状态正常，并且目前没有其他NN在持有ZK集群上的锁，则加入选举，并且申请锁。(注：所谓的锁，实际上是ZK集群上的一种特殊目录)
若ZKFC检查NN进程不正常，则退出选举，并放弃ZK上的锁(如持有)。
Q：如果不是NN进程死了，而是整个NN机器掉电了呢？
A：当集群与ZKFC进程的连接断开超过一定时间，锁将自动过期，以便其他NN可以申请重新选举。
Q：如果Active、Standby都死了呢？
A：不好意思，那就死透了。
上一期提到的另外一个内容，Active NN负责将Edit Log写入某个“共享存储”，而Standby NN负责从该位置读取以保持同步。
最简单的，可以使用NFS(Network File System)来担任共享存储。
但是NFS本身成为了单点失败，即，如果NFS系统坏了，导致Edit Log无法读写，整个HDFS系统也就无法工作。
因此，HDFS推荐使用的是专为Edit Log高可用性所设计的“JournalNode(下称JN))集群”。
NN通过QJM(Quorum Journal Manager)进程将Edit Log写入某JN节点，该JN节点需要将数据写入其他JN节点，直到数据被写入集群中的“多数节点”，本次操作才算成功。
例如，JN集群中共有3个节点，需要写入到其中2个节点，即所谓的“多数”(majority)。
通常，JN集群总是包含奇数个节点，至于为什么，我准备在介绍ZK的时候再来说明，因为二者比较类似。
需要注意，虽然QJM的工作机制类似于ZK，但本身并没有用到ZK，同时它也比ZK来的轻量级，它可以跑在集群现有的机器上，而不需要单独为它准备机器。
好了，这期就先到这，下期我们将介绍现实世界中的HDFS集群，以及Federation等概念。Cheers!
作者公众号“程序员杂书馆”，专注大数据，欢迎关注，每位关注者将获赠《Spark快速大数据分析》纸质书一本