CAP和Base理论理解

 

  分布式事务

 

随着分布式计算的发展，事务在分布式计算领域也得到了广泛的应用。在单机数据库中，我们很容易能够实现一套满足ACID特性的事务处理系统，但在分布式数据库中，数据分散在各台不同的机器上，如何对这些数据进行分布式的事务处理具有非常大的挑战。

 

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上，通常一个分布式事务中会涉及对多个数据源或业务系统的操作。

 

可以设想一个最典型的分布式事务场景：一个跨银行的转账操作涉及调用两个异地的银 行服务，其中一个是本地银行提供的取款服务，另一个则是目标银行提供的存款服务，这两个服务本身是无状态并且相互独立的，共同构成了一个完整的分布式事 物。如果从本地银行取款成功，但是因为某种原因存款服务失败了，那么就必须回滚到取款之前的状态，否则用户可能会发现自己的钱不翼而飞了。

 

从这个例子可以看到，一个分布式事务可以看做是多个分布式的操作序列组成的，例如 上面例子的取款服务和存款服务，通常可以把这一系列分布式的操作序列称为子事务。因此，分布式事务也可以被定义为一种嵌套型的事务，同时也就具有了 ACID事务特性。但由于在分布式事务中，各个子事务的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事务处理系统就显得格外复杂。 

 

 CAP理论

 

 一个经典的分布式系统理论。CAP理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。

 

1、一致性

 

在分布式环境下，一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一直的状态。

 

对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进 行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是老数据（或称为脏数据），这就是典型的分布式数据不一致的情况。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都可以读取到其最新的值，那么 这样的系统就被认为具有强一致性

 

2、可用性

 

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是"有限时间内"和"返回结果"。

 

"有限时间内"是指，对于用户的一个操作请求，系统必须能够在指定的时间内返回对 应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。另外，"有限的时间内"是指系统设计之初就设计好的运行指标，通常不同系统之间有很 大的不同，无论如何，对于用户请求，系统必须存在一个合理的响应时间，否则用户便会对系统感到失望。

 

"返回结果"是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出队请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

 

 3、分区容错性

 

分区容错性约束了一个分布式系统具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

 

网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络） 中，由于一些特殊的原因导致这些子网络出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。 需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特别的网络分区。
 

 

 既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样。

 

 

不同选择说明：

CA放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择

AP放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此

CP放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用

需要明确的一点是，对于一个分布式系统而言，分区容错性是一个最基本的要求。因为 既然是一个分布式系统，那么分布式系统中的组件必然需要被部署到不同的节点，否则也就无所谓分布式系统了，因此必然出现子网络。而对于分布式系统而言，网 络问题又是一个必定会出现的异常情况，因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。因此系统架构师往往需要把精力花在如何根据业务 特点在C（一致性）和A（可用性）之间寻求平衡。

 

 

BASE理论

 

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。接下来看一下BASE中的三要素：

 

1、基本可用

 

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，即保证核心可用。注意，这绝不等价于系统不可用。比如：

 

（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

 

（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

 

2、软状态

 

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

 

3、最终一致性

 

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

 

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

 

 CAP

CAP是一致性(Consistency)，可用性(Availability)，分区容错性(Partition tolerance)的缩写。在分布式系统设计中，任何一个系统都不可能同时满足这三个特性，只能满足其中2个特性。既然是分布式系统，所以分区容错性是必须要有的，所以在实际设计过程中，更多的是在一致性和可用性之间寻找平衡。

CAP三个特性的具体含义如下： 

2.1. 一致性：这里说的一致性是指强一致性。分布式系统中，数据都是以多副本的形式存储在不同的节点中，要任何时刻数据副本之间的状态保持一致性。即一个进程对一个节点中的数据进行了更新后，同时其他节点中的数据副本实时也进行了更新。另一个进程读取其他节点的数据是最新版本。 

2.2. 可用性：是指在任何时刻系统提供的服务都是可用的。用户或者客户端发送一个请求，服务总是在规定的时间内返回请求结果。在规定的时间内，没有返回请求结果，则认为服务不可用。 

2.3. 分区容错性：系统在任何时刻发生网络故障，系统宕机，整个系统仍然能够对外提供可用性服务和一致性服务。这也说明了，在分布式系统设计过程中，更多的是考虑可用性和一致性平衡。

 

BASE理论

BASE理论是ebay架构师提出的。主要是指基本可用(Basically Available),软状态(soft state)和最终一致性(Eventually consistent)三个词的缩写。核心思想是即使无法做到强一致性，但是每个应用都可以根据自身业务特点，采用合适的方式达到最终一致性。

Base理论是依据大型的分布式系统架构设计设计经验得来，是一致性和可用性平衡结果。同时，也可以反映出在分布式系统设计中，主要考虑到PA两个特性，最终实现数据一致性。

BASE理论三个要素： 

3.1. 基本可用：基本可用是指允许发生不可预知的故障，但是服务对外照常可用。只是损失部分可用性。 

3.2. 弱状态 ：数据副本在整个服务运行期间，允许在某一个时刻(比如，数据复制)允许存在中间状态，但是最终数据的状态保持一致。在处于弱状态时，整个服务可用。 

3.3 最终一致性：在经过一定的时间后，所有数据副本的状态都已经保持一致。一致性的本质就是要保证数据最终一致性。