Nacos源码之AP一致性协议实现

CAP介绍

在了解Nacos一致性协议之前先了解一下CAP是什么：

C：一致性

A：可用性

P：分区容错性。针对多节点部署的系统，分区就代表了网络分区，由于网络原因节点之间无法通信进行数据同步。容错指在这种情况下，系统仍然可以对外提供服务。

在分布式系统中，首先需要保证P，然后在C和A之间做权衡：

在满足P的情况下，如果向node1写入一条数据，因为分区产生则数据无法同步给其他节点，此时就需要在C和A直接做出选择。

选择C，则需要保证所有节点数据的一致性，则整个分布式系统对外暂时不可用。

选择A，则会舍弃C，分布性系统仍然可以对外提供服务，但是因为数据没有同步，则通过不同节点查询返回的结果回不一致。

Nacos中的一致性协议

作为一个分布式系统，Nacos 的服务管理和配置管理都支持 AP、CP 协议。相比较而言Zookeeper作为服务发现常用的一种实现方式只支持CP协议。本篇还是以注册中心功能为基础进行介绍。

服务之间感知对方服务可正常提供服务的实例信息，必须从注册中心获取。因此对注册中心的可用性就会有着更高的要求，尽可能保证服务注册功能的可用性。

在Nacos中，注册中心分为非持久化和持久化两种服务：

非持久化对应了AP协议：保障服务的可用性，在一定时间内，各节点数据可以达成一致。

持久化则对应的CP协议：保障了各个节点数据的强一致性。

Nacos中AP协议的具体实现则是Distro 协议，是Nacos自研的一种协议。而CP协议的实现则是Raft协议。具体代码代码实现都在naming.consistency包中。

在Distro 协议的设计下：

Nacos 每个节点是平等的都可以处理写请求，同时把新数据同步到其他节点。

每个节点只负责部分数据，定时发送自己负责数据的校验值到其他节点来保持数据⼀致性。

对于读请求每个节点可以独立处理，及时从本地发出响应。

对于写请求，Nacos中会员前置Filter根据请求中包含的 IP 和 port 信息计算其所属的 Distro 责任节点， 并将该请求转发到所属的 Distro 责任节点上。

Distro协议源码分析

在之前我们已经知道了，Nacos注册中心实现的大体流程，最终的数据存储在ServiceManager类中的双层Map中，之后就会通知客户端，推送最新的