其實就是簡單的 replica
冗餘存在的目的就是為了防止掛掉
任何形式的掛掉都要防止
基本的原理異常的簡單
如下：
每一個replica HDFS ，HBse 這些都有各自的replica
每一個replica都會企圖在 zookeeper 的某一個目錄節點獲取一個鎖
拿到鎖的就是master ， 比如說replica（1）拿到了鎖，但是需要定期的和zookeeper 交流感情，
其他沒拿到鎖的 replica (2.3.4.5.6.)就告訴 zookeeper 說：“你要是覺得那個replica（1）掛了你告訴我一聲 啊！
注意： 是覺得哦！ 這裡分兩種可能
1） replica（1）掛了
2） network partition 把replica（1） 從網路中物理的隔開了。
這個時候其他的replica（2.3.4.5.6.) 就會再去爭搶那個 master了.
這就是冗餘機制 其實 hdfs的冗餘機制沒啥特別的 ， 主要是 作為BigTable的開源實現，NONsql資料庫的特性比較重要吧
而且zookeeper 本身 作為 Google Chubby 的開源實現 ，也是透過實現 PAXOS 演算法來保持 自身的 Consensus 的 只不過它是建立在 TCP 協議基礎上的， 所以zookeeper吧Chubby的演算法改進了一下換了個名字叫 ..total order broadcast protocol 略無恥.
所謂特點的話： 其實就是在有這個zookeeper （Chubby） 以前 Google 使用另外一種演算法來保證核心鎖機制的 Consensus的 .. 只是那個有很多問提， 需要有人值守 這個就是我上面為什麼提到掛掉的那兩種可能的原因
基本上就是這樣了 。。。
你要是想學的話 Google scholar + Hadoop in action 用起來 五六個月就能有所小成了
其實就是簡單的 replica
冗餘存在的目的就是為了防止掛掉
任何形式的掛掉都要防止
基本的原理異常的簡單
如下：
每一個replica HDFS ，HBse 這些都有各自的replica
每一個replica都會企圖在 zookeeper 的某一個目錄節點獲取一個鎖
拿到鎖的就是master ， 比如說replica（1）拿到了鎖，但是需要定期的和zookeeper 交流感情，
其他沒拿到鎖的 replica (2.3.4.5.6.)就告訴 zookeeper 說：“你要是覺得那個replica（1）掛了你告訴我一聲 啊！
注意： 是覺得哦！ 這裡分兩種可能
1） replica（1）掛了
2） network partition 把replica（1） 從網路中物理的隔開了。
這個時候其他的replica（2.3.4.5.6.) 就會再去爭搶那個 master了.
這就是冗餘機制 其實 hdfs的冗餘機制沒啥特別的 ， 主要是 作為BigTable的開源實現，NONsql資料庫的特性比較重要吧
而且zookeeper 本身 作為 Google Chubby 的開源實現 ，也是透過實現 PAXOS 演算法來保持 自身的 Consensus 的 只不過它是建立在 TCP 協議基礎上的， 所以zookeeper吧Chubby的演算法改進了一下換了個名字叫 ..total order broadcast protocol 略無恥.
所謂特點的話： 其實就是在有這個zookeeper （Chubby） 以前 Google 使用另外一種演算法來保證核心鎖機制的 Consensus的 .. 只是那個有很多問提， 需要有人值守 這個就是我上面為什麼提到掛掉的那兩種可能的原因
基本上就是這樣了 。。。
你要是想學的話 Google scholar + Hadoop in action 用起來 五六個月就能有所小成了