分布式和微服务场景下的CAP理论以及BASE理论

CAP 理论

一致性（Consistency） : 所有节点在同一时刻看到的都是一样的数据，数据保持同步

可用性（Availability）: 每一次读写请求都能收到成功或失败的响应

分区容错性（Partition Tolerance） : 分布式系统中出现任何网络分区的消失丢失或者宕机，仍然能对外提供服务

CAP 不可能都取，只能取其中 2 个的原因如下：

• 如果一致性C是第一需求的话，那么会影响A。比如某个分布式系统有Node1和Node2两个节点，两个节点需要同步数据data，如果某个用户修改了Node1的数据data，为了保持数据一致性，需要将data同步到Node2，在此期间，Node2是不可用的，从而影响了可用性A。
• 如果可用性A是第一需求的话，那么会影响C。比如某个分布式系统有Node1和Node2两个节点，两个节点需要同步数据data，如果某个用户修改了Node1的数据data，为了保持可用性，Node2仍然需要对外提供服务，这就有可能发生Node2还是旧数据而Node1已经是新数据的数据不一致问题C。
• 同时满足一致性C和可用性A，那么分区容错P就很难保证了，也就是会出现单点故障整个系统不可用，这和分布式的初衷就相悖了。

根本原因在于网络通信是不可靠的，单点故障也是会发生的。

BASE 理论

BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

BASE 理论的核心思想

即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。

BASE 理论三要素

Basically Available 基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。

什么叫允许损失部分可用性呢？

• 响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
• 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。

Soft-state 软状态

软状态指允许系统中的数据存在中间状态（违背了CAP 理论中的C强一致性），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

Eventually Consistent 最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

分布式一致性的 3 种级别

1. 强一致性 ：随时随地可以读到系统最新的值。
2. 弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
3. 最终一致性 ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态（未支付-支付中-已支付）。

业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。

实现最终一致性的具体方式

读时修复 : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点 的副本数据不一致，系统就自动修复数据。

写时修复 : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败 就将数据缓存下来，然后定时重传，修复数据的不一致性。

异步修复 : 这个是最常用的方式，通过定时对账，检测副本数据的一致性，并修复。