跟我扯分布式事务之Try-Confirm-Cancel

事情还得从事务说起。我说事情总是喜欢从字面意义说起。那事务究竟是什么意思呢?得从它的英文说起:Transaction。

事务

这是我找到的transaction的释义。其中有一个解释叫:accomplish,还有一个说:come to a settlement。而且transaction可以拆分成两块,一个是trans,一个是action。trans有跨越之意,action由词根ag-而来,有行动,做事之意。

那Transaction的大致意思就是:完成一件事情。这个事情也许是由多个部分组成,你得把每个部分都完成了,才算这件事情做成了。

现在再回到软件领域中,我们最早接触的事务是数据库事务(也算是“本地事务”),后来又有了分布式事务。

但他们的核心都是去完成一个事情。这个事情可以是一个本地就可以完成的,也可以是需要由多个服务共同来完成的。总之,他们都是为了要完成一件事情。也就是要完成一个business,业务。

事务的进一步细化

事务最开始出现在数据库中,而且还规定了ACID一致性模型。

ACID

Atomicity 原子性

Consistency 一致性

Isolation 隔离性

Durability 持久性

BASE

再后来,出现了分布式系统,人们渐渐发现ACID不再可以hold住一切了。ACID只适合于本地事务,对于分布式系统来说,应该有全新的标准,于是又有人制定了另外一种标准,叫做BASE。

Basic Availability 能用就行了。

Soft-state 持久化写入也没必要一定要写入一致了。

Eventual consistency 最终一致就可以了。

也许是为了和ACID保持阵型一致,BASE并没有叫BSE,而且强行叫BASE。和basic形似,仿佛在告诉世人,差不多就行了,没必要那么严格,毕竟实现了业务需求就够了。

总之,标准是由人来定的,看场景。

现在你大概知道了目前事务是有两种标准的。

几个名词

补偿

相信你总是听到补偿,但补偿这个词并不是我们自己发明的,而是从国外的名词中引入后翻译过来的,compensation。这里我们说的补偿就是指的一个事务中的某个一个操作片段,就是补偿,具体说来可以是一个远程的操作,也可以是一个本地的操作,可以是一个更新操作,也可以是一个取消操作。

长时间事务

长时间事务(long-running transaction),也就是分布式事务。这个说法是相对于本地的ACID事务而言的。之所以人们这么叫,是因为分布式事务涉及到多个服务或系统,不像那种数据库的本地事务一样,瞬间就结束了。分布式事务要耗不特定的更长的时间。今天要讨论的TCC就是long-running transaction。

补偿

现在我们回到前面的“补偿”。前面说补偿可以是一个远程的操作,可以是一个更新操作,也可以是一个取消操作。他是长时间事务中的一个片段。

比如我把500元从某个银行卡账户转入到微信钱包。那么对微信这边的转入接口进行的操作便是一个补偿操作。

看到这里,你可能在想,原来是调用一个远程接口啊。没错,直接去调用现有的远程接口就是一种补偿操作。

除了这种补偿外,还有另外一种补偿方式。那就是TCC,也就是Try-Confirm-Cancel。

补偿方式

直接方式

TCC

那接下来就重点来说TCC。

TCC:Try-Confirm-Cancel

TCC的方式和直接方式其实都是调用服务方提供的接口。但他们有所不同的是,直接方式更加的简单,不用服务提供方再额外提供接口就可以实现业务。

而TCC则需要服务方提供更多更具体的接口,分别有Try接口、Confirm接口和Cancel接口。

TCC相比直接方式的好处就是在有的场景下,TCC让你的分布式事务更加的符合业务体验。

比如买飞机票的例子。我要买机票从布鲁塞尔到多伦多。这是一个事务,可以分为两个部分,从布鲁塞尔到华盛顿的航班和从华盛顿到多伦多的航班。假设这两张机票分别有自己的预订系统。那么此时如果用直接方式来实现补偿的后果就是,我可能买到了一张布鲁塞尔到华盛顿的机票,但却没有买到华盛顿到多伦多的机票,此时我就得急匆匆的又去看看华盛顿到多伦多其他时间段的航班,毕竟买到手的机票退起来还是比较麻烦的。这显然是不友好的。

而此时如果使用TCC的方式,我先分别对布鲁塞尔到华盛顿和华盛顿到多伦多的机票进行Try,也就是仅仅占用一个名额(仅仅是预留)。然后第二阶段的时候,我才真正决定自己要不要最终下单,如果两个都成功Try,那么就最终下单,然后把状态改为CONFIRMED,如果第二张机票没有成功Try,那么依然还有机会去取消第一张机票,把第一张机票改为CANCELED。

上面我们已经对比了直接方式和TCC两种方式。可以发现TCC在特定的场景,比如预订有限资源的购买场景下就非常适合,通过Try来预留资源,然后通过confirm和cancel两个补偿动作来最终决定是否购买。

当然有的场景下,使用直接方式则显得更加的简单,而不需要服务提供方提供额外的接口。比如买股票。股票买就买了,赔就赔了,也不需要TCC如此稳妥的方式,哈哈。

TCC开源实现

TCC开源框架,比较著名的有Atomikos、国内的TCC-transaction。更多框架欢迎补充。

总结

通过上面的梳理,我们首先明确了事务的概念:完成一件事情。然后明白事务中是由多个片段来组成。然后明确了两种事务一致性标准ACID和BASE。然后我们明确了补偿这一概念。补偿有两种方式,直接方式和TCC的方式。且在诸多BASE中,TCC是在特定的预订购买场景下较为适合的处理方式之一。

原文发布于微信公众号 - ImportSource(importsource)

原文发表时间:2018-08-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏张善友的专栏

让应用程序与您形影相随-PortableApps.com

作为一名 IT 专业人员,您可能会经常需要从一台计算机移到另一台计算机。当您这样做时,您可能会希望能拥有一组随时可用的标准应用程序、工具和文档。满足这些需求的一...

22850
来自专栏我思故我在

ABP框架 - N层架构

47580
来自专栏程序人生

再谈 API 的撰写 - 总览

背景 去年我写过一篇文章:撰写合格的 REST API。当时 Juniper 裁掉了我们在德州的一支十多人的团队,那支团队有一半的人手在之前的半年里,主要的工作...

44170
来自专栏Flutter入门到实战

开发工具总结(9)之开源项目的README文档的最全最规范写法

版权声明:本文为博主原创文章,未经博主允许不得转载。https://www.jianshu.com/p/813b70d5b0de

12810
来自专栏我思故我在

ABP框架 - N层架构

17630
来自专栏前沿技墅

超媒体:将客户端服务端分离进行到底

2017 年年末,就职小米的一位前同事送了我一枚 F 码,我用它抢购到一枚小爱音箱。我满怀期待地装上“小爱同学”,希望能够通过她用语音控制所有小米产品。但我失望...

18020
来自专栏云时之间

简单爬虫(一):实现百度音乐下载

现在我们听歌往往会集中在一个平台,但是往往很多歌曲只在一个平台独占,我们听自己几首想听的歌曲往往要在几个平台跳来跳去,正好现在在使用爬虫,在学着解析网页的时候,...

432130
来自专栏阮一峰的网络日志

谈谈MVC模式

1. 如何设计一个程序的结构,这是一门专门的学问,叫做"架构模式"(architectural pattern),属于编程的方法论。 MVC模式就是架构模式的一...

33350
来自专栏FreeBuf

如何通过Python实现自动填写调查问卷

0X00 前言的,我才想起来貌似我也还没做。对于这种无意义的问卷,我是不怎么感冒的,所以我打算使用”特技”来完成,也就是python,顺便重新复习一下pytho...

64050
来自专栏Android机动车

Android模块化开发方案

随着业务的不断发展壮大,移动端所承担的功能也越来越重,特别是代码几易其主之后开始变得杂乱无章,牵一发而动全局的事情时常发生。为了应对团队壮大之后的开发模式,我们...

17720

扫码关注云+社区

领取腾讯云代金券