nacos协议

 一致性协议

Raft的CP⼀致性
Nacos支持集群模式，很显然。 而一旦涉及到集群，就涉及到主从，那么nacos是一种什么样的机制来实现的集群呢？

nacos的集群类似于zookeeper， 它分为leader角色和follower角色， 那么从这个角色的名字可以看出 来，这个集群存在选举的机制。 因为如果自己不具备选举功能，角色的命名可能就是master/slave了， 当然这只是我基于这么多组件的命名的一个猜测。

Raft协议是一种强一致性、去中心化、高可用的分布式协议，它是用来解决分布式一致性问题的，相对于大名鼎鼎的Paxos协议，Raft协议更容易理解，并且在性能、可靠性、可用性方面是不输于Paxos协议的。许多中间件都是利用Raft协议来保证分布式一致性的，例如Redis的sentinel，CP模式的Nacos的leader选举都是通过Raft协议来实现的。因为Nacos的一致性协议是采用的Raft协议。

选举算法
Nacos集群采用raft算法来实现，它是相对zookeeper的选举算法较为简单的一种。 选举算法的核心在 RaftCore 中，包括数据的处理和数据同步

raft算法演示

在Raft中，节点有三种角色：

Leader：负责接收客户端的请求
Candidate：用于选举Leader的一种角色
Follower：负责响应来自Leader或者Candidate的请求
选举分为两个时间点:

服务启动的时候
leader挂了的时候
所有节点启动的时候，都是follower状态。 如果在一段时间内如果没有收到leader的心跳（可能是没有 leader，也可能是leader挂了），那么follower会变成Candidate。然后发起选举，选举之前，会增加 term，这个term和zookeeper中的epoch的道理是一样的。

follower会投自己一票，并且给其他节点发送票据vote，等到其他节点回复

在这个过程中，可能出现几种情况

收到过半的票数通过，则成为leader
被告知其他节点已经成为leader，则自己切换为follower
一段时间内没有收到过半的投票，则重新发起选举
选举的几种情况:

第一种情况，赢得选举之后，leader会给所有节点发送消息，避免其他节点触发新的选举
第二种情况，比如有三个节点A B C。A B同时发起选举，而A的选举消息先到达C，C给A投了一 票，当B的消息到达C时，已经不能满足上面提到的第一个约束，即C不会给B投票，而A和B显然都不会给对方投票。A胜出之后，会给B,C发心跳消息，节点B发现节点A的term不低于自己的term， 知道有已经有Leader了，于是转换成follower。
第三种情况， 没有任何节点获得majority(超过半数的)投票，可能是平票的情况。加入总共有四个节点 （A/B/C/D），Node C、Node D同时成为了candidate，但Node A投了NodeD一票，NodeB投 了Node C一票，这就出现了平票 split vote的情况。这个时候大家都在等啊等，直到超时后重新发 起选举。如果出现平票的情况，那么就延长了系统不可用的时间,因此raft引入了randomized election timeouts来尽量避免平票情况.
更详细原文

Distro的AP一致性

Distro 协议的主要设计思想如下：

•  Nacos 每个节点是平等的都可以处理写请求，同时把新数据同步到其他节点。
•  每个节点只负责部分数据，定时发送自己负责数据的校验值到其他节点来保持数据⼀致性。
•  每个节点独立处理读请求，及时从本地发出响应。 下面几节将分为几个场景进行 Distro 协议工作原理的介绍。

数据初始化

新加入的 Distro 节点会进行全量数据拉取。具体操作是轮询所有的 Distro 节点，通过向其他的机 器发送请求拉取全量数据

​

数据校验

在 Distro 集群启动之后，各台机器之间会定期的发送心跳。心跳信息主要为各个机器上的所有数据 的元信息（之所以使用元信息，是因为需要保证网络中数据传输的量级维持在⼀个较低水平）。这 种数据校验会以心跳的形式进行，即每台机器在固定时间间隔会向其他机器发起⼀次数据校验请求。 

​

⼀旦在数据校验过程中，某台机器发现其他机器上的数据与本地数据不⼀致，则会发起⼀次全量拉 取请求，将数据补齐。 

写操作

对于⼀个已经启动完成的 Distro 集群，在⼀次客户端发起写操作的流程中，当注册非持久化的实例 的写请求打到某台 Nacos 服务器时，Distro 集群处理的流程图如下

​

 整个步骤包括几个部分（图中从上到下顺序）：

• 前置的 Filter 拦截请求，并根据请求中包含的 IP 和 port 信息计算其所属的 Distro 责任节点， 并将该请求转发到所属的 Distro 责任节点上。
• 责任节点上的 Controller 将写请求进行解析。
• Distro 协议定期执行 Sync 任务，将本机所负责的所有的实例信息同步到其他节点上。

读操作

由于每台机器上都存放了全量数据，因此在每⼀次读操作中，Distro 机器会直接从本地拉取数据。 快速响应。

​

 这种机制保证了 Distro 协议可以作为⼀种 AP 协议，对于读操作都进行及时的响应。在网络分区 的情况下，对于所有的读操作也能够正常返回；当网络恢复时，各个 Distro 节点会把各数据分片的 数据进行合并恢复。

Distro 协议是 Nacos 对于临时实例数据开发的⼀致性协议。其数据存储在缓存中，并且会在启动 时进行全量数据同步，并定期进行数据校验。

在 Distro 协议的设计思想下，每个 Distro 节点都可以接收到读写请求。所有的 Distro 协议的请 求场景主要分为三种情况：

• 当该节点接收到属于该节点负责的实例的写请求时，直接写入。
• 当该节点接收到不属于该节点负责的实例的写请求时，将在集群内部路由，转发给对应的节点， 从而完成读写。
• 当该节点接收到任何读请求时，都直接在本机查询并返回（因为所有实例都被同步到了每台机 器上）。