为什么CAP不能同时满足CA

1、CAP的定义

CAP的基本概念

一致性（Consistence）
可用性（Availability）
分区容错性（Partition Tolerance）

CPA的论文：

第一版：https://robertgreiner.com/cap-theorem-explained/
第二版：https://robertgreiner.com/cap-theorem-revisited/

CAP定理的一个关键性结论：CAP当中的CA是不能同时满足的。

一些CAP的其它细节：
(1)、CAP关注的是粒度是数据，而非整个系统；
(2)、CAP是忽略网络延迟的

2、为什么不能同时满足CA

这是因为在一个分布式系统中，当存在网络分区时，为了保证数据的一致性或可用性，必须在两者之间做出选择。具体来说，CAP理论指出，在一个分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三者不可兼得。其中，一致性指的是在分布式系统中的所有数据备份在同一时刻是否具有同样的值；可用性指的是在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求；分区容错性则是指分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务。

在实际应用中，如果选择保证一致性和可用性（即CA组合），那么在网络分区的情况下，系统可能会面临困境。例如，当两个数据分区分别拥有相同数据的不同版本时，如果修改了一个分区的数据，那么在另一个分区中读取数据时，要么牺牲一致性返回旧版本的数据，要么牺牲可用性等待网络分区恢复后再返回数据。这种情况下，系统无法同时保证一致性和可用性。

因此，根据CAP理论，为了保证系统的稳定性和可靠性，通常需要在一致性和可用性之间做出权衡。例如，一些系统可能优先保证一致性，而在网络分区的情况下牺牲部分可用性；或者优先保证可用性，而在数据不一致的情况下牺牲一致性。这两种情况分别对应于CP（一致性优先）和AP（可用性优先）的组合方式。这两种组合方式是分布式系统中常见的解决方案，但它们都有各自的局限性和权衡‌。

 

3、比较常见的几种CP架构与AP架构

Zookeeper集群：CP架构（master挂掉，选主的过程当中，系统不可用）；
Eureka集群：AP架构
Nacos集群：默认AP架构，也可以支持CP架构。
RocketMQ集群：AP架构
Redis集群：AP架构

 

4、关于CP架构和AP架构的基本论述

在我们的分布式系统当中，我们的业务需求自然是同时需要CAP三样。

对于CP架构而言：我们追求的是尽可能快的补上A，如：Zookeeper没有A的时候，只是Zookeeper集群master挂了，重新选举新的master的时候，才会失去A，一旦选举完成，A就回来了。

对于AP架构而言：我们追求的是尽可能快的补上C，这种玩法就比较多了，先保证高可用，然后再做成最终一致性的设计，通常有这样一些手段，如：

‌‌(1)、阻塞式重试
(2)、2PC、3PC
(3)、异步队列；
(4)、TCC补偿事务；
(5)、本地消息表+异步处理
(6)、事务消息
(7)、结合业务人工补偿

这些方法各有优缺点，选择哪种方法取决于具体的业务需求、系统架构以及可接受的性能和一致性之间的权衡。在工程实践中，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性‌