闲聊CAP、BASE与XA

CAP理论与BASE理论

首先要和大家说的就是大名鼎鼎的CAP理论与BASE理论了，这两个理论与解决分布式事务问题是密切相关的。

其实网上有很多关于CAP与BASE相关的文章，一写就写了一大堆，篇幅很长，让人看起来头大。王子将以最简短的文字让大家理解它们的含义。

CAP理论

CAP，就是Consistency、Availability、Partition Tolerence的简称，简单来说，就是一致性、可用性、分区容忍性。

首先说说一致性，这不就是字面意思吗，保证分布式系统下各个环节的数据是一致的，准确无误的。

再说可用性，同样字面意思理解，保证分布式系统出现异常、宕机情况下依然对用户可用。

最后是分区容错性，这个看起来不太好理解，其实你就把它理解成假如分布式服务器之间出现网络故障，依然可以正常运转就行了。

所以CAP理论我们就介绍完了。

另外要说明的是CAP是不能同时满足的，只能满足CP或者AP。

首先既然是分布式环境，那么就一定涉及到网络问题，所以P是一定要保证的。如果放弃了使用P，而选择CA，那么网络出现问题时，如果各个节点都分别操作一下数据，就很可能出现数据不一致的情况，所以为了保证C，就要禁止多节点同时写入数据，也就是加锁，这就违背了A的可用性要求，因为加锁的时候是不可用的。

BASE理论

那BASE理论又是什么呢？

所谓的BASE，英文是Basicly Available、Soft State、Eventual Consistency，也就是基本可用、软状态、最终一致性。

首先说基本可用，你可以简单理解成在分布式系统中基本保证同时满足CAP理论。

然后是软状态，我们都知道分布式系统是无法同时保证CAP的，为了保证数据的一致性，往往需要一段数据处理时间，这段时间内数据是可能出现不一致的，这段时间就被称为软状态。软状态的表现形式其实我们已经体验过了，比如你给订单支付的时候，会提醒你“正在支付中，请稍后”，这段时间你是不能操作订单的。

最后是最终一致性，也就是说无论中间数据不一致的时间持续多久，最终都会保证数据的一致，这就是最终一致性，就比如消息中间件。

CAP理论与BASE理论是解决分布式事务的基本知识，我们理解到这个程度就可以了。

XA规范与2PC/3PC分布式事务

XA规范

我们先了解一下什么是XA规范。

有个叫做X/Open的组织定义了分布式事务的模型，这个模型中包含了几个角色，分别是AP（Application，应用，说白了就是我们的系统），TM（Transaction Manager，分布式事务管理器），RM（Resource Manager，资源管理器，可以理解成数据库），CRM（Communication Resource Manager，通信资源管理器，可以是消息中间件），他们之间的关系如图10.1所示：

分布式事务说白了就是一个横跨多个数据库的事务，这个事务里，涉及了多个数据库的操作，然后要保证多个数据库中，任何一个操作失败了，其他所有库的操作全部回滚。

而XA就是定义好的那个TM与RM之间的接口规范，XA仅仅是个规范，具体的实现是数据库产商来提供的。

2PC

2PC说白了就是基于XA规范搞的一套分布式事务的理论，意思就是两阶段提交，分别是准备阶段和提交阶段。

（1）准备阶段，简单来说就是TM先发送个prepare消息给各个数据库，让各个库先把分布式事务里要执行的各种操作，先执行好，但不提交，同时返回一个响应消息给TM，如果成功了就发送一个成功的消息，如果失败了就发送一个失败的消息。

（2）提交阶段，主要分为两种情况，一种情况就是TM接收到失败的消息或者超时没有接到消息，TM就认为本次事务出现错误，就会发送给所有RM回滚的消息，并且认为回滚一定会成功；另一种情况就是TM接收到成功的消息，那么就会发送给所有RM提交的消息，并且认为每个RM收到消息后一定会成功执行提交操作。

看到这里，小伙伴们觉得2PC的方案可靠吗？

没错，2PC的方案是不可靠的。

首先，当TM发送prepare消息给RM的时候，会锁定资源，如果其他人要访问这个资源就会进入阻塞状态。

然后如果TM是一个单机的，就,会存在单点故障问题。

那么如果我们把TM做成了双机热备，且支持双机自动切换，那么如果此时TM发送了prepare消息给某个RM，之后就发生故障，进行了备机的切换，此时这个备机是不知道之前的主机做了什么的，就会导致状态信息的丢失。

另外，如果有些数据库接收到了commit消息，有些数据库由于脑裂问题没有接收到消息，那么数据就出现问题了。

3PC

既然我们知道2PC的方案是不可靠的，所以当然要解决了，于是3PC方案诞生了，它就是三阶段提交，过程如下：

（1）TM向RM发送CanCommit消息，然后等待RM返回结果，注意的是此时RM并没有执行事务，其实就是检查了一下网络是否正连通。

（2）如果所有的RM都返回连接正常，那么TM接着向RM发送PreCommit消息，这个阶段就是2PC中的第一个阶段，RM接收消息执行事务但不提交。如果有RM返回连接不正常，那么TM就会发送abort消息给RM，直接终止事务。

（3）如果TM发送了PreCommit消息后，并接收到RM成功的响应，那么就会发送DoCommit给RM，RM收到消息执行提交操作。如果返回了错误的响应或者超时未响应，那么就发送abort消息给RM执行回滚。

简单来讲3PC就是这样，这个时候小伙伴们就会问了，新增了一个阶段到底对2PC有什么改进呢？

这就要说到3PC的PreCommit阶段了，TM发送PreCommit给RM后，各个RM是有自己的超时机制的，如果收到了PreCommit并且返回成功了，一段时间后没有接收到TM发送的DoCommit请求，那么RM会认为TM出现了故障，自动执行提交操作。这样就解决了TM单点故障的问题。

为什么可以这样做呢？这就是因为新增了一个CanCommit确认的阶段。

不过虽然这样做解决了TM的单点故障问题，但实际上还是有缺陷的。

如果TM本来是想要发送abort消息给RM的，但未发送之前就挂掉了，那么RM超时后自动执行提交操作数据不是又出问题了。

所以2PC与3PC本质上都不能保证分布式事务的绝对可靠。

往期文章推荐：

JVM专栏

消息中间件专栏

并发编程专栏