<a href="#_Toc16131%20">目錄 1</a>
<a href="#_Toc4363%20">1. 前言 1</a>
<a href="#_Toc18795%20">2. 背景 1</a>
<a href="#_Toc24592%20">3. 解析 1</a>
為何需要Federation？衆所周知，之前的HDFS存在如下幾個缺陷：
1) NameNode存在單點，不具備高可用性
2) 由于受限于單個NameNode，支撐的檔案數量有限
3) 同樣受限于單個NameNode，吞吐量有限
站在運維和高可用性的角度，解決這些問題，系統運作可以省心得多。HDFS Federation是以很自然的誕生了，但請注意它隻解決了後兩個問題，第一個問題不在它的解決範疇之内。
為何說很自然的誕生，稍加思考即可明白解決這兩個問題能有什麼手段：無非是更新機器的記憶體和CPU，也就是縱向更新；另一個就是增加機器，也就是橫向更新。
顯然更新記憶體和CPU的手段是非常有限的，不能從根本上解決問題，兩個問題仍然存在，是以可行的隻有增加機器這個唯一手段了。
沒有Federation之前的HDFS架構如下圖所示（沒有畫SecondaryNameNode，是因為SecondaryNameNode是針對單點，而非Federation要解決的兩個問題），這是一種非常簡潔的架構，很明顯壓力都集中在單個NameNode上，它成了系統瓶頸：
Federation版本的HDFS架構變成如下，顯然這裡不止一個NameNode，而是存在多個NameNode，并且可以按需要添加新的NameNode進行橫向擴充。這裡的多個NameNode間地位是平等的，而且互不幹涉互不隸屬，站在每個NameNode上看，它就是一個獨立的HDFS叢集：
南京全面深化改革工作上司小組成立，由市委書記和市長同時擔任改革小組組長，通過前面的描述不難發現HDFS Federation和這個有點類似，那麼就會産生一個疑問：聽誰的？不亂了麼？答案是：都聽。
俗話曰無規則不成方圓，顯然都聽就亂序了。如果把這個關系了解成外包，可能更好了解一點，比如同一家外包公司會同時服務于多家公司，如下圖所示：
可以進一步抽象：一個實體節點被虛拟化成多個虛拟節點，虛拟節點和NameNode是一一對應的，但實體節點和NameNode是一對多的關系。實際上Google Borg/Apache Mesos/Hadoop Yarn就是這樣一種行為。進一步可看作：有多少個NameNode，就有多少個實體磁盤一樣，Namespace就相當于C:\、D:\等：
甚至，可以将NameNode看作是DataNode的用戶端，而DataNode則是服務端，服務端當然可以服務不同的用戶端。
HDFS Federation雖然未解決單點問題，但因為多個NameNode的存在，單個NameNode故障的影響就降低了，是以可以說HDFS Federation弱化了單點問題。
要從根本上解決單點，有多種可行的手段：
1) Share Storage，主備NameNode共享同一個存儲，可保證資料完整性
2) 像SecondaryNamenode一樣的備份，但不能保證資料完整性
3) 引入兩階段送出（2PC），可保證一緻性，但寫性能會下降
4) 引入Quorum NRW，也可保證一緻性，可以選擇犧牲讀性能來提升寫性能
也許2PC是相對較好的解決方式。