分布式系统调取服务架构图
CAP原则【三选二】
- C：一致性（consistency）:在分布式系统中的所有数据备份，在同一时刻是否是同样的值（等同于所有节点访问同一份最新的数据副本）
- A：可用性（Availability）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
- P：分区容错性（Partition tolerance）：以实际效果而言，分区相当于***对通信的时限要求***。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
BASE原则【CAP的折中】
- BA:：基本可用（Basically Available）
- S：软状态（Soft State）
- E：最终一致性（Evebtual Consistency）
C、A、P三个都要，但不用100%的保证每一个原则 分布式肯定是优先保证P，多数时候是在C和A之间做权衡选择。
常用的分布式系统的权衡：
（1）、MySQL 单机（CA）
（2）、Eureka 集群（AP）：保证可用性作为首要条件。Eureka各个节点都是平等的，几个节点挂了不会影响其它正常的节点工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致）。其中说明了，eureka是不满足强一致性的，但是还是会保证最终一致性。
（3）、zookeeper 集群（CP）：zookeeper在选举leader时，会停止服务，直到选举成功之后才会再次对外提供服务，这个时候就说明了服务不可用，但是在选举成功之后，因为一主多从的结构，zookeeeper在这时还是一个高可用注册中心，只是在优先保证一致性的前提下，zookeeper才会顾及到可用性。
（4）、nacos 集群（AP或CP）：默认使用AP模型，但也支持CP模型。Nacos不只是发现中心，也是配置中心（配置中心一致性是数据库保证的），以后可能也会有更远大的设计目标，需要保证数据的强一致性。
（5）、redis 集群（AP）：AP模型保证了分布式系统的高可用性。AP模型的分布式锁基于Redis来实现，使用于对数据的一致性要求不那么苛刻的场景中，可以保证高可用性。根据redis的存储结构以及原理可以知道redis无法保证主从节点数据的一致性，无法保证在主节点宕机时将所有数据自动同步到从节点中，因此在业务要求保证一致性的场景中，redis的分布式锁会在主节点宕机的情况下丢失锁信息而出现重复上锁的极端情况。
redis分布式锁的最致命的问题就是无法保证数据的一致性，如果一旦主节点宕机，数据没有同步到从节点，会出现再次上锁的问题。如果业务一定需要数据的一致性在高并发的场景下是不建议选择redis锁的实现，可以选择CP模型的Zookeeper或etcd来实现分布式锁。
（6）、RocketMQ 中间件（AP）：自己实现了一个服务治理服务NameServer,它采用了AP模型，原因是它只是个服务治理服务，它的实现相对简陋，应该说相当简洁，所以效率也相当的高。