科普文：微服务之Spring Cloud Alibaba组件Nacos一致性协议Distro+Raft概叙
一、概要
Nacos是阿里开放的一款中间件，它主要提供三种功能：持久化节点注册，非持久化节点注册和配置管理。
二、一致性协议 - AP/CP
Nacos不是纯粹的AP服务，也不是纯粹的CP服务，而是两者同时支持。
这要从服务注册说起，Provider启动时将自身的信息注册至注册中心，如果注册中心是Zookeeper，在注册时可以选择注册临时节点或者永久节点。如果注册中心是Eureka，服务注册只能注册临时节点。
Nacos同时借鉴了两者的模式，如果在Nacos上注册临时节点，那么Nacos就是AP服务，保证高可用。如果Nacos上注册永久节点，那么Nacos就是CP服务，保证数据一致性。
Nacos对这两者区分实现，通过Distro协议来实现AP，通过Raft来实现CP。
2.1 Distro-AP
Distro协议的主要设计思想如下：
Nacos每个节点负责部分的写请求；- 每个节点把负责新增的数据同步到其他节点；
- 每个节点定时发送自己负责数据的校验值到其他节点来保持数据一致性；
- 每个节点独立处理写请求，及时从本地发出响应；
- 新加入的
Distro节点会进行全量数据拉取。
其实和Eureka差不多，多了每个节点独立负责一部分数据这个特性
数据初始化
当新节点加入时，它会轮询所有的Distro节点，只要一个节点正常响应就会拉取全量数据。
数据校验
在Distro集群启动后，各台机器之间会定期发送心跳，心跳信息主要为各个机器上的所有数据的元信息，这种数据校验会以心跳的形式进行，即每台机器在固定的时间间隔会向其他机器发起一次数据校验请求，一旦在数据校验过程中，某台机器发现其他机器上的数据与本地数据不一致，则会发起一次全量拉取请求，将数据补齐。
写操作
当客户端写入注册非持久节点的请求时，Distro集群处理的流程图如下：
Distro会计算当前数据所属的节点，如果当前节点不是处理该数据的节点，那Distro会将其转发至责任节点，再由责任节点对其做请求解析，然后跟随定时Sync任务，将数据同步到其他Distro节点上。
2.2 Raft-CP
科普文：2PC、3PC、Paxos、Raft、ZAB、NWR一致性协议汇总和对比_paxos zab-CSDN博客
科普文：分布式数据一致性协议Paxos-CSDN博客
科普文：分布式一致性算法Paxos原理与推导过程-CSDN博客
科普文：分布式一致性协议和Raft_对分布一致性协议-CSDN博客
Nacos通过Raft来实现CP。
不过Nacos已经准备用JRaft来替换Raft了，相关的特性正在开发中，JRaft的详细可以看这里：JRaft RheaKV 用户指南
三、心跳检测
Nacos的心跳检测比较有特色。常规的心跳检测方式有两种，一种是客户端主动上报，服务端一段时间未收到心跳就会将客户端下线。另一种是服务端主动去调客户端的心跳接口，如果没有得到正常响应或者超时就将客户端下线。
在注册中心的场景中，客户端的数量一定是会远多于服务端的，如果让服务端去主动轮询心跳接口，会给服务端比较大的压力，所以目前的主流选择都是让客户端去主动上报。
但是Nacos对临时节点和永久节点分别做了处理，如果是临时节点，那么就需要临时节点主动上报，如果是永久节点，Nacos可以主动发起TCP端口检查或者是HTTP接口检查，用来做健康检查。
在Nacos的定义中，临时节点都是弹性扩容之后注册的，随着访问量下来，相关服务是会被回收的，而有的永久节点是无法发起健康检查的，例如一些三方服务，只能提供出一个接口用于心跳检查。
四、配置中心原理
客户端启动后，每30秒给Server发送一个心跳包，Server拿到心跳包之后，先对比一下数据版本，如果版本一样说明数据没有变化，这时Server不会立即将该心跳返回，Server会一直拿着这个心跳，此时和客户端保持长连接的状态，直到数据有变化或者持有超过29.5秒，如果客户端感知到数据版本发生变化，就会主动请求Server拉取数据。
阿里出品的中间件都有个特点，不像一个纯粹的中间件，更像是业务锤炼出来的产物，在RocketMQ，Nacos上这种味道特别明显，它总是会考虑非常多的业务场景，在性能与好用性方面做一个取舍，使用阿里中间件的最大感受就是：它也许不是性能最好的，也许不是纯粹的，但是一定是最适合拿来做业务的。