BASE是Basically Available（基本可⽤）、Soft state（软状态）和Eventually consistent（最终⼀致性）三个短语的简写，BASE是对CAP中⼀致性和可⽤性权衡的结果，其来源于对⼤规模互联⽹系统分布式实践的结论，是基于CAP定理逐步演化⽽来的，其核⼼思想是即使⽆法做到强⼀致性（Strong consistency），但每个应⽤都可以根据⾃⾝的业务特点，采⽤适当的⽅式来使系统达到最终⼀致性（Eventual consistency）。接下来我们着重对BASE中的三要素进⾏详细讲解。

基本可用

基本可⽤是指分布式系统在出现不可预知故障的时候，允许损失部分可⽤性——但请注意，这绝不等价于系统不可⽤，以下两个就是“基本可⽤”的典型例⼦。

响应时间上的损失：

正常情况下，⼀个在线搜索引擎需要0.5秒内返回给⽤户相应的查询结果，但由于出现异常（⽐如系统部分机房发⽣断电或断⽹故障），查询结果的响应时间增加到了1~2秒。

功能上的损失：

正常情况下，在⼀个电⼦商务⽹站上进⾏购物，消费者⼏乎能够顺利地完成每⼀笔订单，但是在⼀些节⽇⼤促购物⾼峰的时候，由于消费者的购物⾏为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到⼀个降级页⾯。

弱状态

也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可⽤性，即允许系统在不同节点的数据副本之间进⾏数据同步的过程存在延时。

最终一致性

最终⼀致性强调的是系统中所有的数据副本，在经过⼀段时间的同步后，最终能够达到⼀个⼀致的状态。因此，最终⼀致性的本质是需要系统保证最终数据能够达到⼀致，⽽不需要实时保证系统数据的强⼀致性。
亚马逊⾸席技术官Werner Vogels在于2008年发表的⼀篇⽂章中对最终⼀致性进⾏了⾮常详细的介绍。他认为最终⼀致性是⼀种特殊的弱⼀致性：系统能够保证在没有其他新的更新操作的情况下，数据最终⼀定能够达到⼀致的状态，因此所有客户端对系统的数据访问都能够胡渠
道最新的值。同时，在没有发⽣故障的前提下，数据达到⼀致状态的时间延迟，取决于⽹络延迟，系统负载和数据复制⽅案设计等因素。
在实际⼯程实践中，最终⼀致性存在以下五类主要变种。

因果⼀致性：

因果⼀致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进⾏更新操作的话，务必基于进程A更新后的最新值，即不能发⽣丢失更新情况。与此同时，与进程A⽆因果关系的进程C的数据访问则没有这样的限制。

读己之所写：

读⼰之所写是指，进程A更新⼀个数据项之后，它⾃⼰总是能够访问到更新过的最新值，⽽不会看到旧值。也就是说，对于单个数据获取者⽽⾔，其读取到的数据⼀定不会⽐⾃⼰上次写⼊的值旧。因此，读⼰之所写也可以看作是⼀种特殊的因果⼀致性。

会话⼀致性：

会话⼀致性将对系统数据的访问过程框定在了⼀个会话当中：系统能保证在同⼀个有效的会话中实现“读⼰之所写”的⼀致性，也就是说，执⾏更新操作之后，客户端能够在同⼀个会话中始终读取到该数据项的最新值。

单调读⼀致性：

单调读⼀致性是指如果⼀个进程从系统中读取出⼀个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

单调写⼀致性：

单调写⼀致性是指，⼀个系统需要能够保证来⾃同⼀个进程的写操作被顺序地执⾏。

以上就是最终⼀致性的五类常见的变种，在时间系统实践中，可以将其中的若⼲个变种互相结合起来，以构建⼀个具有最终⼀致性的分布式系统。事实上，可以将其中的若⼲个变种相互结合起来，以构建⼀个具有最终⼀致性特性的分布式系统。事实上，最终⼀致性并不是只有那些⼤型分布式系统才设计的特性，许多现代的关系型数据库都采⽤了最终⼀致性模型。在现代关系型数据库中，⼤多都会采⽤同步和异步⽅式来实现主备数据复制技术。在同步⽅式中，数据的复制通常是更新事务的⼀部分，因此在事务完成后，主备数据库的数据就会达到⼀致。⽽在异步⽅式中，备库的更新往往存在延时，这取决于事务⽇志在主备数据库之间传输的时间长短，如果传输时间过长或者甚⾄在⽇志传输过程中出现异常导致⽆法及时将事务应⽤到备库上，那么狠显然，从备库中读取的的数据将是旧的，因此就出现了不⼀致的情况。当然，⽆论是采⽤多次重试还是认为数据订正，关系型数据库还是能搞保证最终数据达到⼀致——这就是系统提供最终⼀致性保证的经典案例。

总的来说，BASE理论⾯向的是⼤型⾼可⽤可扩展的分布式系统，和传统事务的ACID特性使相反的，它完全不同于ACID的强⼀致性模型，⽽是提出通过牺牲强⼀致性来获得可⽤性，并允许数据在⼀段时间内是不⼀致的，但最终达到⼀致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据⼀致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往⼜会结合在⼀起使⽤。