在前一篇文章中讲到了BASE模式,这种模式可以应用在单库or跨库事务的场景下。事实上BASE模式不仅仅局限于数据库层面,还可以应用于分布式系统,这类分布式系统最典型的例子就是电商平台,它们有以下几个特征:
在这种场景下,2PC(及XA)已经无法满足需求,因为它:
而BASE只解决最后提交的问题,不能解决诸如在上一篇文章中最后提到的如何保证刷卡消费不透支的问题.于是就有人提出了TCC模式(Try、Confirm、Cancel),这一模式在国内因阿里巴巴的推广而广为人知。
在TCC协议里,参与的主体分为两种:
并且有三种动作:Try、Confirm、Cancel。
TCC是Try、Confirm、Cancel的简称,它们分别的职责是:
关于预留资源要多说两句,资源都是有限的,因此预留资源都是有时效的,如果当预留资源迟迟得不到Confirm——我们将这种情况称为timeout——参与方会自行将其Cancel(这里有坑,下面会讲)。也就是说参与方对于资源具有自我管理能力,这样可以避免因发起方的问题导致资源被长期占用。
TCC于BASE相比,增加了业务检查和撤销事务的功能。
同时,TCC将2PC数据库层面的动作提升到了服务层面,不同的是TCC的所有动作都是一个本地事务,每个本地事务都在动作完成后commit到数据库:
以下是TCC的状态图:
下面是流程步骤(你会发现和2PC很像):
从【发起方】的角度来看出现异常要怎么处理:
从【参与方】角度来看看看出现异常怎么处理:
观察一下你就会发现TCC和2PC存在一样的问题:
不过TCC在处理这种情况相比2PC具有一些优势,因为TCC是在服务层面的,当出现这种问题的时候可以很容易通过日志、业务数据排查出来,然后人工介入,而2PC完全是数据库底层的。
TCC对于ACID的保证:
实现TCC需要关注以下几个方面: