HA JournalNode的作用

   为了保证 Active 节点和 Standby 节点，即可以可靠的保持数据的一致性，又不会影响集群的可用性，HDFS 在 Active 节点和 Standby 节点之间引入了另外一个节点 JournalNode 节点。

        JournalNode 节点作为 Active 节点和 Standby 节点的中间节点，它为两个节点解决了数据的同步的问题。首先 Active 节点会将元数据发送给 JournalNode 节点，然后 Standby 节点会从 JournalNode 节点获取需要同步的元数据。即使 Standby 节点故障了、产生问题了，在它恢复正常状态后，也可以从 JournalNode 节点中同步相应的数据。这就要求 JournalNode 节点需要有持久化的功能来保证元数据不丢。

        但是，问题又来了，JournalNode 节点如果挂掉又怎么办？那么这就对 JournalNode 节点提出了新的要求，它需要保证自己的可靠性，才能保证为 Standby 节点提供数据。因此 JournalNode 节点本身也是一个多节点的集群，从而保证它自身的可靠性。而且 JournalNode 节点会在集群自动的选择一个"主"节点出来，Active 节点会和 JournalNode 的主节点通信，然后 JournalNode 集群的主节点会将数据发送给其他的节点，只要有过半的节点完成了数据的存储，JournalNode 集群的主节点，就会将成功信息返回给 Active 节点。当 JournalNode 集群的主节点挂掉，其他的 JournalNode 节点会快速选举出新的"主"节点来。

        这样，通过 JournalNode 通过自身具备存储能力，和保证自身的可靠性，为 Active 节点和 Standby 节点之间的数据最终一致性提供了服务。

---

        为了使Standby节点保持其状态与Active 节点同步，两个节点都与一组称为"JournalNodes"（JN）的单独守护进程进行通信。当Active 节点执行任何命名空间修改时，它会持久地将修改记录记录到这些JN的大多数中。Standby节点能够从JN读取edit log内容，并不断监视它们以查看edit log内容的更改。当“Standby节点”看到edit log变化时，会将其应用到自己的命名空间。发生故障转移时，备用服务器将确保在将自身升级为活跃状态之前，已从JournalNode读取所有edit log内容。这样可确保在发生故障转移之前，命名空间状态已经完全同步。

        JournalNode守护程序相对较轻，因此可以合理地将这些守护程序与其他Hadoop守护程序（例如NameNodes，JobTracker或YARN ResourceManager）并置在计算机上。

        注意：必须至少有3个JournalNode守护程序，因为必须将编辑日志修改写入大多数JN。这将允许系统容忍单个计算机的故障。您可能还会运行3个以上的JournalNode，但是为了实际增加系统可以容忍的故障数量，您应该运行奇数个JN（即3、5、7等）。请注意，当与N个JournalNode一起运行时，系统最多可以容忍（N-1）/ 2个故障，并继续正常运行