CAP、BASE与XA

本篇文章帮大家学习CAP、BASE与XA,包含了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本质上都不能保证分布式事务的绝对可靠。

 

    

站长公告

极客大全致力于分享java、c#、php、python等编程语言教程,帮助广大程序员解决问题。

热门标签