不要太迷信zookeeper，来看看它有什么缺点？

Posted 2021-04-13 java版web项目

zookeeper原本不是为高可用性设计的，但很多系统实际上是需要跨机房部署的。出于性价比的考虑我们通常会让多个机房同时工作，而不会搭建N倍的冗余。也就是说单个机房肯定撑不住全流量。由于zookeeper集群只能有一个master，因此一旦机房之间连接出现故障，zookeeper master就只能照顾一个机房，其他机房运行的业务模块由于没有master都只能停掉。于是所有流量集中到有master的那个机房，于是系统crash。

由于zookeeper对于网络隔离的极度敏感，导致zookeeper对于网络的任何风吹草动都会做出激烈反应。这使得zookeeper的‘不可用’时间比较多，我们不能让zookeeper的‘不可用’，变成系统的不可用。

zookeeper的选举过程速度很慢。

这是一个很难从理论分析上看到的弱点，但是你一旦遇到就会痛不欲生。

前面我们已经说过，网络实际上常常是会出现隔离等不完整状态的，而zookeeper对那种情况非常敏感。一旦出现网络隔离，zookeeper就要发起选举流程。

zookeeper的选举流程通常耗时30到120秒，期间zookeeper由于没有master，都是不可用的。

对于网络里面偶尔出现的，比如半秒一秒的网络隔离，zookeeper会由于选举过程，而把不可用时间放大几十倍。

zookeeper的性能是有限的

典型的zookeeper的tps大概是一万多，无法覆盖系统内部每天动辄几十亿次的调用。因此每次请求都去zookeeper获取业务系统master信息是不可能的。

因此zookeeper提供的‘强一致性’实际上是不可用的。如果我们需要强一致性，还需要其他机制来进行保障：比如用自动化脚本把业务系统的old master给kill掉，但是那会有很多陷阱（这里先不展开这个议题，读者可以自己想想会有哪些陷阱）。

zookeeper的权限控制非常薄弱

在大型的复杂系统里面，使用zookeeper必须自己再额外的开发一套权限控制系统，通过那套权限控制系统再访问zookeeper

额外的权限控制系统不但增加了系统复杂性和维护成本，而且降低了系统的总体性能

即使有了zookeeper也很难避免业务系统的数据不一致

前面已经讨论过了，由于zookeeper的性能限制，我们无法让每次系统内部调用都走zookeeper，因此总有某些时刻，业务系统会存在两个master（业务系统client那边缓存的业务系统master信息是定时从zookeeper更新的，因此会有更新不同步的问题）。

如果我们需要人工介入才能保证‘可靠的强一致性’，那么zookeeper的价值就大打折扣。

我们能做什么

我们或者选择人工介入的强一致性，或者选择程序自动化进行的弱一致性。需要进行取舍。

最终一致性甚至未必是程序来做的，有时候人工修正数据反而在灵活、可靠、低成本上有优势。这需要权衡。

不要迷信zookeeper，有时候不妨考虑一下主备数据库。数据库自带权限控制，用起来比zookeeper方便多了。

zookeeper比较有价值的东西也许是内容变化的时候，可以阻塞回调的方式通知所有在线的client实时更新信息，但这个功能用处不大。因为php这样的模块你很难说它是在线还是离线，每次都是新发起的。一旦这个功能无法支持php，就无法覆盖整个系统，那么就无法保证强一致性了。

推荐作品

  ●  

  ●  

  ●  

  ●  

  ●  

  ●  

  ●  

  ●  

  ●  

  ●    

  ●