CAP 理论
C：Consistency，一致性。表示无论什么时刻的请求返回得到的数据都是数据库中的最新值。
A：Availability，可用性。指的是系统能保证正常执行请求，不会瘫痪。
P：Partition tolerance，分区容错性。指的是如果某一个分区发生异常瘫痪，仍然可以对前来的请求提供响应数据。
CAP理论就是说明一个分布式系统最多只能同时满足这三个条件中的两个。而对于一个高可用的分布式项目，P 是一定需要实现的，具体方法就是对某个模块设立多个集群节点，使得某一个结点瘫痪后其他结点依然能正常对相应请求进行处理并返回。所以 CAP理论 实际上就是对 C 和 A 的取舍。
如果选择C，那么在某节点瘫痪后，请求会等待该结点恢复并将其之前修改的数据更新到其他节点，以此来保证数据的一致性，但是这样请求就会延时，导致不能及时被处理，失去了可用性。
如果选择A，那么在某节点瘫痪后，请求会直接去另外没有瘫痪的节点处理，并不会等待瘫痪的节点恢复，直接进行处理，此时处理请求的节点数据库中的数据就没有与瘫痪节点的数据库同步，可能导致数据不一致的情况产生，也就是失去了一致性。
绝大多数分布式系统都优先满足AP。因为对于一个网站来说，能使用才是最重要的。
而对于一些数据库来说一致性要比可用性重要，比如 Redis、Mongodb 满足的是 CP。
Base 理论
Base 理论实际是对 CAP 理论中一致性和可用性的一种权衡。其内容主要分为基本可用、软状态、最终一致性。
基本可用：当某个节点发生异常但还可以处理相应请求，那么该节点还是会处理请求，只不过响应的速度会稍慢；或者是请求过多，达到了系统可承受并发量的阀值，那么多出来的请求会被暂缓处理，以此来保证系统的正常可用，那么多出来的请求响应也会延时，但是还是可以被处理，达成了 “基本可用”。
软状态：CAP 理论中对于模块集群的分布式项目，集群的某个节点发生异常，那么新的请求会先不管该节点，直接被其他节点处理，这样故障节点中的数据就不能及时同步到其他节点，其他节点处理的数据就是一种 “中间状态”。这种 “中间状态”就叫做软状态。
最终一致性：虽然在节点故障时无法立刻同步故障节点的数据，但随着时间的推移，该节点被修复正常工作，其数据也会同步到其他节点，最终各节点的数据正常并保持一致。