文章目录
Nacos一致性协议
为什么需要一致性协议
在集群模式 下，就需要考虑如何保障各个节点之间 的数据一致性 以及数据同步 。要想解决这个问题，就不得不引入共识算法，通过算法来保障各个节点之间的数据的一致性。
Nacos选择了Raft（强一致性）&Distro（最终一致性）
服务发现角度
- 如果服务可以自己上报自己的健康状态，那就是非持久化服务
- 如果服务要依赖naocs-server去探测，那就是持久化服务 ，比如DNS协议场景
对于非持久化服务 ，由于强调服务的可用性而不是数据的即时一致性，采用了最终一致性 共识算法。这种算法可以保证服务的持续可用性，同时确保一定时间内数据在各个节点间达成一致。
非持久化服务 通过给注册中心发送心跳让注册中心确认自己的健康状况，所以注册中心必须是高可用 的，需要能够随时确认非持久化服务的健康状态，所以对于非持久化服务的数据一致性 选择的是最终一致性。
对于持久化服务 ，因为所有的数据都是直接使用调用Nacos服务端直接创建 ，因此需要由Nacos保障数据在各个节点之间的强一致性，故而针对此类型的服务数据，选择了强一致性共识算法来保障数据的一致性。
配置管理角度
配置数据，是直接在 Nacos 服务端进行创建并进行管理的，必须保证大部分的节点都保存了此配置数据才能认为配置被成功保存了，否则就会丢失配置的变更，如果出现这种情况，问题是很严重的，如果是发布重要配置变更出现了丢失变更动作的情况，那多半就要引起严重的现网故障了，因此对于配置数据的管理，是必须要求集群中大部分的节点是强一致的，而这里的话只能使用强一致性共识算法
Nacos自研Distro协议
背景
Distro协议是Nacos社区自研的一种AP分布式协议，是面向临时实例设计的一种分布式协议，其保证了在某些Nacos节点宕机后，整个临时实例处理系统依旧可以正常工作。作为一种有状态的中间件应用的内嵌协议，Distro保证了各个Nacos节点对于海量注册请求的统一协调和存储。
设计思想
Distro协议的主要设计思想：
- Nacos每个节点是平等 的都可以处理写请求，同时把新数据同步到其他节点。
- 每个节点只负责部分数据 ，定时发送自己负责数据的校验值到其他节点来保持数据一致性。
- 每个节点独立处理读请求，及时从本地发出响应
数据初始化
新加入的Distro节点会进行全量数据拉取。具体操作是轮询所有 的Distro节点，通过向其他的机器发送请求拉取全量数据 。
全量拉取操作之后，Nacos的每台机器 上都维护了当前的所有 注册上来的临时实例数据。
数据校验
在Distro集群启动之后，各台机器之间会定期发送心跳 。心跳信息主要为各个机器上的所有数据的元信息 （使用元信息的原因是，需要保证网络中数据传输的量级 维持在一个较低水平）这种数据校验会以心跳的形式进行，即每台机器会在固定时间间隔 向其他机器发起一次数据校验请求。
一旦数据校验过程中，某台机器发现其他机器上的数据与本地数据不一致 ，会发起一次全量拉取请求 ，将数据补齐。
写操作
对于一个已经启动完成的 Distro 集群，在一次客户端发起写操作的流程中，当注册非持久化的实例的写请求打到某台 Nacos 服务器时，Distro 集群处理的流程图如下：
整个步骤包括几个部分（图中从上到下顺序）：
- 前置的 Filter 拦截请求，并根据请求中包含的 IP 和 port 信息计算其所属的 Distro 责任节点 ，并将该请求转发到所属的 Distro 责任节点上。
- 责任节点上的 Controller 将写请求进行解析。
- Distro 协议定期执行 Sync 任务，将本机所负责的所有的实例信息同步到其他节点上。
读操作
由于每台 机器上都存放了全量数据 ，因此在每一次读操作中，Distro 机器会直接从本地拉取数据 。快速响应。
这种机制保证了 Distro 协议可以作为一种 AP 协议，对于读操作都进行及时的响应。在网络分区的情况下，对于所有的读操作也能够正常返回；当网络恢复时，各个 Distro 节点会把各数据分片的数据进行合并恢复。