对zookeeper的一些分析
来源:互联网 发布:网络文明志愿者宣言 编辑:程序博客网 时间:2024/05/17 04:13
1.zookeeper不是为高可用性设计的
o 由于要跨机房容灾,很多系统实际上是需要跨机房部署的。出于性价比的考虑我们通常会让多个机房同时工作,而不会搭建N倍的冗余。也就是说单个机房肯定撑不住全流量(你能设想谷歌在全球只剩下一个机房在干活吗)。由于zookeeper集群只能有一个master,因此一旦机房之间连接出现故障,zookeeper master就只能照顾一个机房,其他机房运行的业务模块由于没有master都只能停掉。于是所有流量集中到有master的那个机房,于是系统 crash。
o 即使是在同一个机房里面,由于网段的不同,在调整机房交换机的时候偶尔也会发生网段隔离的情况。实际上机房每个月基本上都会发生短暂的网络隔离之类的子网段调整。在那个时刻zookeeper将处于不可用状态。如果整个业务系统基于zookeeper(比如要求每个业务请求都先去zookeeper获取业务系统的master地址),则系统的可用性将非常脆弱。
o 由于zookeeper对于网络隔离的极度敏感,导致zookeeper对于网络的任何风吹草动都会做出激烈反应。这使得zookeeper的‘不可用’时间比较多,我们不能让zookeeper的‘不可用’,变成系统的不可用。
2.zookeeper的选举过程速度很慢
o 这是一个很难从理论分析上看到的弱点,但是你一旦遇到就会痛不欲生。
o 前面我们已经说过,网络实际上常常是会出现隔离等不完整状态的,而zookeeper对那种情况非常敏感。一旦出现网络隔离,zookeeper就要发起选举流程。
o zookeeper的选举流程通常耗时30到120秒,期间zookeeper由于没有master,都是不可用的。
o 对于网络里面偶尔出现的,比如半秒一秒的网络隔离,zookeeper会由于选举过程,而把不可用时间放大几十倍。
3.zookeeper的性能是有限的
o 典型的zookeeper的tps大概是一万多,无法覆盖系统内部每天动辄几十亿次的调用。因此每次请求都去zookeeper获取业务系统master信息是不可能的。
o 因此zookeeper的client必须自己缓存业务系统的master地址。
o 因此zookeeper提供的‘强一致性’实际上是不可用的。如果我们需要强一致性,还需要其他机制来进行保障:比如用自动化脚本把业务系统的old master给kill掉,但是那会有很多陷阱(这里先不展开这个议题,读者可以自己想想会有哪些陷阱)。
4.zookeeper无法进行有效的权限控制
o zookeeper的权限控制非常薄弱
o 在大型的复杂系统里面,使用zookeeper必须自己再额外的开发一套权限控制系统,通过那套权限控制系统再访问zookeeper
o 额外的权限控制系统不但增加了系统复杂性和维护成本,而且降低了系统的总体性能
5.即使有了zookeeper也很难避免业务系统的数据不一致
o 前面已经讨论过了,由于zookeeper的性能限制,我们无法让每次系统内部调用都走zookeeper,因此总有某些时刻,业务系统会存在两个 master(业务系统client那边缓存的业务系统master信息是定时从zookeeper更新的,因此会有更新不同步的问题)。
o 如果要在业务系统client的master信息不一直的情况下,仍要保持系统的数据一致性,唯一的方法是“先kill掉老master,再在 zookeeper上更新master信息”。但是在是否要kill current master这个问题上,程序是无法完全自动决定的(因为网络隔离的时候zookeeper已经不可用了,自动脚本没有全局信息,不管怎么做都可能是错的,什么都不做也可能是错的。当网络故障的时候,只有运维人员才有全局信息,程序是无法接电话得知其他机房的情况的)。因此系统无法自动的保障数据一致性,必须要人工介入。而人工介入的典型时间是半个小时以上,我们不能让系统这么长时间不可用。因此我们必须在某个方向上进行妥协,最常见的妥协方式是放弃 ‘强一致性’,而接受‘最终一致性’。
o 如果我们需要人工介入才能保证‘可靠的强一致性’,那么zookeeper的价值就大打折扣。
6.我们能做什么
o 我们或者选择人工介入的强一致性,或者选择程序自动化进行的弱一致性。需要进行取舍。
o 最终一致性甚至未必是程序来做的,有时候人工修正数据反而在灵活、可靠、低成本上有优势。这需要权衡。
o 不要迷信zookeeper,有时候不妨考虑一下主备数据库。数据库自带权限控制,用起来比zookeeper方便多了。
o zookeeper 比较有价值的东西也许是内容变化的时候,可以阻塞回调的方式通知所有在线的client实时更新信息,但这个功能用处不大。因为php这样的模块你很难说它是在线还是离线,每次都是新发起的。一旦这个功能无法支持php,就无法覆盖整个系统,那么就无法保证强一致性了。
- 对Zookeeper的一些分析
- 对zookeeper的一些分析
- Zookeeper的一些问题
- zookeeper的一些理解
- 对zookeeper的认识
- 对需求分析的一些理解
- 对做需求分析的一些感受
- 对TRIM SCSI命令的一些分析
- 对java中Map的一些分析
- 对Java异常分析的一些见解
- 对嵌入式行业的一些分析
- 关于zookeeper的一些学习
- dubbo对zookeeper的应用
- 关于对border的一些属性的分析
- 对java的Hash方法的一些分析总结
- 对silverlight未来的一些分析及个人看法
- 对内核高精度timer体系的一些分析
- Android学习札记33:对ActivityGroup源代码的一些分析
- 令人向往的国外生活
- Entity Framework技术系列之2:三种开发模式实现数据访问
- 转载
- 飞鸽协议分析
- PAIP.MYSQL数据库比较VC313.TXT
- 对zookeeper的一些分析
- 网络二<网卡的接收报文>
- Silverlight WCF通信
- 2013年03月13日 工作总结
- 数据库大型应用解决方案总结
- Java网络socket编程详解
- 权限管理之基础设计
- Java-String-阿拉伯数字转换成中文汉字数字
- js 当鼠标移到单元格(tr、td)背景变色 多种解决方案