BASE理论

BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。
BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
可以说基本上都是针对CAP中一些问题的一些容错或者弱化。

下面就根据个人的理解进行简单分析解释。

BASE 不是base这个单词的含义。

BASE中 ：

• BA 是 Basically Available (基本可用)

  基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。
  可以理解为在一个平台中，假设部分出现故障，这个时候系统应该在允许这些故障出现的情况下依旧保持部分功能（应该是核心功能）可以正常使用，另一部分功能出现些许可以允许的问题。
  比如，当出现故障的时候可以允许部分呢功能出现延时，或者跳转不顺畅的情况出现。但不是直接出现错误或者异常。
  个人感觉像是再说一种弱可用性，可用，但是不要求必须所有都可用，是一种对可用性要求的妥协。允许一些特殊情况下，系统出现一小部分可容忍的问题。

• S 是Soft state（软状态）
  软状态，允许部分节点的数据存在一定的延时，这个延时不影响可用性。
  举个例子，就是一个集群中，需要保持所有节点的数据时时刻刻都一致，这是一种强一致性的要求，这个很有可能会造成可用性的问题。
  软状态就是不强制要求在同一个时刻所有节点数据都是一致的，但是也不能说延时延到系统都不能使用了。在保证了可用性的的前提下，允许各个节点在数据的一致性操作的时候有一定的延时。

• E 是Eventually consistent（最终一致性）
  最终一致性很好理解，软状态允许有一定延时，所以这个最终一致含义就是在一定的延时过去之后，所有节点的数据必须保持一致。
  相比的假如在更新的同时，所有节点都必须查询到最新的数据，这样的话是一种 强一致性 。
  在更新的同时，可以容忍节点查询到的数据不是最新的那么是一种 弱一致性。

  最终一致性根据更新数据后各进程访问到数据的时间和方式的不同可以分类为：

  • Causal consistency（因果一致性）
    因果一致性，字面直接理解就是有操作之间有前因后果的要保持一致性。
    假设现在有线程A，线程B，线程C，首先 线程A修改了一条数据，暂且把数据标记为d，在A修改之后并且通知了B线程也就是说这个修改已经可以对B线程可见，那么线程B再在A的基础上修改的时候必须基于A修改的之后的数据进行操作。这是可以很明显看到A 和B存在因果关系，A修改的数据可能直接决定了B最后将要修改的数据。这个时候在AB因果之外的C线程看来，就不需要关心AB之间的一致性，所以一致性其实只需要有前因后果的操作之间保持。

  • Read-your-writes consistency （读己所写一致性）
    读己所写一致性，字面上看，就是读取数据的时候，假如读到的是自己修改之后过的数据那么至少应该读取到自己上一次修改的最新的数据。

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

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

  • Monotonic write consistency （单调写一致性）
    单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。

  小结：
  BASE理论首先对于CAP的一种适应妥协和弱化，为了保证可用性，对一致性作出的一些削弱，所以呢可以说BASE是一种反ACID的理论。

参考：
分布式理论(二)——Base 理论
CAP原理与最终一致性
CAP, BASE, 最终一致性和五分钟原则
CAP原则(CAP定理)、BASE理论