分布式CAP理论
CAP定理：指的是在一个分布式系统当中，Consistency（一致性），Availability（可用性），Partition tolerance（分区容错性）三者不可同时获得。 最多可得其二
一、CAP分别是什么
- 一致性（C）
在分布式系统中的所有备份数据，在同一时刻是否有同样的值。（所有节点在同一时间内的数据完全一致，越多节点数据同步越耗时，但是不能达到纳秒级别的同步）
- 可用性（A）
当负载过大，故障发生后，能否快速恢复，集群整体是否还能继续响应客户端的请求。即每个请求都是可以得到响应的，不管请求是成功还是失败。（即服务器数量多，服务器一直可用，正常运行）
- 分区容错性（P）
除了全部整体网络故障，其他故障都不能导致整个系统不可用
分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。分区容忍性，一个节点崩了，并不影响其他节点。（服务器集群中的节点崩溃了几个， 不影响服务）
提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡
二、CAP验证
- CP满足，A不满足
如果不要求A（可用），每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验， 等待所有数据全部一致了之后再让用户访问系统
- CA满足，P不满足
如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的
- AP满足，C不满足
要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
三、注册中心
| | Nacos | Eureka | Consul | Zookeeper |
| :-------------- | :------------------------- | :----- | :---------------- | ---------- |
| 一致性协议 | CP+AP | AP | CP | CP |
| 健康检查 | TCP/HTTP/MYSQL/Client Beat | 心跳 | TCP/HTTP/gRPC/Cmd | Keep Alive |
| 雪崩保护 | 有 | 有 | 无 | 无 |
| 访问协议 | HTTP/DNS | HTTP | HTTP/DNS | TCP |
| SpringCloud集成 | 支持 | 支持 | 支持 | 支持 |
Zookeeper：CP设计，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则无法提供服务，因此可用性没法满足
Eureka：AP原则，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化
选择：
分布式系统中P,肯定要满足，所以只能在CA中二选一
没有最好的选择，最好的选择是根据业务场景来进行架构设计
如果要求一致性，则选择zookeeper/Nacos，如金融行业 CP
如果要求可用性，则Eureka/Nacos，如电商系统 AP
CP ： 适合支付、交易类，要求数据强一致性，宁可业务不可用，也不能出现脏数据
AP: 互联网业务，比如信息流架构，不要求数据强一致，更想要服务可用
四、BASE理论
CAP 中的一致性和可用性进行一个权衡的结果，核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性, 来自 ebay 的架构师提出
Basically Available(基本可用)：假设系统，出现了不可预知的故障，但还是能用, 可能会有性能或者功能上的影响
Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时
Eventually consistent（最终一致性）：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值