zookeeper应用场景
- - CSDN博客推荐文章zookeeper采用了fast paxos算法,该算法比paxosa算法好的地方是解决了几个proposer交替发出提案,导致没有一个提案被批准的活锁问题. 为什么需要zookeeper. 如果我们有很多服务程序需要有一些配置信息,可以保存在zookeeper的对应的znode中. zookeeper保证多个服务器同时对znode里面信息的修改是一致的.
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的客户端。
这篇 博客描述的较细,可进一步参考。