看了Facebook用来为HDFS Namenode提供HA的AvatarNode方案，不明白为什么要用NFS。令我困惑的是 NFS 无论如何都必须复制才能实现 HA。主数据库必须写入 NFS 并刷新才能获得 HA。为什么不简单地在主节点和次节点之间打开一个套接字通道，并对次节点 Namenode 执行相同的写入操作。这将是（大约）相同数量的网络流量，并且似乎具有相同的复制语义。
那么问题来了，为什么不这样做呢？
我想其中一个原因可能是 NFS 存在，因此问题可能更容易实现。但是考虑到在主要和次要之间使用原始套接字通道的（明显）简单性，将写入流接口（即文件）的相同信息写入 NFS，我不知道为什么这不是完成了。
当然，选择使用我在扶手椅分析中遗漏的 NFS 肯定有充分的理由。
我不知道，但我同意这似乎是一个非常奇怪的选择，而且我真的想不出任何其他原因，但负责修复某些东西的团队有一个功能正常的 NFS 设置，它已经为其他用途工作。但是根据我的经验，我认为 NFS 是另一个失败的单点，并且不会在这种情况下选择它。
有趣的问题。我在 AvatarNodes 上找到了这篇文章：http: //hadoopblog.blogspot.com/2010/02/hadoop-namenode-high-availability.html
在我看来，AvatarNode 允许您在名称节点出现故障时最大限度地减少停机时间，并在不到一分钟的时间内用新的名称节点备份。
从hadoop文档：
The term "secondary name-node" is somewhat misleading. It is not a name-node in the
sense that data-nodes cannot connect to the secondary name-node, and in no event it can
replace the primary name-node in case of its failure.
由于辅助名称节点不能充当名称节点，因此在恢复或启动新名称节点时可能会出现较长的停机时间。
AvatarNode 既可以充当辅助节点，也可以充当主要节点，并允许快速故障转移，只需切换 VIP。
关于为什么使用 NFS 而不是套接字，帖子说
It is guaranteed that the Standby AvatarNode ingests all committed transactions because
it reopens the edits log and consumes all transactions till the end of the file; this
guarantee depends on the fact that NFS-v3 supports close-to-open cache coherency
semantics.
我认为这是在名称节点出现故障时最大限度地减少数据丢失并保持与 HDFS 编辑数据的一致性的问题。更多关于接近开放一致性保证的信息：http: //nfs.sourceforge.net/#faq_a8
哈尔，这可能会回答您的问题（尤其是“在路上踢罐头”位）..