当前位置:   article > 正文

Nacos和Zookeeper对比

Nacos和Zookeeper对比

主要平时用的较多是配置中心和服务注册中心,所以也是结合这两点功能做出对应的对比,主要比对集群模式。

以下仅仅整理了个人理解后的观点,如有疑问欢迎咨询讨论。
1.Zookeeper
其实明白一点Zookeeper的功能主要是它的树形节点来实现的。当有数据变化的时候或者节点过期的时候,会通过事件触发通知对应的客户端数据变化了,然后客户端再请求zk获取最新数据,采用push-pull来做数据更新。

ZK最重要的就是它的ZAB(消息广播和崩溃恢复)协议了。
消息广播: 集群中zk在数据更新的时候,通过leader节点将将消息广播给其他follower节点,采用简单的两阶段提交模式,先request->ack->commit,当超过一半的follower节点响应可以提交就更新代码。

崩溃恢复: 当leader挂了,或者超半数follower投票得出leader不可用,那么会重新选举,这段期间zk服务是不可用的。通过最新的 xid来选举出新的leader,选举出来后需要将新的leader中的数据更新给超过半数的follower节点才能对外提供服务。

2.Nacos
Nacos的配置中心和注册中心实现的是两套代码,和Zk不同,

1.配置中心
Nacos和Zookeeper都可以作为配置中心,做一些可以实时变化的配置数据存储,然后实时更新线上数据。

1.1 存储和数据更新
Nacos:依赖Mysql数据库做数据存储,当有数据更新的时候,直接更新数据库的数据,然后将数据更新的信息异步广播给Nacos集群中所有服务节点数据变更,在由Nacos服务节点更新本地缓存,然后将通知客户端节点数据变化。

Zookeeper:利用zk的树型结构做数据存储,当有数据更新的时候使用过半机制保证各个节点的数据一致性;然后通过zk的事件机制通知客户端。

这里可以明显发现差异:

服务器存储位置不同,分别采用mysql和zk本身存储
消息发送,一个有采用过半机制保持一致性,另外一个异步广播,通过后台线程重试保证。
2.注册中心
Nacos:nacos支持两种方式的注册中心,持久化和非持久化存储服务信息。

非持久直接存储在nacos服务节点的内存中,并且服务节点间采用去中心化的思想,服务节点采用hash分片存储注册信息
持久化使用Raft协议选举master节点,同样采用过半机制将数据存储在leader节点上
Zookeeper:利用zk的树型结构做数据存储,服务注册和消费信息直接存储在zk树形节点上,集群下同样采用过半机制保证服务节点间一致性

这里的差异:

nacos支持持久化和非持久化存储即有点 AP和CP 分布式一致性的概念,nacos的CP-持久化更像贴合zk的模式(过半机制),默认非持久化采用内存存储速度更快,而且分片存储,不利点就是某个服务节点挂掉,可能出现部分时间调用失败。因为服务调用本身就是实时的,持久化存储起来应该意义不大,及时变化才是真理。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/天景科技苑/article/detail/975085
推荐阅读
相关标签
  

闽ICP备14008679号