Nacos注册中心CP架构Raft源码分析

@toc[]

一、CAP介绍

二、Nacos如何设置CP、AP模式

我们使用nacos的时候，有一个关于节点类型的配置：

cloud:
    nacos:
      discovery:
        server-addr: 192.168.131.172:8848
        ephemeral: true

• ephemeral：true：临时节点，写在内存中，效率较高，这种是AP架构；
• ephemeral：false：持久化节点，会写在文件中（不会写到mysql中，mysql是为了存储配置信息的，和注册没关系），同时在内存中同步一份，这种是CP架构。

不同的模块，可以使用不同的架构，Nacos支持混合架构。

作为注册中心，我们一般都会使用AP架构，一般都要求性能更高一点。

三、Distro、Raft协议

• Distro：AP架构实现协议;
• Raft：CP架构实现协议，与Zookeeper的ZAB协议类似。

Raft和ZAB都是分布式一致性协议Paxos的简化，两者很类似，主要包括两部分：

1、leader选举（半数以上节点投票同意）
2、集群写入数据同步（两阶段提交，半数以上节点写入成功）

Raft协议演示网址：http://thesecretlivesofdata.com/raft/

四、BASE理论

• BA（Basically Available）：基本可用；
• S（Soft State）：软状态；
• E（Eventual Consistency）：最终一致性。

BASE原则是CAP的折中，C、A、P三个都要，但不用100%的保证每一个原则。分布式系统肯定优先保证P，多数时候在C和A之间做权衡选择。

满足AP的系统在一定程度上也可以说是复合BASE原则的，比如Eureka集群。三个节点挂了两个，系统还是基本能用的（BA）。此时如果有系统来注册了，因为挂了两个节点，这是整个系统的各节点间的数据是不一致的，但是等另外两个节点恢复了，数据会同步过去（E），对于中间暂时的数据不一致状态可以成为软状态（S）。

五、Nacos脑裂问题（与Zookeeper对比）

六、Nacos源码剖析-集群数据一致性(持久化实例CP模式Raft协议实现)

版本：nacos-1.4

七、云Sass平台千万节点部署优化

此时一台Nacos服务中自然无法储存这么多数量的服务实例，因为无法承受如此大的内存。

优化建议：

数据拆分，参考Redis分片。主节点（对应多个从节点）分片，对服务进行hash确定要注册的主节点。

这样每一个小集群放一小块服务实例即可。

八、集群、分布式、微服务概念区分

集群：同一个业务，部署在多个服务器上

分布式：

• 分布式部署：一个业务拆分成多个子业务，每个子业务分别部署在不同的服务器上；
• 分布式存储：存储在一台机器上的数据被拆分成多分存储在不同的机器上（Kafka分区、RecketMQ）;

微服务：就是一种分布式部署架构。