开发者社区> 摩云飞> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

【转载】对 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 的一些认识,欢迎讨论和指正。 


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
ZooKeeper
在前面的文章中,我已经总结了分布式系统的一般方案和各种一致性算法,接下来就让我们来了解一下分布式系统在工业上的实现ZooKeeper。
45 0
Zookeeper
Zookeeper的特性与节点数据类型及使用场景进行简单介绍
332 0
zookeeper
ZNode ZNode是ZK树形结构的一个节点,它可以包含或者不包含数据。 ZK提供了如下API,用于操作ZNode。 create path data delete path data exists path getdata path putdata path data getChildren pathZK客户端通过建立一个Session会话,来连接ZK服务,通过这些API来操作ZNode。
1774 0
zookeeper
zookeeper主要用于解决分布式环境下的服务协调问题,通常应用场景为: 注册中心: dubbo、motan等 配置中心:disconf 负载均衡:节点值可以为多个服务地址,根据不同负载策略选取服务地址 分布式锁 集群管理工具:根据节点排序用来选举master等 znode zookeeper结构 zookeeper可以理解为一个文件树结构,每一个节点称为一个znode,每个znode上都能存储自己的信息。
1506 0
ZooKeeper简介
ZooKeeper简介 ZooKeeper:分布式应用的协调服务 ZooKeeper是一个分布式的开源协调服务,用于分布式应用程序。它公开了一组简单的原子操作,分布式应用程序可以构建这些原子操作,以实现更高级别的服务,以实现同步,配置维护以及组和命名。
1166 0
一:ZooKeeper简介
一:背景                --->随着互联网技术的高速发展,企业对计算机系统的计算,存储能力要求越来越高,最简单的明证就是出现一些诸如:高并发,海量存储这样的词汇。在这样的背景下,单纯依靠少量高性能主机来完成计算任务已经不能满足企业需求,企业的IT架构逐步从集中式向分布式过渡,所谓的分布式:把一个计算任务分解成若干个计算单元,并且分派到若干不同的计算机中去执行,然后汇总计算结果的过程。
1121 0
Zookeeper简介
zookeeper 是一个分布式协调系统 下载链接:http://mirror.cogentco.com/pub/apache/zookeeper/ 1.zookeeper集群结构 (1) leader 是zk集群的主节点,客户端向zk注册数据时,都要通过leader来对整...
797 0
+关注
摩云飞
十年磨一剑,我还差几年~~
266
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载