1. 简介

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

BASE & CAP 的关系

  之前我们分析过CAP，当一个分布式系统没有发生分区错误时，在逻辑上是完整的时候，我们需要思考如何同时保证 C & A （一致性和可用性），当系统发生分区错误，我们要考虑选择 CP 还是 AP，也就说在容错的同时保证一致性还是可用性，对于绝大多数互联网应用来说，一般都会优先选择 AP，就是发生分区错误时，要保证系统的可用性，而放弃一致性，但这并不意味的完全放弃一致性，当系统从分区错误恢复时，就必须要同时保证 C & A。而 BASE 理论是 CAP 理论中的 AP 的延伸，是对互联网大规模分布式系统的实践总结，强调可用性。因此高可用分布式系统的核心就在于实践 BASE 理论。

Basically Available（基本可用）

  基本可用的意思是说当分布式系统在出现分区错误（就是大规模结点离线或故障），允许损失部分功能的可用性，保障核心功能的可用性。就像弹簧一样，遇到外界的压迫，它不是折断，而是变形伸缩，不断适应外力，实现基本的可用。如何实现基本可用呢，常用的方法有四种：

1. 流量削峰
2. 延迟响应
3. 体验降级
4. 过载保护

Soft-state（软状态）

  软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。比如分布式系统数据会停留某个链路结点上，比如队列一段时间，最后才会进入终点的数据库中，停留在队列中可以看做是一种软状态。

Eventually Consistent（最终一致性）

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

分布式一致性的 3 种级别：

• 强一致性 ：系统写入了什么，读出来的就是什么。每次读取的都是数据记录的最新版本。
• 弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
• 最终一致性 ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。那么如何实现最终一致性呢？你首先要知道它以什么为准，因为这是实现最终一致性的关键。一般来说，在实际工程实践中有这样几种方式：

1. 以最新写入的数据为准，比如 AP 模型的 KV 存储采用的就是这种方式；
2. 以第一次写入的数据为准，如果你不希望存储的数据被更改，可以以它为准。

那实现最终一致性的具体方式是什么呢？常用的有这样几种：

1. 读时修复：在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。
2. 写时修复：在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致性。
3. 异步修复：这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复（更多信息可以参考11 讲的反熵）。在这里，我想强调的是因为写时修复不需要做数据一致性对比，性能消耗比较低，对系统运行影响也不大，所以我推荐你在实现最终一致性时优先实现这种方式。而读时修复和异步修复因为需要做数据的一致性对比，性能消耗比较多，在开发实际系统时，你要尽量优化一致性对比的算法，降低性能消耗，避免对系统运行造成影响。