從Hadoop HA到Zookeeper到Kafka（瞭解篇）

Kafka基於Zookeeper協調的分佈式日誌系統，能夠當作MQ。主要就是作：日誌收集系統、消息系統。
還有就是用於用戶活動跟蹤：記錄web用戶或者app用戶的各類活動，相信你們都感覺到了吧。
上篇咱們已經提到，消息系統的兩種傳遞模式：點對點、訂閱/發佈。這裏將再也不贅述。

【對比】

名稱	Column 2
RabbitMQ	使用Erlang編寫的一個開源的消息隊列，適合企業級的開發，同時實現了Broker構架，對路由、負載均衡或者數據持久化都有很好的支持
Redis	基於Key-value的Nosql數據庫，自己也支持MQ功能，能夠當作輕量級的隊列服務來使用。
ZeroMQ	聽說是最快的消息隊列系統，針對大吞吐量的需求場景，可以實現RabbitMQ不擅長的高級、複雜的隊列，可是技術上比較難一點
ActiveMQ	這個我們上篇文章已經初步探究了一下，是Apache下的一個子項目，相似ZeroMQ，可以代理任何點對點的技術實現隊列；同時，相似RabbitMQ以少許的代碼高效的實現更高級的應用。
Kafka/Jafka	KafKa也是Apache下的一個子項目，是一個高性能的跨語言分佈式發佈/訂閱消息隊列系統。kafka相對於ActiveMQ是一個很是輕量級的消息系統，仍是一個良好的分佈式系統。Jafka是kafka演化而來的。

【爲了搭建kafka，這裏得先拓展一下zookeeper安裝】

問， 爲何要安裝Zookeeper呢？
答：在Hadoop 2.0以前,在HDFS 集羣中NameNode 存在單點故障 (SPOF：A Single Point of Failure)。 對於只有一個 NameNode 的集羣，若是 NameNode 機器出現故障(好比宕機或是軟件、硬件 升級)，那麼整個集羣將沒法使用，直到 NameNode 從新啓動。
HDFS 的 HA 功能經過配置 Active/Standby 兩個 NameNodes 實如今集羣中對 NameNode 的 熱備來解決上述問題。若是出現故障，如機器崩潰或機器須要升級維護，這時可經過此種方 式將 NameNode 很快的切換到另一臺機器。
在典型HA集羣中，使用兩臺單獨的機器配置未NameNodes。任意時間點，確保NameNodes中只有一個出去Active狀態，其餘處在等待狀態。其中ActiveNameNode負責集羣中的全部客戶端操做，StandbyNameNode充當備機，主程序出現問題是可以快速的切換。
爲實現同步Active【激活】與Standby【等待】兩個NameNode的元數據信息須要一個共享存儲系統，這個系統能夠是NFS、QJM或者是Zookeeper。爲了實現快速切換， Standby 節點獲取集羣的最新文件塊信息也是頗有必要的。爲了實現這一目標，DataNode 需 要配置 NameNodes 的位置，並同時給他們發送文件塊信息以及心跳檢測。
參考：《ZooKeeper學習之路 （九）利用ZooKeeper搭建Hadoop的HA集羣 》

【集羣】
Hadoop的HA集羣的搭建依賴於Zookeeper。所以這裏先拓展一下Zookeeper的安裝。
【PS，鑑於我這裏只有一個虛擬機，所以Zookeeper和Hadoop我都不安裝了。之後用到再學吧，並非我懶啊（或許是真的懶）。】