CAP：C（一致性），A（可用性），P（分区容错）

AP

当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。

结论：违背了一致性C的要求，只满足可用性和分区容错，即AP

CP

当网络分区出现后，为了保证一致性，就必须拒绝请求，否则无法保证一致性。

结论：违背了可用性A的要求，只满足一致性和分区容错，即CP

理论

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），但是CAP 原则指示3个要素最多只能同时实现两点，不可能三者兼顾，由于网络硬件肯定会出现延迟丢包等问题，但是在分布式系统中，我们必须保证部分网络通信问题不会导致整个服务器集群瘫痪，另外即使分成了多个区，当网络故障消除的时候，我们依然可以保证数据一致性，所以我们必须保证分区容错性；

至于剩下的一致性和可用性，我们需要二选一，但是鱼和熊掌不可兼得，假设我们选择一致性，那我们就不能让用户访问无法进行数据同步的机器，毕竟该机器上的数据和其他正常机器上的不一致，但是这样我们就丢弃了可用性；假设我们选择可用性，那我们就可以让用户访问无法进行数据同步的服务器，虽然保证了可用性，但是我们无法保证数据一致性。

具体解释如下：

上面的图少了一部分，这里补上：

动画演示：

可以通过分布式系统中实现一致性的raft算法来了解一下，该算法用动画演示了领导选举、日志复制等过程，这些过程保证在分区错误的情况下依然保证整个集群的数据一致性，其中有一个自旋时间决定节点变成选举人，还有一个心跳时间来发送日志，现在来说一下具体过程，假设当前集群初始启动，之后等到一个自旋时间经过之后，所有人都变成了候选人，之后进行投票，票数最高会成为领导，当然可以会经过多轮选举领导人，领导人在自旋心跳时间之后就会给跟随者发送心跳，然后获得他们的心跳，了解他们是否还活着，如果领导挂掉，那么将再次进行选举，知道选出领导人，当然跟随者死了是不会进行选举的，即使之前挂掉的老领导再回来，它也只能当跟随者了，那些活过来的跟随者会从领导者那里复制日志数据，从而保证集群的数据一致性；如果由于网络原因导致多个节点变成了多个区域，比如之前是5个节点，由于网络原因分成了2个区，那么这两个区独自选择领导，当网络恢复之后，网络故障之前的领导将成为新的领导（如果这个另外还是分区领导的话），它将删除自己还没有使用的日志信息，之后从另外一个分区前领导那里复制日志数据，用来保证集群的数据一致性，这些知识点在上面那个网站中都有演示到，最后再说一点领导选举需要大多数人同意，也就是所有节点的一半以上，比如6个要有一个节点得到4个节点的赞同才能成为领导，即使由于网络故障被分区了也是这样，看的是全部的节点，而不是由于网络故障造成的分区节点，所以在网络故障造成的分区中由于一个分区只有2个节点，而全部有6个节点，所以2个节点的不能选出领导，但是那2个节点之前有一个是老领导，那我们使用的还是是老的领导，如果这2个节点之前没有一个节点是领导，那就不会有领导；

以上是分步演示，还有一个网站可以自己去控制过程，它就是raft算法动画演示，我们可以通过该网站来模拟leader宕机后的领导选举、领导如何保存数据等等过程

AP架构

明显AP结构选择了高可用和分区容错性，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。Eureka就是一个AP架构的例子，当Eureka客户端心跳消失的时候，那Eureka服务端就会启动自我保护机制，不会剔除该EurekaClient客户端的服务，依然可以提供需求；

CP结构

CP结构选择的是一致性和分区容错性，如果选择一致性C(Consistency)，为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。最好的例子就是zookeeper，如果客户端心跳消失的时候，zookeeper会很快剔除该服务，之后就无法提供需求；

作者：明快de玄米 链接：https://blog.csdn.net/qq_42449963/article/details/105470515 来源：csdn

补充

理论扩展

CAP理论提出就是针对分布式数据库环境的，所以，P这个属性是必须具备的。

在分布式环境下，为了保证系统可用性，通常都采取了复制的方式，避免一个节点损坏，导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况，而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的，所以，当P发生时，也就是无法向某个节点复制数据时，这时候你有两个选择：

选择可用性 A(Availability)，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。

选择一致性C(Consistency)，为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。

场景

最常见的例子是读写分离，某个节点负责写入数据，然后将数据同步到其它节点，其它节点提供读取的服务，当两个节点出现通信问题时，你就面临着选择A（继续提供服务，但是数据不保证准确），C（用户处于等待状态，一直等到数据同步完成）。