Zookeeper作用

zookeeper是为了“分布式”而诞生的，我反复在说“分布式”，并不是赶潮流，而是被潮流推着向前。在任何互联网生产应用中，哪怕你的公司规模小，访问量用一台服务器足够应付，仍然不能容忍当服务器故障时，没有备用的服务器可切换，这个称为“防止单点故障”，因为你至少要用两台服务器来防止单点故障，所以你已经在“分布式”的服务环境里。

这种应用场景叫做master/slave，或者我更喜欢称为主/备模式，在这种场景下，我有两台服务器（主和备），任何情况下，只有“主”在工作，“备”是在主出现故障时，接替“主”来提供服务。在zookeeper的支持下，这一过程是这样实现的

ookeeper提供目录和节点的服务，当我的两台服务器启动时，会在zookeeper的指定目录下创建对应自己的临时节点（这个过程称为“注册”），所谓临时节点，是靠心跳（定时向zookeeper服务器发送数据包）维系，当服务器出现故障（无法向zookeeper服务器发送数据包），zookeeper会删除临时节点。服务器向zookeeper注册时，zookeeper会分配序列号，我们认为序列号小的那个，就是“主”，序列号大的那个，就是“备”。

 

当我们的客户端（通常是web server）需要访问“写”服务时，需要连接zookeeper，获得指定目录下的临时节点列表，也就是已经注册的服务器信息，获得序列号小的那台“主”服务器的地址，进行后续的访问操作。以达到“总是访问主服务器”的目的。

 

当“主”服务器发生故障，zookeeper从指定目录下删除对应的临时节点，同时可以通知关心这一变化的所有客户端，高效且迅速的传播这一信息，你想一想，如果不是使用zookeeper，要自己实现这个功能，可没。。。那么简单（不许唱！）

 

我们为了消除单点故障而使用的主/备模式依赖zookeeper，那么zookeeper可不能有单点故障，所以zookeeper在诞生的时候，就是用集群的模式工作，用多台服务器来消除自身的单点故障隐患，怎么样，无可挑剔吧。

 

总结，在多核并行计算模式下，我认定基于消息传递的actor模型（源自erlang）是正确的编程方式，在actor模型下，可以简单实现基于服务层的串行操作，保证“写”操作的完整和一致。使用actor模型，需要用主/备的部署架构来消除单点故障，实现主/备的部署架构，最简单可靠的方法是使用zookeeper。所以我现在的软件架构是这么推导出来的

Zookeeper在Hadoop及hbase中具体作用
Hadoop有NameNode，HBase有HMaster，为什么还需要zookeeper，下面给大家通过例子给大家介绍。
一个Zookeeper的集群中,3个Zookeeper节点.一个leader,两个follower的情况下,停掉leader,然后两个follower选举出一个leader.获取的数据不变.我想Zookeeper能够帮助Hadoop做到:

Hadoop,使用Zookeeper的事件处理确保整个集群只有一个NameNode,存储配置信息等.
HBase,使用Zookeeper的事件处理确保整个集群只有一个HMaster,察觉HRegionServer联机和宕机,存储访问控制列表等.