@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/
- 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
此时一台Nacos服务中自然无法储存这么多数量的服务实例，因为无法承受如此大的内存。
优化建议：
数据拆分，参考Redis分片。主节点（对应多个从节点）分片，对服务进行hash确定要注册的主节点。
这样每一个小集群放一小块服务实例即可。
八、集群、分布式、微服务概念区分集群：同一个业务，部署在多个服务器上
分布式：
- 分布式部署：一个业务拆分成多个子业务，每个子业务分别部署在不同的服务器上；
- 分布式存储：存储在一台机器上的数据被拆分成多分存储在不同的机器上（Kafka分区、RecketMQ）;
微服务：就是一种分布式部署架构。
