nacos与zk对比（浅议）

以下仅仅整理了个人理解后的观点，如有疑问欢迎咨询讨论。
当前因精力有限，仅收集了一些浅显的内容，后续会逐步补充完整。

前言

平时用的主要是配置中心和服务注册中心，所以主要从这两点进行对比。

zk是比较经典的服务注册中心组件。国内早期受Dubbo默认推荐的影响，被认为是RPC服务框架下注册中心的最佳选择。但随着Dubbo的不断更新，及各种注册中心的诞生，已经有逐步丢弃zk的趋势。但毕竟之前的辉煌还未走远，在微服务体系中zk仍有不小的分量。

特性对比

NacosZKEurekaConsulCoreDNS一致性协议AP，可改CPCPAPCP/健康检查TCP/HTTP/MySql/Client BeatClient BeatClient BeatTCP/HTTP/gRPC/cmd/负载均衡权重/DSL/metabase/CMDB/RibbonFabioRR雪崩保护支持不支持支持不支持不支持自动注销实例支持支持支持不支持不支持访问协议HTTP/DNS/UDPTCPHTTPHTTP/DNSDNS监听支持支持支持支持支持不支持多数据中心支持不支持支持支持不支持跨注册中心支持不支持不支持支持不支持SpringCloud集成支持不支持支持支持不支持Dubbo集成支持支持不支持不支持不支持K8S集成支持不支持不支持支持支持

参考原图

nacos

一致性协议

nacos一致性协议为AP，也可以修改配置变CP。
AP重在服务的可用上，即使拿到的数据已过时，也比没有强。

在保障服务可用上，nacos采用类似多级缓存的方式。数据持久化在内存或mysql中，并在服务端用户目录下缓存一组文件，在客户端拉取到之后会在本地用户目录下同样存储一份自己需要的文件。
这样当服务器出现重启后，可以从本地缓存文件中加载之前的信息，并通过心跳健康检测查看哪些客户端还在。
如果客户端启动时服务端无法连接，至少还有本地缓存的信息可以用，不至于使得客户端服务无法启动。

注册中心与配置中心

nacos虽然融注册中心和配置中心为一体，但实际是两套独立代码实现。所以很多时候讲nacos的存储和逻辑时，需要区分来看。这点和zk不同

nacos作为注册中心，数据存储非持久化（Raft协议，选举leader存储，并遵循过半机制），和非持久化（hash分片存在各节点内存中）

nacos作为配置中心，数据存储在mysql中.

zookeeper

zk主要采用push-pull来做数据更新，通过其树形叶子节点来储存信息，当有节点变动时会通过事件触发通知，告诉客户端有变动，然后客户端再向zk获取最新数据。

zk集群一致性方式为CP，即以保证数据一致性为主。
CP的特性，重在数据一致性，要么失败，要么拿到的肯定是最新最全的数据。但在重选主节点时可能耗时30~120秒不等，期间一切访问都是失败的。

集群间数据同步：ZAB

集群各节点数据的同步方式，最主要的就是ZAB（消息广播和崩溃回复）协议。
消息广播：数据更新时，先通过leader节点将消息广播给其它follower节点，采用简单的两阶段提交模式（commit -> ack -> commit），当超过一般follower节点响应，就可以提交更新。
崩溃恢复：当leader挂了或超过半数投票得出leader不可用，就出重新选举，选举期间zk服务不可用，通过最新的xid来选举新的leader（每次拿到最新数据后当前节点xid会加1，可通过xid最大判断是否数据最新），然后将新leader的数据发给超半数的follower节点，zk才可恢复对外服务。

leader选举

。。。

数据特点

支持节点短暂存在，会话创建节点后，每隔一段时间需要发送心跳给zk。如果该服务下线则立即删除节点。同时zk使用了ZAB协议保证了数据的强一致性。

数据同步

持久化使用Raft协议选举master节点，同时采用过半机制将数据存储在leader节点中。
非持久化直接存在nacos运行内存中，且服务节点采用去中心化方式，使用hash分片策略存储注册信息(有点像redis的cluster集群分片)。

一致性协议（CAP）

作为注册中心，P要保证，C和A权衡取其一。

如果选择 一致性 ，必须在某节点写入时，数据同步到其他节点后才算成功。旨在保证无论从哪个节点看到的数据都是一致的。
常见一致性协议有paxos、raft，他们都是强一致性协议（CP）

反之选择 可用性 ，必须保证请求必须及时响应结果，哪怕是过期的数据。与一致性冲突！

Nacos

默认AP（弱一致性协议distro），也可通过修改配置改为CP。

zk

CP

数据储存与集群间同步

nacos分注册中心和配置中心。

nacos的配置中心数据存储在mysql中，当有数据变动时，先存入mysql做持久化，再通过异步广播所有服务节点更新本地缓存后，再通知客户端节点数据变化。

nacos的注册中心有持久化与非持久化两种模式：

• 持久化使用Raft协议选举master节点，同样采用过半机制存储在leader节点。
• 非持久化直接存储在nacos服务节点的内存中，并使用hash分片方式实现去中心化的思想。

zk本身并不区分注册或配置中心

使用类似文件系统目录的树形结构存储，所有数据存储在叶子节点，其数据存储在硬盘上。
当数据变动时，采用过半机制保证各个节点数据的一致性，再通过zk的事件机制通知客户端。

这里有几点差异

1. 数据存储位置不同。nacos存mysql，zk本身存储
2. 数据变动的一致性。nacos先更新数据再发送异步广播，zk采用ZAB协议的过半机制保证数据一致性

？
怎么通知客户端的？顺序和保证机制

配置中心实现

nacos的注册和配置中心的实现是两套代码（虽然只有一个服务）

zk可借助叶子节点数据变动时通知客户端，然后客户端再来获取最新数据的机制，可以实现配置中心的动态配置功能

扩展

CAP理论

CAP理论指出，一个分布式系统不可能同时满足一致性、可用性、分区容错性，鱼和熊掌不可兼得！

• C（Consistency）：一致性。在分布式集群部署中的所有数据备份，在同一时刻是否同样的值
• A（Availability）：可用性。只要收到用户请求，服务器就一定会给出成功或失败响应，不会让用户一直等在那直到超时
• P（Partition tolerance）：分区容错性。由于分布式系统通过网络通讯，但网络是不可靠的。当出现消息丢失或延迟时，程序能正常处理，而不会挂掉或未知异常(未捕获)

本文主要参考下列文章

• 服务注册发现与注册中心对比(NACOS 和 ZK)
• Nacos和Zookeeper对比
• 轻松理解CAP理论

推荐阅读

• [荐] 阿里巴巴为什么不用 ZooKeeper 做服务发现？