大数据小白系列——HDFS(3)

这里是大数据小白系列，这是本系列的第三篇，介绍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快速大数据分析》纸质书一本