Nacos一致性协议
Nacos技术架构
先简单介绍下Nacos的技术架构 从而对nacos有一个整体的认识 如图Nacos架构分为四层 用户层、应用层、核心层、各种插件 再深入分析下nacos一致性协议的发展过程及原理实现
为什么nacos需要一致性协议
Nacos是一个需要存储数据的一个组件 为了实现这个目标，就需要在Nacos内部实现数据存储 单机下其实问题不大，简单的内嵌关系型数据库即可 但是集群模式下 就需要考虑如何保障各个节点之间的数据一致性以及数据同步 而要解决这个问题 就不得不引入共识算法 通过算法来保障各个节点之间的数据的一致性
为什么Nacos会在单个集群中同时运行CP协议以及AP协议呢
- 从服务注册来看
服务之间感知对方服务的当前可正常提供服务的实例信息，必须从服务发现注册中心进行获取，因此对于服务注册发现中心组件的可用性，提出了很高的要求，需要在任何场景下，尽最大可能保证服务注册发现能力可以对外提供服务
服务A和服务B往注册中心注册 服务A从注册中心获取服务B的信息 访问服务B 服务B从注册中心获取服务A的信息 访问服务A
如果数据丢失的话，是可以通过心跳机制快速弥补数据丢失
- 对于非持久化数据（即需要客户端上报心跳进行服务实例续约）
不可以使用强一致性共识算法
必须要求集群内超过半数的节点正常 整个集群才可以正常对外提供服务
最终一致共识算法
最终一致共识算法的话，更多保障服务的可用性，并且能够保证在一定的时间内各个节点之间的数据能够达成一致
- 对于持久化数据
强一致性
因为所有的数据都是直接使用调用Nacos服务端直接创建，因此需要由Nacos保障数据在各个节点之间的强一致性，故而针对此类型的服务数据，选择了强一致性共识算法来保障数据的一致性
nacos集群包括3个节点 分别位于不同的网络分区 服务A往节点1上注册 然后持久化到节点1对应的本地存储上 此时要保证节点1对应的持久化数据必须同步到节点2和节点3上
- 从配置管理来看
强一致性
在nacos服务端修改了配置 必须同步到集群中的大部分节点即必须要求集群中的大部分节点是强一致性的
强制一致性算法的选择
Nacos选择了JRaft 是因为JRaft支持多RaftGroup，为Nacos后面的多数据分片带来了可能
最终一致性算法的选择
最终一致性协议算法 例如Gossip和Eureka内的数据同步算法 而Nacos使用的是阿里自研的Distro算法 该算法集中了Gossip和Eureka同步算法的优势
Gossip缺点
对于原生的Gossip，由于随机选取发送消息的节点，也就不可避免的存在消息重复发送给同一节点的情况，增加了网络的传输的压力，也给消息节点带来额外的处理负载
Distro
引入了Server的概念 每个节点负责一部分数据以及将自己的数据同步给其他节点，有效的降低了消息冗余的问题
