转自 http://blog.csdn.net/u010185262/article/details/49910301
Zookeeper
zookeeper是一个分布式应用程序的协调服务。它是一个为分布式应用提供一致性服务的软件，提供的性能包括：配置维护、名字服务、分布式同步、组服务等。
zookeeper是以Fast Paxos算法为
基础，paxos算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fase
Paxos作了一些优化，通过选举产生一个leader，只有leader才能提交proposer，具体的可以看一下Fast Paxos算法。
Zookeeper的基本运转流程：
- 选举leader；
- 同步数据；
- 选举leader过程中算法有很多，但要达到的选举标准是一致的；
- leader要有更高的zxid；
- 集群中大多数的机器得到响应并follow选出的leader。
小说了一下Zookeeper，接下来讨论一下脑裂，假死等等问题以及解决方法吧。
假死脑裂
在一个大的集群中往往会有一个master的存在，在长期运行过程中不可避免会出现宕机等等的问题导致master不可用，在出现这样的情况以后往往会对系统产生很大的影响，所以一般的分布式集群中的master都采用了高可用的解决方案来避免这样的情况发生。
master-slaver方式，存在一个master的节点，平时对外服务，同时有一个slaver节点来监控master，监控的同时有某种方式来进
行数据同步。假如现在master挂掉了，slaver能很快获知并且迅速切换为新的master。但是在这种方式中，监控切换是一个很大的难题，但是现
在Zookeeper的watch和分布式锁机制能比较好的解决这个问题。虽然Zookeeper很好的解决了这个问题，但是它的使用也存在其他的问题，
比如脑裂。
导致脑裂的一个根源问题就是假死。
什么叫假死呢？
有一个很重要的问题，就是到底是根据一个什么样的情况来判断一个节点死亡down掉了。
在分布式系统中这些都是有监控者来判断的，但是监控者也很难判定其他的节点的状态，唯一一个可靠的途径就是心跳，包括Zookeeper也是使用心跳来判断客户端是否仍然活着。
使用ZooKeeper来做master
HA基本都是同样的方式，每个节点都尝试注册一个象征master的临时节点其他没有注册成功的则成为slaver，并且通过watch机制监控着
master所创建的临时节点，Zookeeper通过内部心跳机制来确定master的状态，一旦master出现意外Zookeeper能很快获悉并
且通知其他的slaver，其他slaver在之后作出相关反应。这样就完成了一个切换。这种模式也是比较通用的模式，基本大部分都是这样实现的，但是这
里面有个很严重的问题，如果注意不到会导致短暂的时间内系统出现脑裂，因为心跳出现超时可能是master挂了，但是也可能是
master，zookeeper之间网络出现了问题，也同样可能导致。这种情况就是假死，master并未死掉，但是与ZooKeeper之间的网络出
现问题导致Zookeeper认为其挂掉了然后通知其他节点进行切换，这样slaver中就有一个成为了master，但是原本的master并未死掉，
这时候client也获得master切换的消息，但是仍然会有一些延时，zookeeper需要通讯需要一个一个通知，这时候整个系统就很混乱可能有一
部分client已经通知到了连接到新的master上去了，有的client仍然连接在老的master上如果同时有两个client需要对
master的同一个数据更新并且刚好这两个client此刻分别连接在新老的master上，就会出现很严重问题。
是什么原因导致这样情况的出现呢？
主要原因是Zookeeper集群和Zookeeper
client判断超时并不能做到完全同步，也就是说可能一前一后，如果是集群先于client发现那就会出现上面的情况。同时，在发现并切换后通知各个客
户端也有先后快慢。一般出现这种情况的几率很小，需要master与Zookeeper集群网络断开但是与其他集群角色之间的网络没有问题，还要满足上面
那些情况，但是一旦出现就会引起很严重的后果，数据不一致。
如何避免？
在slaver切换的时候不在检查到老的master出现问题后马上切换，而是在休眠一段足够的时间，确保老的master已经获知变更并且做了相关的
shutdown清理工作了然后再注册成为master就能避免这类问题了，这个休眠时间一般定义为与Zookeeper定义的超时时间就够了，但是这段
时间内系统不可用了。