zookeeper采用了fast paxos算法，该算法比paxosa算法好的地方是解决了几个proposer交替发出提案，导致没有一个提案被批准的活锁问题。

为什么需要zookeeper？我想有以下几个应用场景：

1. 配置管理

如果我们有很多服务程序需要有一些配置信息，可以保存在zookeeper的对应的znode中。zookeeper保证多个服务器同时对znode里面信息的修改是原子的，要么成功，要么失败，不会有部分结果被提交。

当然也可以用其他的方式来实现，比如NoSQL或者RDBMS集群。有以下几个区别：

a. zookeeper提供了事件机制，当配置被修改后，这些服务程序可以收到通知。这里使用的是Zookeeper的Watcher机制。

b. 另外，如果仅作配置管理，用NoSQL或者RDBMS集群的确有点奢侈，还是zookeeper性价比好。

c. 至于配置文件的方式，不适合分布式管理，就更不好了。

2. 故障通知

你的程序可能依赖某个服务，用EPHERMAL结合Watcher机制，可以监控依赖的服务程序是否活着，从而作出相应的操作。

3. 选举master

很多分布式服务都需要这个功能，包括zookeeper自己。MongoDB自己实现了选举策略，但是如果要让自己编写的程序具备这个功能，可以考虑不开发，学会使用zookeeper帮你做到这点，让自己的程序成为zookeeper的客户端。

这篇博客描述的较细，可进一步参考。