分布式BASE理论

一、概述

 BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个词语的简写。

二、来源

 CAP 定理表明：对于一个分布式系统而言，它是无法同时满足 Consistency（强一致性）、Availability（可用性）和 Partition tolerance（分区容忍性）这三个条件的，最多只能满足其中两个。而对于互联网来说，由于网络环境是不可信的，所以分区容错性（P）必须满足。
 Base 理论由 eBay 架构师提出，是对 CAP 中一致性和可用性权衡的结果，其来源与对大规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的。

三、核心思想

 即使无法做到强一致性（Strong Consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

四、名词解释

4.1 基本可用

 分布式系统在出现不可预知的故障时，允许损失部分可用性。

• 损失响应时间
   在正常情况下，为了提升响应时间，通常会将商品信息缓存在缓存数据库中，每次获取商品信息时会先到缓存数据库中获取，只有在缓存数据中获取不到时，再到关系型数据库中获取。那么当缓存数据库宕机时， 用户请求的数据仅能在关系型数据库中获取，则势必会造成响应时间上的损失，如下图所示。
  
   CAP 可用性的服务正常响应时间可能是10ms，而基本可用的响应时间是1～2秒，即允许损失部分可用性（时间上的损失）。
• 损失系统功能
   在正常情况下，用户的请求信息会通过“聚合服务”进行路由、分发到对应的具体服务中，但当该具体的服务不能继续提供服务时，则由“聚合服务”进行处理，如下图所示。
   允许在某个服务出现出现故障时，采用服务降级等手段保证用户的体验性，即允许损失部分系统功能。

4.2 软状态

 允许部分节点的数据存在一定的延时，这个延时不影响系统整体的可用性。即不需要完全符合 ACID 的原子性。
 先把订单状态更改成已支付成功，然后告诉用户已经支付成功了。剩下在异步发送 MQ 消息通知积分服务和仓库服务。

硬状态
指必须满足 ACID 的原子性。如下图所示。
只有在订单更改状态、积分发送成功和仓库出单成功，此三者同时成功的情况下，才算支付成功。

4.3 最终一致性

 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。在实际工程实践中，最终一致性存在以下五类主要变种：

• 因果一致性
   如果进程 A 在更新完某个数据项后通知了进程 B，那么进程 B 之后对该数据项的访问都应该能够获取到进程 A 更新后的最新值，并且如果进程 B 要对该数据项进行更新操作的话，务必基于进程 A 更新后的最新值，即不能发生丢失更新情况。与此同时，与进程 A 无因果关系的进程 C 的数据访问则没有这样的限制。
• 读己之所写
   进程 A 更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者而言，其读取到的数据一定不会比自己上次写入的值旧。因此，读己之所写也可以看作是一种特殊的因果一致性。
• 会话一致性
   会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
• 单调读一致性
   如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
• 单调写一致性
   一个系统需要能够保证来自同一个进程的写操作被顺序地执行。

五、小结

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