白眉大叔 一、 HA
1.解决 NameNode 元数据共享存储问题是 通过 QJM
NameNode 记录了 HDFS 的目录文件等元数据，客户端每次对文件的增删改等操作，Namenode 都会记录一条日志，叫做 editlog，而元数据存储在 fsimage 中。为了保持 Stadnby与 active 的状态一致，standby 需要尽量实时获取每条 editlog 日志，并应用到 FsImage 中。这时需要一个共享存储存放 editlog，standby 能实时获取日志。
有两个关键点需要保证：
1）共享存储是高可用的。
2）需要防止两个 NameNode 同时向共享存储写数据导致数据损坏。
共享存储常用的方式是 Qurom Journal Manager，QJM
QJM 可以认为是包含一些 JournalNode的集群，JournalNode 运行在不同的机器上，每个 JournalNode 是一个很轻量的守护进程，所以可以部署在 hadoop 集群的节点上，QJM 中至少要有 3 个 JournalNode，因为 edit log必须要写到 JournalNodes 中大部分节点中，比如运行 3,5,7 个 JournalNode，如果你运行了N 个 JournalNode，那么系统可以容忍最多(N-1)/2 个节点失败。
共享存储实现逻辑：
1）初始化后，Active NN 把 editlog 写到大多数 JN 并返回成功（即大于等于 N+1）即认定写成功。
2）Standby NN 定期从 JN 读取一批 editlog，并应用到内存中的 FsImage 中。
3）NameNode 每次写 Editlog 都需要传递一个编号 Epoch 给 JN，JN 会对比 Epoch，如果比自己保存的 Epoch 大或相同，则可以写，JN 更新自己的 Epoch 到最新，否则拒绝操作。在切换时，Standby 转换为 Active 时，会把 Epoch+1，这样就防止即使之前的 NameNode 向JN 写日志，即使写也会失败。
二、利用 Zookeeper 实现 NameNode 故障转移
HDFS2 NN 的主备切换流程
欢迎来撩 ： 汇总all
