paxos zookeeper

其实就是简单的 replica ... 冗余存在的目的就是为了防止挂掉 任何形式的挂掉都要防止 基本的原理异常的简单 如下： 每一个replica ... HDFS ，HBse 这些都有各自的replica 每一个replica都会企图在 zookeeper 的某一个目录节点获取一个锁

---

　　其实就是简单的 replica
冗余存在的目的就是为了防止挂掉
任何形式的挂掉都要防止
基本的原理异常的简单
如下：
每一个replica hdfs ，hbse 这些都有各自的replica
每一个replica都会企图在 zookeeper 的某一个目录节点获取一个锁
拿到锁的就是master ， 比如说replica（1）拿到了锁，但是需要定期的和zookeeper 交流感情，
要么就是zookeeper periodical 的ping一下，看看那个replica（1）还活着没有，要么就是replica（1）主动去报道，告诉master “ 呵呵我还活着” 这个叫 master session
其他没拿到锁的 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 用起来 五六个月就能有所小成了