在上一篇 CAP理论 中，我提到分布式系统理论上只能取CP或AP，如果要实现强一致性必然会影响可用性。但是，大多数系统实际上不需要那么强的一致性，而是更关注可用性。比如一个3节点的集群，假设每个节点的可用性为 99.9％，那么整个集群的可用性为 99.7％，也就是说，每个月约宕机 129.6 分钟，这对于很多系统是非常严重的问题，所以生产环境，大多数系统都会采用可用性优先的 AP 模型。
在对大规模分布式系统的实践过程中，eBay 的架构师 Dan Pritchett 提出了BASE理论，其核心思想就是：
即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但分布式系统可以采用适合的方式达到最终一致性（Eventual Consitency）。
Base 理论是 CAP 理论中的 AP 的延伸，是对互联网大规模分布式系统的实践总结，强调可用性。BASE 是 基本可用（Basically Available） 、 软状态（Soft-state） 和 最终一致（Eventually Consistent） 三个短语的缩写：
一、基本可用
在BASE理论中，基本可用是说，当分布式系统在出现不可预知的故障时，允许损失部分功能的可用性，保障核心功能的可用性。
具体来说，你可以把基本可用理解成，当系统节点出现大规模故障的时候，比如专线的光纤被挖断、突发流量导致系统过载，这个时候可以通过服务降级，牺牲部分功能的可用性，保障系统的核心功能可用。
1.1 实现方式
实现分布式系统基本可用的手段有很多，常见的有：
- 流量削峰
- 请求排队
- 服务降级
- 服务熔断
所以， 基本可用在本质上是一种妥协，也就是在出现节点故障或系统过载的时候，通过牺牲非核心功能的可用性，保障核心功能的稳定运行 。
二、最终一致
最终一致性是指，分布式系统即使无法做到强一致性，但应当根据自身业务特点，采用适当的方式在一定时限后使各个节点的数据最终能够达到一致的状态。这个时限取决于网络延时，系统负载，数据复制方案设计等等因素。
几乎所有的互联网系统采用的都是最终一致性，只有在实在无法使用最终一致性，才使用强一致性或事务，比如，对于决定系统运行的敏感元数据，需要考虑采用强一致性，对于涉账类的支付系统或清算系统的数据，需要考虑采用事务。
我们可以将CAP理论中的“强一致性”理解为最终一致性的特例，也就是说，你可以把强一致性看作是不存在延迟的一致性。在实践中，你也可以这样思考： 如果业务功能无法容忍一致性的延迟（比如分布式锁对应的数据），就实现强一致性；如果能容忍短暂的一致性延迟（比如 QQ 状态数据），则可以考虑最终一致性。
2.1 实现方式
那么如何实现最终一致性呢？你首先要知道它以什么为准，因为这是实现最终一致性的关键。一般来说，在实际工程实践中有这样几种方式：
- 读时修复： 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，就是向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据；
- 写时修复： 在写入数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Hinted Handoff 实现，具体来说，就是Cassandra 集群的节点之间远程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致性。
- 异步修复： 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。
注意，因为写时修复不需要做数据一致性对比，性能消耗比较低，对系统运行影响也不大，所以许多开源框架都是用这种方式实现最终一致性的。而读时修复和异步修复因为需要做数据的一致性对比，性能消耗比较多，所以需要尽量优化一致性对比的算法，降低性能消耗，避免对系统运行造成影响。
在实现最终一致性的时候，一般要实现自定义写一致性级别（All、Quorum、One、Any）， 比如Elasticsearch在进行索引数据同步时，就支持各种写一致性级别。
三、软状态
软状态，描述的是实现服务可用性的时候系统数据的一种过渡状态，也就是说不同节点间，数据副本存在短暂的不一致。
比如，分布式存储中一般一份数据至少会有N个副本，允许系统在不同节点的数据副本之间进行数据同步的过程中存在延时。mysql replication的异步复制也是一种体现。
这里，我们只需要知道软状态是一种过渡状态就可以了，BASE理论的重点是基本可用以及最终一致性。
四、总结
BASE 理论是对 CAP 中一致性和可用性权衡的结果，它来源于对大规模互联网分布式系统实践的总结，是基于 CAP 定理逐步演化而来的。它的核心思想是： 如果不是必须的话，不推荐实现事务或强一致性，鼓励可用性和性能优先，根据业务的特点，来实现非常弹性的基本可用，以及数据的最终一致性 。
