标签：存储 zk Zookeeper Nacos 对比 数据 节点

在项目中使用了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的模式（过半机制），默认非持久化采用内存存储速度更快，而且分片存储，不利点就是某个服务节点挂掉，可能出现部分时间调用失败。因为服务调用本身就是实时的，持久化存储起来应该意义不大，及时变化才是真理。

标签：存储,zk,Zookeeper,Nacos,对比,数据,节点
来源： https://blog.csdn.net/CodeBlues/article/details/121566129

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。