【转载】对 Zookeeper 的一些分析

1. zookeeper 不是为高可用性设计的 
由于要跨机房容灾，很多系统实际上是需要跨机房部署的。出于性价比的考虑我们通常会让多个机房同时工作，而不会搭建 N 倍的冗余。也就是说单个机房肯定撑不住全流量（你能设想谷歌在全球只剩下一个机房在干活吗）。由于 zookeeper 集群只能有一个 master ，因此一旦机房之间连接出现故障，zookeeper master 就只能照顾一个机房，其他机房运行的业务模块由于没有 master 都只能停掉。于是所有流量集中到有 master 的那个机房，于是系统 crash 。 即使是在同一个机房里面，由于网段的不同，在调整机房交换机的时候偶尔也会发生网段隔离的情况。实际上机房每个月基本上都会发生短暂的网络隔离之类的子网段调整。在那个时刻 zookeeper 将处于不可用状态。如果整个业务系统基于 zookeeper（比如要求每个业务请求都先去 zookeeper 获取业务系统的master 地址），则系统的可用性将非常脆弱。 由于 zookeeper 对于网络隔离的极度敏感，导致 zookeeper 对于网络的任何风吹草动都会做出激烈反应。这使得 zookeeper 的‘不可用’时间比较多，我们不能让 zookeeper 的‘不可用’，变成系统的不可用。
2. zookeeper 的选举过程速度很慢 
这是一个很难从理论分析上看到的弱点，但是你一旦遇到就会痛不欲生。 前面我们已经说过，网络实际上常常是会出现隔离等不完整状态的，而 zookeeper 对那种情况非常敏感。一旦出现网络隔离，zookeeper 就要发起选举流程。 zookeeper 的选举流程通常耗时 30 到 120 秒，期间 zookeeper 由于没有 master，都是不可用的。 对于网络里面偶尔出现的，比如半秒一秒的网络隔离，zookeeper 会由于选举过程，而把不可用时间放大几十倍。
3. zookeeper 的性能是有限的 
典型的 zookeeper 的 tps 大概是一万多，无法覆盖系统内部每天动辄几十亿次的调用。因此每次请求都去zookeeper 获取业务系统 master 信息是不可能的。 因此 zookeeper 的 client 必须自己缓存业务系统的 master 地址。 因此 zookeeper 提供的‘强一致性’实际上是不可用的。如果我们需要强一致性，还需要其他机制来进行保障：比如用自动化脚本把业务系统的 old master 给 kill 掉，但是那会有很多陷阱（这里先不展开这个议题，读者可以自己想想会有哪些陷阱）。
4.zookeeper 无法进行有效的权限控制 
zookeeper 的权限控制非常薄弱。 在大型的复杂系统里面，使用 zookeeper 必须自己再额外的开发一套权限控制系统，通过那套权限控制系统再访问 zookeeper 。 额外的权限控制系统不但增加了系统复杂性和维护成本，而且降低了系统的总体性能。
5.即使有了 zookeeper 也很难避免业务系统的数据不一致 
前面已经讨论过了，由于 zookeeper 的性能限制，我们无法让每次系统内部调用都走 zookeeper，因此总有某些时刻，业务系统会存在两个 master（业务系统 client 那边缓存的业务系统 master 信息是定时从zookeeper 更新的，因此会有更新不同步的问题）。 如果要在业务系统 client 的 master 信息不一直的情况下，仍要保持系统的数据一致性，唯一的方法是“先 kill 掉老 master，再在 zookeeper 上更新 master 信息”。但是在是否要 kill current master 这个问题上，程序是无法完全自动决定的（因为网络隔离的时候 zookeeper 已经不可用了，自动脚本没有全局信息，不管怎么做都可能是错的，什么都不做也可能是错的。当网络故障的时候，只有运维人员才有全局信息，程序是无法接电话得知其他机房的情况的）。因此系统无法自动的保障数据一致性，必须要人工介入。而人工介入的典型时间是半个小时以上，我们不能让系统这么长时间不可用。因此我们必须在某个方向上进行妥协，最常见的妥协方式是放弃‘强一致性’，而接受‘最终一致性’。 如果我们需要人工介入才能保证‘可靠的强一致性’，那么 zookeeper 的价值就大打折扣。
6.我们能做什么 
我们或者选择人工介入的强一致性，或者选择程序自动化进行的弱一致性。需要进行取舍。 最终一致性甚至未必是程序来做的，有时候人工修正数据反而在灵活、可靠、低成本上有优势。这需要权衡。 不要迷信 zookeeper，有时候不妨考虑一下主备数据库。数据库自带权限控制，用起来比 zookeeper 方便多了。 zookeeper 比较有价值的东西也许是内容变化的时候，可以阻塞回调的方式通知所有在线的 client 实时更新信息，但这个功能用处不大。因为 php 这样的模块你很难说它是在线还是离线，每次都是新发起的。一旦这个功能无法支持 php，就无法覆盖整个系统，那么就无法保证强一致性了。

PS：以上只是个人对 zookeeper 的一些认识，欢迎讨论和指正。 

原文地址：http://blog.csdn.net/wwwsq/article/details/7644445
Zookeeper Watcher 流程分析(结合源码) ZK提供了分布式数据的发布/订阅功能，一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，能够让多个订阅者同时监听某个主题对象，当这个主题对象自身状态发生变化时，会通知所有的订阅者。在ZK中引入了 Watcher 机制来实现这种分布式的通知功能。
    这篇文章目的主要是为了讲解清楚zookeeper启动过程中启动各类服务，说白了就是启动了线程提供服务，希望通过这个文章的梳理能够让大家对整个zookeeper的线程架构有一个清晰的印象。
笃行杂记之Zookeeper SessionTimeOut分析 近期的一个C++项目里使用了Zookeeper做服务发现，期间遇到了SessionTimeOut问题的困扰，明明通过zookeeper c client设置了超时时间，但无效。 请原谅我一开始对zookeeper不熟悉。
七：zookeeper与paxos的分析 zookeeper是什么官方说辞：Zookeeper 分布式服务框架是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
linux安装zookeeper集群，包括集群启停脚本 #### 三台机器安装zookeeper集群 **注意事项：安装前三台机器一定要保证时钟同步** * 我这里是有3台服务器，分别hostname为node01、node02、node03。 * 三台机器已经配置好了ssh。 * zookeeper使用的是cdh5的zookeeper包，没有使用原生zookeeper项目的包。 * 三台机器已经进行了时钟同步。