CAP 理论
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这其中这两项
一致性（Consistency）
指所有节点在同一时间看到的数据完全一致，这里说的就是数据一致性。
其中一致性又可以分为
- 强一致性：CAP 理论中的一致性就是指的强一致性。比如一个主从结构的 MySQL 集群，强一致性则要求对主库的写必须在从库同步完成后才对外部可见，这样所有用户在同一时间点看到的数据就是一致的。
- 弱一致性：数据更新成功后，系统不承诺立即读到最新的值，也不承诺具体多久能读到最新的值
- 最终一致性：弱一致性的一种形式，数据更新成功后可能会存在短暂的不一致，但是在过一段时间后，结点间的数据最终会达到一致性。
可用性（Availability）
可用性是指分布式服务一直处于可用状态，即用户发起的请求总是能够在有限时间内处理并且返回。
在衡量分布式系统的可用性的时候，一般是通过停机时间来计算的。
| 可用性类型 | 可用水平（%） | 年可容忍停机时间 |
|---|---|---|
| 容错可用性 | 99.9999 | < 1 min |
| 极高可用性 | 99.999 | < 5 min |
| 具有故障自动恢复能力的可用性 | 99.99 | < 53 min |
| 高可用性 | 99.9 | < 8.8 h |
| 商品可用性 | 99 | < 43.8h |
分区容错性（Partition Tolerance）
分布式系统在遇到某结点或者网络分区故障的时候，仍然能够正常对外提供服务
CAP 理论证明
假设此时有 N1 和 N2 两台计算机分别部署应用 A 和 B 同时 A 对应的数据库为 D1，B 对应的数据库是 D2，假设如果能同时满足 CAP 特性他们应该是这样的
- 满足一致性：D1 和 D2 数据始终一致
- 满足可用性：不论是请求 N1 服务器还是请求 N2 服务器，都能够正常响应，并且D1 和 D2 数据能够达到一致性
- 满足分区容错性：N1 或者 N2 其中一台服务器不可用了，也能够正常对外提供服务
假设
- 外部请求 N1 和 N2 能否正常响应作为可用性
- N1 和 N2 之间网络环境作为分区容错性
- D1 和 D2 之间的数据是否一样作为一致性
由于在单机的情况数据库是可以保证其自身事务的 ACID 特性的，在分布式环境中主要影响他们的则是网络通信问题这个不确定因数，但是对于分布式服务来说，在部分服务器网络通信出现异常的时候也必须能够正常响应也就是分布式系统必须要满足分区容错性，不满足分区容错性的分布式服务没有意义。
所以我们这里只讨论，在满足分区容错性的前提下是否能够同时满足一致性和可用性这 2 种情况
1、 满足一致性，在这种情况下，必须得保证 D1 和 D2 数据的一致性。那么如果要再满足可用性的话，因为某一台服务器可能不可用了，这样 D1 和 D2 无法数据同步了，这样就和一致性冲突了，必须等待等到不可用的服务器恢复之后才能正常提供服务。
2、 满足可用性，在这种情况下，如果要去满足一致性则无法做到了，因为某一台机器不可用了，数据不可能达到一致性
在此就能看出我们在满足分区容错性的前提下，只能在一致性和可用性中二选一。
这里的二选一中的一致性是指的是强一致性，我们可以退而求其次的选择最终一致性方案。因为最终一致性方案可能会导致中间有一段时间内数据是不一致的，所以具体选用还是要分情况。比如涉及到金钱相关的操作，可以只选择分区容错性和一致性，即出现分区故障的时候优先保证数据的一致性，让服务暂时不可用这样的场景在银行等机构都有使用，我们可以权衡使用。
CAP 权衡
CA without P
保证一致性和可用性舍弃分区容错性。这样的场景几乎不存在，舍弃分区容错性意味着舍弃分布式系统，我们只能想办法去加强基础设施建设区降低网络分区的发生。
CP without A
保证一致性和分区容错性而舍弃可用性。这意味着如果发生网络分区，那么系统会处于不可用状态直到网络分区的恢复。
满足这种性质的其实还是挺多的比如 Zookeeper 它会优先保证 CP，比如金融机构某些核心的金融业务优先保证 CP 系统暂时的不可用也比资金流失好多了。
AP without C
保证可用性和分区容错性舍弃一致性。这里舍弃的是强一致性，某些应用可以退而求其次的选择最终一致性。
强一致性一般是采用 XA 协议来实现的它采用 2 PC 协议 其中可能涉及到长时间的阻塞而导致系统并发性降低吞吐量急剧下降，无法满足高并发下的场景
所以说很多大型应用都是选择的 AP without C 然后保证最终一致性，比如在淘宝商城购买商品发现还有库存，但是下单支付的时候却提示库存不足，比如在 12306 抢票的时候看到还有票结果支付的时候却提示余票不足（相信大家都有过类似体验）这样的情况其实无伤大雅。
BASE 理论
在 CAP 理论中我们讲了，系统无法同时满足 CAP，但是可以退而求其次的选择 AP 然后保证最终一致性
eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）
基本可用（BASE）
基本可用是指允许损失部分可用性，保证核心可用即可。
比如在秒杀场景中，为了应对用户可能出现的激增情况，要保证服务器不会因此出现错误，那么达到服务器承载的上限后，服务器就只能为后续的请求提供降级服务了，将后面一部分用户的请求进行排队或者是引导到降级页面去，这就是损失部分可用性，保证核心可用的一种体现。
软状态（Soft State）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统的整体可用性。分布式存储中一般至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现，mysql replication 的异步复制也是一种体现。
最终一致性（Eventual Consistency）
最终一致性是指系统中的所有数据副本经过一定时间后，最终都能达到一致性的状态，是弱一致性的一种体现
参考：