BASE 理论的由来
BASE是 Basically Available （基本可用）、Soft state（软状态）和 Eventually consistent （最终一致性）三个短语的简写，是来自 eBay 架构师 Dan Pritchett 在其文章 BASE:An Acid Alternative 中第一次明确提出的。
BASE 是对 CAP 中一致性和可用性权衡的结果，其来源对于大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式使系统达到最终一致性。
BASE 理论介绍
基本可用
基本可用是指分布式系统在出现不可预知故障的情况下，允许损失部分可用性（注意一点，这绝不等价于系统不可用）。以下是“基本可用”的典型例子。
- 响应时间上的损失： 正常情况下，一个在线搜索引擎要在0.5秒内返回给用户相应的查询结果，但是出现故障，查询结果的响应时间增加到了1~2秒或更多。
- 功能上的损失： 正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些大促活动购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。（亦或12306年底售票的场景。🌔）
软状态
软状态也成为若状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延迟。
例如，使用支付宝转账、信用卡还款等功能时，在我们付完款后提示您的订单已受理，在2小时内进行完成订单相关的提示。这时 订单结果 就处于一个中间的状态，也不是成功，也不是不成功。然而这个完成时间可能几秒后就会完成，也可能几十分钟。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证数据的强一致性。
最终一致性是一种特殊的弱一致性，系统能够保证在没有其它更新操作的情况下，数据最终一定能够大道一致的状态，因此所有客户端对系统的数据访问都能够获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟、系统负载和数据复制方案设计等因素。在实际项目工程实践中，最总一致性主要有以下几个类型。
因果一致性
因果一致性（Causal consistency），是指如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对数据项进行更新操作的话，务必基于进程A更新后的值，即不能发生丢失更新的情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。
读已之所写
读已之所写（Read your writes），是指进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者来说，其读取到的数据，一定不会比自己上次写入的值旧。因此，读已之所写可以看作是一种特殊的因果一致性。
会话一致性
会话一致性（Session consistency），它将对系统数据的访问过程框定在一个会话中：系统能保证在同一个有效的会话中实现 “读已之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
单调读一致性
单调读一致性（Monotonic read consistency），是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
单调写一致性
单调写一致性（Monotonic write consistency），是指一个系统需要能够保证来自同一个进程的写操作被顺序地执行。
BASE 结论
总的来说，BASE 理论面向的是大型高可用、可扩展的分布式系统，和传统事务的 ACID 特性是相反的，它完全不同于 ACID 的强一致性模型，而是提出通过牺牲强一致性来获取可用性，并允许数据在一段时间内是不一致的，但最终达到一致性状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求不尽相同，因此在具体的分布式系统架构设计过程中， ACID 特性与 BASE 理论往往又会结合在一起使用。
作者： Zealon
崇尚简单，一切简单自然的事物都是美好的。