ZooKeeper 并不适合做注册中心

网友投稿 929 2022-05-29

zookeeper 的 CP 模型不适合注册中心

zookeeper 是一个非常优秀的项目,非常成熟,被大量的团队使用,但对于服务发现来讲,zookeeper 真的是一个错误的方案。

在 CAP 模型中,zookeeper 是 CP,意味着面对网络分区时,为了保持一致性,他是不可用的。

因为 zookeeper 是一个分布式协调系统,如果使用最终一致性(AP)的话,将是一个糟糕的设计,他的核心算法是 Zab,所有设计都是为了一致性。

对于协调系统,这是非常正确的,但是对于服务发现,可用性是第一位的,例如发生了短暂的网络分区时,即使拿到的信息是有瑕疵的、旧的,也好过完全不可用。

zookeeper 为协调服务所做的一致性保障,用在服务发现场景是错误的。

注册中心本质上的功能就是一个查询函数:

ServiceList = F(service-name)

以 service-name 为查询参数,得到对应的可用的服务端点列表 endpoints(ip:port)。

我们假设不同的客户端得到的服务列表数据是不一致的,看看有什么后果。

一个 serviceB 部署了 10 个实例,都注册到了注册中心。

现在有 2 个服务调用者 service1 和 service2,从注册中心获取 serviceB 的服务列表,但取得的数据不一致。

s1 = { ip1,ip2 ... ip9 }s2 = { ip2,ip3 ... ip10 }

这个不一致带来的影响是什么?

就是 serviceB 各个实例的流量不均衡。

ip1 和 ip10 的流量是单份的,ip2-ip9 流量是双份的。

这个不均衡有什么严重影响吗?并没有,完全可以接受,而且,又不会一直这样。

所以,注册中心使用最终一致性模型(AP)完全可以的。

现在我们看一下 CP 带来的不可用的影响。

3个机房部署 5 个 ZK 节点。

现在机房3出现网络分区了,形成了孤岛。

发生网络分区时,各个区都会开始选举 leader,那么节点数少的那个分区将会停止运行,也就是 ZK5 不可用了。

这时,serviceA 就访问不了机房1和机房2的 serviceB 了,而且连自己所在机房的 serviceB 也访问不了了。

不能访问其他机房还可以理解,不能访问自己机房的服务就理解不了了,本机房内部的网络好好的,不能因为你注册中心有问题就不能访问了吧。

因为注册中心为了保障数据一致性而放弃了可用性,导致同机房服务之间无法调用,这个是接受不了的。

所以,注册中心的可用性比数据强一致性更加重要,所以注册中心应该是偏向 AP,而不是 CP。

以上表述的是 zookeeper 的 CP 模型并不适合注册中心的需求场景。

zookeeper 的性能不适合注册中心

在大规模服务集群场景中,zookeeper 的性能也是瓶颈。

zookeeper 所有的写操作都是 leader 处理的,在大规模服务注册写请求时,压力巨大,而且 leader 是单点,无法水平扩展。

还有所有服务于 zookeeper 的长连接也是很重的负担。

zookeeper 对每一个写请求,都会写一个事务日志,同时会定期将内存数据镜像dump到磁盘,保持数据一致性和持久性。

这个动作会降低性能,而且对于注册中心来讲,是不需要的。

小结

ZooKeeper 并不适合做注册中心

从 CP 模型上来讲,zookeeper 并不适合注册中心高可用的需要。

从性能上来讲,zookeeper 也无法满足注册中心大规模且频繁注册写的场景。

你可能会问,zookeeper 既然这么多问题,他咋不改呢?

其实,这并不算是 zookeeper 的问题,是人家本来就不适合做注册中心,非要用他的话,肯定一堆问题。

zookeeper 的特长是做分布式协调服务,例如 kafka、hbase、flink、hadoop 等大项目都在用 zookeeper,用的挺好的,因为是用对了地方。

ZooKeeper 注册

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:svn利用钩子脚本功能实现代码同步到web目录
下一篇:第三章: C语言程序设计初步-语句学习(上)
相关文章