一、CAP理论
在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
1、CP架构
如下图，当node1发生异常时，node1的i的值为1，而因为node1发生了异常，导致node1和node2之间的复制通道断开，node2中i的值还为2，为了保证数据一致性，即使node2还是正常的，可以访问的，当client客户端调用node2时，node2还是得返回error。这种情况下，在node1发生异常时(Partition Tolerance)，系统保证了数据一致性（Consistence），而违背了可用性（Availability）。
2、AP架构
如下图，当node1发生异常时，node1的i的值为1，而因为node1发生了异常，导致node1和node2之间的复制通道断开，node2中i的值还为2，为了保证可用性，即使node2未达到一致性，当client客户端调用node2时，node2还是会返回2。这种情况下，在node1发生异常时(Partition Tolerance)，系统保证了可用性（Availability），而违背了数据一致性（Consistence）。注意：这里 N2 节点返回 2，虽然不是一个“正确”的结果，但是一个“合理”的结果，因为2是旧的数据，并不是一个错乱的值，只是不是最新的数据而已。
3、Consul：CP
1. Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。
2. Consul强一致性(C)带来的是：
a. 服务注册会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
b. Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
4、Nacos：AP（默认）+CP
一般来说，如果不需要存储服务级别的信息且服务实例是通过nacos-client注册，并能够保持心跳上报，那么就可以选择AP模。当前主流的服务如Spring cloud和 Dubbo服务，都适用于AP模式。AP模式为了服务的可能性而减弱了一致性，因此AP模式下只支持注册临时实例。
· URL指令：$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP
二、Nacos雪崩保护
1. yml添加`ephemeral`配置，nacos在服务详情设置保护阈值（例如设置0.5）
2. 这样当此服务宕机后，nacos服务列表还会有此服务实例存在（假如有10个此服务的实例）
3. 假设此时有6台挂掉了（6/10<0.5），那么服务列表显示4台健康、6台不健康。
4. 当新的请求来临时，为了防止所有请求都打到那4台健康服务器，导致那4台服务器被压垮，进而出现服务雪崩。
5. 那么nacos会把部分请求也分配到那6台不健康的服务器上，虽然有些请求会出现错误，但是避免了服务雪崩导致的整体业务不可用。
三、Nacos自动注销实例
ephemeral: false #雪崩保护：true:服务实例以"临时"方式注册,当服务实例意外终止不再发送心跳时，Nacos会将该实例自动注销。false:服务实例以"持久"的方式注册,即使服务实例意外终止或不再发送心跳，Nacos也会保持该实例的注册状态，直到显式注销或服务实例被删除