分布式事务CAP与BASE简介

一、CAP理论

  CAP理论是由Eric Brewer教授在2000年举⾏的ACM研讨会上提出的⼀个著名猜想：⼀致性（Consistency）、可⽤性（Availability）、分区容错（Partition-tolerance），并且在分布式系统中这三个条件无法被同时满⾜，并且最多只能满⾜其中两个！2003年，MIT的Gilbert和Lynch正式证明了这三者确实是不可兼得的。此后，CAP理论被奉为分布式系统领域中的理论基石。

1、CAP理论内容

• 1、Consistency 数据一致性 (All nodes see the same data at the same time)
  即更新操作成功并返回客户端后，所有的节点在同一时间数据完全一致，一致性的问题在集群中是不可避免的。从服务端来看，是数据更新如何复制到整个系统，以保证数据一致性。这里所说的一致性是强一致性
• 2、Availability 完全可用性 (Reads and writes always succeed)
  即服务能够一直可用，读写操作能正常响应，并且是在正常的时间内进行响应，不会出现访问失败或者访问超市的情况
• 3、Partition Tolerance 分区容错性
  当系统节点间网络中断，系统也要能够对外提供服务。

2、分布式系统能同时满足CAP三个条件吗？答案是：不能！

   当集群中节点间网络中断，集群因网络中断被分为A和B两个分区，如果该集群对外完全可用，但是因为A和B两个集群不能通讯，无法做到数据同步，就无法保障数据一致性，故无法同时满足三个条件。

同时满足CP条件，当分区发生时，为了保证数据一致性，所有的操作将会被阻塞，直到数据一致性结果达到，所有的操作将会被返回超时

同时满足AP条件，当分区发生时，为了保证集群对外完全可用，所有的操作会正常返回，但是数据会不一致

同时满足AC条件，放弃P条件，即该系统无法容忍分区发生，当网络正常，系统正常对外服务，当分区发生，系统无法对外提供服务，所以三个要求无法同时满足，只能同时满足其中两个要求。

3、关于P的理解

   如果我们放弃P选项，即系统无法容忍分区的情况出现，即当分区出现的时候系统无法对外服务，会出现什么情况呢？现实情况下我们面对的是一个不稳定的网络，网络中断、网络丢包、机器容易宕机的情况时有发生，有概率使系统发生分区。如果这些情况发生导致系统不可用，与分布式高可用，高容错的设计理念相悖。所以P选项是必选的，所以3选2就变成了2选一，即Consistency和Availability 选择一个。
   实际上，CAP中的Consistency 数据一致性是强一致性，要求集群中的更新操作像单节点一样，具有原子性，其实在实际运用中可以放宽一致性的要求； Availability （完全可用性）与上述类似，要求读写操作能正常成功响应，并且是在正常的时间内进行响应，但是在实际应用中可以放宽要求。这就延伸出了BASE理论。

二、BASE理论

  BASE理论是CAP理论的一个可用性实现，是对CAP理论中一致性和可用性权衡的结果。该理论是eBay的架构师Dan Pritchett 源于对大规模分布式系统的实践总结，BASE理论是对CAP理论的延伸，其核心思想是即使无法做到强一致性（Strong Consistency ,CAP的一致性就是强一致性），但是应用可以采取合适的方法达到最终一致性（Eventual Consistency）。BASE理论是指 基本可用(Basically Available )、软状态(Soft State )、最终一致性(Eventual Consistency)

基本可用(Basically Available )

基本可用的意义在于，当系统出现真正的故障时，可以提供一些降级的服务，而不是不提供服务。基本服务通常会在两方面有所损失:响应时间和功能
响应时间：处理请求的相应时长会受到影响，会比正常的处理时间长。
比如正常的响应时间是30ms，但是为了保证数据一致性，要做数据同步，所以响应的时间会延长到1s或者3s不等，或者超时；当前端访问后端连接不上时，可以再选取其他节点连接，其间会增加处理时间。
功能:与正常情况下提供的功能不一致，通常是一种降级后的功能，保证用户基本功能或者核心功能可用，其他功能不可用。比如双11当天无法提供退换货的功能

软状态(Soft State )

  CAP中的数据一致性，要求所有的节点在同一时间数据完全一致，这是一种“硬状态”，是完全一致性，但是与之对应的是“软状态”。软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点中的数据副本存在数据延时。
例如 zookeeper集群中只需要保证大部分节点数据一致性就可以。

最终一致性

最终一致性是指在软状态度过一段时间后，保证系统的所有副本最后都达到数据完全一致的状态，这个时间和网络延时、系统负载、数据复制等因素有关。
最终一致性分为以下几种情况，简单介绍如下：
（1）因果一致性（Causal consistency）
当一个节点在完成数据更新后，同步该节点的数据给另外其他节点，则新的节点对该数据的访问和修改都基于同步过来的数据。与此同时,其他还未更新的节点还使用老数据。
（2）顺序一致性
（3）线性一致性