注册中心核心的功能有哪些
- AP or CP
- 服务注册
- 服务变更通知
当然还有服务心跳，服务健康检查，以及服务发现。本文主要着重讲解 1、2、3 点。
CP 不大适合于 RPC 框架的注册中心
在 RPC 框架中，是允许注册中心不同节点的数据不一致的，因为数据不一致，并不影响 RPC 框架的服务注册和发现。
如果注册中心是 CP。那么注册中心在选举时，则会导致整个注册中心不可用，这是 RPC 框架无法接受的。
Zookeeper
ZK 使用的是 ZAB 分布式一致性协议。该协议有以下特点
- 所有的写请求，必须经过主节点
因为所有的写请求，必须经过主节点。因此主节点宕机，集群写功能将不可用，持续到选举出新的主节点为止，但是读功能正常使用。
从这里可以看出，如果主节点宕机，则会导致整个集群写功能短暂不可用。
- 数据变更请求必须得到多数节点的确认才能返回
1 和 2 特性，意味着 ZAB 实现的是 CP 而非 AP。
Nacos
Nacos 支持 AP、CP 2个模式，这里只描述 AP 模式。
Nacos 的 AP 模式有2个主要特点（当然还有其它, 这里不一一描述）。
- 节点平等
每个节点都可以接收读写请求。其中读会优先从本地节点读取。
- 异步复制
异步将数据复制到其他节点
1 和 2 特性，意味着，Nacos 即使主节点挂掉了，整个集群也能正常工作。
服务注册
Zookeeper
临时节点
ZK 中节点分为：临时节点、持久化节点。临时节点会在会话(Session) 断开或过期后，字段从 ZK Server 中删除。
服务提供者(集成 ZK Client) 启动时，会向注册中心(ZK Server) 注册自身信息。ZK Server 会创建临时节点存放注册信息。同时，ZK Client 会向 ZK Server Watch 自身使用到的 Providers 节点。
树形结构
Zookeeper 将所有的数据都存放在内存中，数据模型是一棵树，以 '/' 开始。每个节点，我们称之为 ZNode。
dubbo 在 ZK 中的数据组织如下。直接用官方的图。
Nacos
随机选择注册的节点
Client 在向 Server 发起注册请求前，会先随机生成一个随机值。然后用该随机值 % 注册中心节点数量，得到实际要请求的地址。
路由转发
每个 Client 都有专属的 Server 提供服务。
接收请求的 Server，会根据 hash(Client 实例信息) % 注册中心节点数量，判断该请求是否属于自己，否则会将请求转发至对应的节点。
处理请求
- 将实例信息存储在内存
ConcurrentHashMap。 - 添加任务至
BlockingQueue里面，该任务用于通过 UDP 将服务变更推送给 Client。 - 延迟
1s同步数据至其他节点。
服务变更通知
Zookeeper
Watch 机制实现服务变更
ZK 服务变更通知核心点，是基于 ZK 的 Watch 机制实现的。
Watch 机制原理如下：
- 主动推送: 当监听的节点发生变更时, ZK 会向监听的客户端主动发送通知
- 一次性: Watch 触发是一次性的。若想继续监听，需要重新 Watch。
- 顺序性: 触发多个 Watch，会按照触发顺序，有序推送。
每个服务都会 Watch 自身服务用到的 Providers 节点。这样 Providers 节点存在变更，ZK Client 就会收到通知。Client 收到通知后，会主动向 ZK Server 拉取数据。
Nacos
UDP 推送
当订阅的服务提供方有变更，Nacos 会将最新数据通过 UDP 推送至客户端。
定时拉取
因为是 UDP 推送，就可能存在数据包丢失情况。因此 Client 会定时向 Server 拉取最新的数据。
参考
更多细节，可以参考一下文章.
