BASE 是基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）三个短语的缩写。
BASE 理论是 CAP 理论中的 AP 的延伸，是对互联网大规模分布式系统的实践总结，强调可用性。几乎所有的互联网后台分布式系统都有 BASE 的支持，这个理论很重要，地位也很高。
即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
一、基本可用
分布式系统在出现故障的时候，保证核心可用，允许损失部分可用性。
1. 流量削峰
以 12306 为例，春运期间，会出现及其海量的请求峰值，可以在不同的时间，出售不同区域的票，削弱请求峰值。比如，在春运期间，深圳出发的火车票 8 点开售，北京出发的火车票 9 点开售。
2. 延迟响应
春运期间，提交购票请求，往往会在队列中排队等待处理，可能几分钟或十几分钟后，系统才开始处理，然后响应处理结果。
在出现超出系统处理能力的突发流量的情况下，会通过牺牲响应时间的可用性，保障核心功能的运行。
3. 体验降级
若果你负责的一个互联网系统，突然出现了网络热点事件，好多用户涌进来，产生了海量的突发流量，系统过载了，大量图片因为网络超时无法显示，那么可以通过降级的方式，用小图片来替代原始图片，通过降低图片的清晰度和大小，提升系统的处理能力。
4. 过载保护
把接收到的请求放在指定的队列中排队处理，如果请求等待时间超时了（假设是 100ms），这个时候直接拒绝超时请求；再比如队列满了之后，就清除队列中一定数量的排队请求，保护系统不过载，实现系统的基本可用。
二、软状态
指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在时延。
三、最终一致性
系统中所有的数据副本在经过一段时间的同步后，最终能达到一个一致的状态。也就是说，在数据一致性上，存在一个短暂的延迟。
ACID 要求强一致性，通常运用在传统的数据库系统上。而 BASE 要求最终一致性，通过牺牲强一致性来达到可用性，通常运用在大型分布式系统中。
在实际的分布式场景中，不同业务单元和组件对一致性的要求是不同的，因此 ACID 和 BASE 往往会结合在一起使用。
具体方式
- 读时修复：在读取数据时，检测数据的不一致，进行修复。
- 写时修复：在写入数据，检测数据的不一致时，进行修复。
- 异步修复：这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。