分布式事务之CAP理论和BASE理论

关键字
分布式事务 CAP BASE
[TOC]

在分布式系统中，有两个重要的理论依据，用来指导系统的建设思路。他们分别是CAP理论和BASE理论。其中CAP理论是一个偏向学术的理论，而BASE理论是基于CAP理论提出的一个更偏向工程实践的理论。

接下来我们讲分别解读一下CAP理论和BASE理论到底说了什么？

CAP理论

一、CAP理论

CAP定理指出，对于一个分布式系统，不可能同时满足以下三个条件：

一致性（Consistency ），就是说访问系统中任何一个节点，都访问的是同一份最新的数据。
可用性（Availability ），每次访问系统，都能够获得可用的数据，但是数据不保证是最新的。
分区容错性（Partition tolerance），尽管节点之间的网络丢弃（或延迟）任意数量的消息，系统仍能继续运行。当网络被分区时，从分区的一个组件中的节点发送到另一个组件中的节点的所有消息都将丢失。

接下来我们讲分别解读三个问题：

为什么一个系统不能同时满足CAP？

什么是AP系统和CP系统？

对定理的一些误解

image.png

假设我们的分布式系统内部出现了网络故障，由于我们需要具备分区容错性，因此此时系统应该正常工作。

此时client向服务器Server1 发送了写请求，S1接收并处理了请求。

如果我们系统要保证一致性，那么我们必须要等到S1将数据同步到S2后，才能够返回给客户端成功状态。但是由于网络故障，S1无法同步到S2，因此此时系统就不可用了。

那如果我们要保证系统的可用性，那么就应该直接返回成功，而无需等待S1同步S2。此时如果客户端再次向S2发送读请求，那么S2服务器此时只能返回旧的数据。这也就意味着我们无法保证系统的数据一致性。

可见，我们无法构建一个同时满足CAP的系统，这就是CAP理论的核心。

由于在分布式系统中，网络错误是不可避免的，因此总是需要具备分区容错性P。因此在存在分区容错性的情况下，我们只能对A和P二选一。

AP（Availability and Partition tolerance）：当可用性高于一致性时，系统将始终处理客户端请求并尝试返回最新可用版本的信息，即使由于网络分区而无法保证它是最新的。

CP（Consistency and Partition tolerance ）：如果选择一致性而不是可用性，则系统将返回错误或超时，如果由于网络分区或故障而无法更新到其他节点，则该系统将返回错误或超时。

在实际中的分布式框架中，我们一般会把如ZK认为是属于CP系统，对于Eureka这类的认为是AP系统。当然这种简单的把系统划分为AP或者CP是具有争议的，因为目前很多系统都会支持不同的运行模式，同时也会通过一些手段去尽可能的提升A&C。

CAP 定理经常被误解为必须始终在三个保证中选择两个。实际上，只有在网络分区或发生故障时，才需要在一致性和可用性之间进行选择。在没有网络分区或网络故障的情况下，可以同时满足可用性和一致性。

BASE理论是EBAY架构师针对现实中大规模分布式系统实践而提出的一个理论，是对CAP理论的一种扩展和延伸。其核心思想是:

即使做不到强一致性（Strong Consistency ，CAP中的一致性），但是可以通过某些手段来达到最终一致性（Eventually Consistency ）。

BASE分别代表着:

BA（Basically Available ）基本可用。指的是在分布式系统出现故障时，允许一部分的能力损失。主要包括两方面：1）响应时间方面，比如系统中的一些机器宕机，导致整个系统处理能力下降，用户响应时间变长。2）部分功能损失，例如用户浏览页面，由于系统负载问题，会降级掉一些非核心功能，保证核心功能可用。
S (Soft State ) 软状态，允许系统存在中间状态，而不影响系统的可用性。例如分布式存储中的主从同步延时就是一种软状态的体现。MySQL集群的主从异步复制也是一种软状态。
E（Eventually Consistency）最终一致性。指的是我们系统在经过一定时间后，最终能够达到整体的一致性，就认为系统是可用的。

目前我们常见的一些高可用的分布式架构，绝大部分是采用了BASE理论的思路。

总结：采用ACID保证 (RDBMS)设计的数据库系统通常选择一致性而不是可用性，而采用BASE保证设计的系统则选择可用性而不是一致性。