时间：2021年11月06日

作者：小蒋聊技术

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

经过之前的分享，想必大家已经对“两阶段提交”（2PC - Two-Phase-Commit）和“三阶段提交” （3PC-Three-Phase Commit）有了一定得了解。

今天，小蒋将带来分布式事务的另外一种实现“TCC”（Try-Confirm-Cancel），咱们来一起看一下吧。

“TCC”（Try-Confirm-Cancel）

TCC是采用补偿机制的一种分布式事务，也称为“补偿事务”。它的核心思想是，针对每个操作，都要注册一个与其对应的确认和撤销（补偿）操作。

关于TCC这个概念，最早是由Pat Helland于2007年发表的一篇名叫

《Life beyond Distributed Transactions:an Apostate’s Opinion》

的论文提出的。如果与小蒋之前分享的“两阶段提交”的实现方式相比，TCC实际上解决了几个缺点：

  1. 解决了事务管理器（TM）单点的问题，因为TCC是由主业务方发起并完成这个业务活动。所以事务管理器（TM）也变成多点，引入了集群机制。
  2. 同步阻塞问题得到了缓解，TCC引入了超时重试机制，它并不会锁定整个资源，而是将资源转换为业务逻辑形式，颗粒度更小。
  3. 保证了数据一致性，TCC它提供了补偿机制，由业务活动管理器控制一致性。

接下来，咱们来看TCC（Try-Confirm-Cancel）这个名字，它是Try、Confirm、Cancel三个单词的缩写，一个业务的操作要对应的写这三个方法，它分别为三个阶段：

  • Try 阶段主要是对业务系统做检测及资源预留
  • Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段，默认Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
  • Cancel阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

小蒋猜测，估计大家听到这很多人都会觉得晕头转向的，因为小蒋自己当时就这个感受。为了能够让大家清楚的了解TCC，咱们来看TCC的正常流程（见下图）：

再来看，异常流程（见下图）：

※注意了：小蒋在这里要提醒大家，从图中我们可以看到，cancel阶段参与者调用的顺序与try阶段参与者的调用顺序正好相反，即先调用参与者2的cancel，然后调用参与者1的cancel。大家一定要注意这里！

技术的存在，是为了解决实际的业务问题。学技术，小蒋一直就强调，千万不能脱离实际业务场景。咱今天分享的TCC，它实际上是“业务层面”的分布式事务，并不会一直锁定资源，TCC是在 最后实现最终一致性。

TCC通常使用在：

  • 强隔离性，严格一致性要求的业务活动。
  • 要求执行时间短的业务

小蒋，来给大家举个生活中常见的例子，咱一起来看看用TCC是如何解决这类业务问题的。

跨系统，提现到支付宝：

抖音，是最近比较火的一个App，很多朋友在抖音上已经实现了盈利。也就是说，很多朋友都会有这样一个需求：“从抖音平台提现到支付宝平台”。

这个需求：

  1. 这是一个跨平台的业务活动，横跨抖音平台和支付宝两个平台。
  2. 提现（转账）这个业务，需要强隔离，涉及到钱得业务必须要保证安全性和准确性。
  3. 提现业务需要在规定时间内完成。

小蒋来和大家一起看看，TCC如何实现“提现100元到支付宝”这个业务：

抖音个人账户系统(账户表：余额、冻结金额)：

  • try：
  1. try幂等校验
  2. 检查余额是否够100元
  3. 抖音账户表余额-100，冻结金额+100
  • confirm：
  1. confirm幂等校验
  2. 抖音账户冻结金额-100
  • cancel：
  1. cancel幂等校验
  2. 抖音账户表余额+100，冻结金额-100

抖音转账系统：

  • try：
  1. 空
  • confirm：
  1. confirm幂等校验
  2. 调用支付宝打款接口，打款100元（对于商户同一笔订单支付宝接口是支持幂等的）
  • cancel：
  1. 空

从上面这个“提现”例子中我们可以看到，通常会在Try阶段里面冻结金额，在Confirm阶段里面扣款，在Cancel阶段里面解冻金额。这就是一个经典的TCC案例，“提现”的需求就这样实现了。

总结：

我相信，大家通过上面的这个例子，已经能够明白TCC是如何实现分布式事务了。

如果拿“TCC”和“两阶段提交”相比较，“两阶段提交”通常用在跨库的数据库层面上。而“TCC”则用在业务层面的处理上。

也就是说“TCC”，算是“两阶段提交”在业务层面上的一种实现。

另外，“TCC”不存在资源阻塞的问题，因为每个方法都直接进行事务的提交，一旦出现异常则通过Cancel来进行回滚，也就是常说的补偿性事务。

但，可以看到“TCC”对业务的入侵性很强，原本的一个方法，现在却需要三个方法来支持（Try、Confirm、Cancel）。而且这种模式并不能很好的被复用，会导致开发量激增。

另外，必须考虑网络波动等各种原因的产生的失败问题，每个阶段都需要有重试机制，每个接口都需要支持“幂等性”。

以上，是今天“小蒋聊技术”技术部分的全部内容。

服务之间“边界”的重要性

如果你现在是一名工程师，将来想要成为一名架构师。或者你已经是一名架构师了，还想再进一步提升。接下来，小蒋准备为大家分享一些自己工作中的心得和体会。

作为一名架构师，一定要有一个全局观。那么要求你在做事之前，一定先把自己负责的系统优势劣势想明白了，优势要重点加强，劣势要通过合作来弥补，千万不能在劣势上，主动发起攻击，那就是自取灭亡。

想要做到这一点，其实非常不容易。因为，要建立这个全局观，你必须要得能认清“边界”的重要性才行，它包括“系统的边界”、“服务的边界”、“人的边界”等等……。

接下来小蒋来给大家讲一个故事：

在一所学校门口的旁边，有一个收破烂的大哥每天都在那收破烂。在一个雨后的下午，这位大哥在那收拾他的东西，他有一个躺椅，他就躺在他的那个躺椅上喝茶，听戏，享受人生，脸上还露出了满足的笑容。

这个时候，学校来好几辆客车的参观团，参观的游客从客车里走出来以后，把手里喝完的矿泉水瓶都扔进了工作人员预先准备好的大垃圾袋中。工作人员把空矿泉水瓶压扁后，就堆放到了垃圾桶旁边，转身就带着参观团进校参观去了。

接下来，大家来猜猜会发生什么？

这边一个收破烂的大哥，就在不远处垃圾桶那堆着满满的好几大袋空矿泉水瓶子，这简直就是捡钱一样啊！

那么小蒋的猜测是，这个收破烂的大哥走过去，把这满满的好几大袋空矿泉水瓶子直接拽过来，挨个数数，直接就回收变现了。

但是，小蒋的期待的场面，并没有发生。这个捡破烂的大哥，拿眼睛瞄了一眼那装满矿泉水瓶的几个大垃圾袋，纹丝未动，继续喝茶，听戏，享受人生。

紧接着，对面走过来几个出来买菜的老太太。一看垃圾桶旁边，放着好几袋装满矿泉水瓶子的大垃圾袋，最关键的是旁边还有一个收破烂的大哥，哎呦这不都准备好了嘛！

这几个老太太就一起把垃圾袋拽到了这个收破烂大哥这里，把这几袋子的空瓶子给卖了，然后卖的钱就一起平分了。

整个这一系列场景，被学校门口的一个本地看自行车的大哥看到了。这个本地看自行车的大哥过来就对着这个收破烂的大哥说，老弟啊！你到底是懒呢还是傻呀，你自己把它拽过来，自己把这些瓶子收了多好，你能赚好多钱。现在你不去拿，别人拿了过来卖给你，你不光卖不了钱，你还得给别人钱，这一进一出你损失了双倍的钱。

你看，这个本地看车的大哥算机会成本，要乘以2。周围看到这一幕的人，都觉得这个收破烂的大哥有点傻。

但，没有想到的是，躺椅之上这个听戏的收破烂大哥，当着众人的面说了一句特别有境界的话。这个哥们把茶杯一放，笑眯眯的瞅着对面那看自行车的大哥说啊，老兄啊，你不明白。我是收破烂的，不是捡破烂的！

各位朋友们，你看这境界太高了。

这句话，在态度上叫有所为有所不为；在哲学上叫做知道自己是谁；在营销上叫定位清晰；在管理上叫只做产业链的一段。

小蒋想要告诉大家，作为架构师的你，一定要懂得划清“边界”。你架构的系统之所以棒，所有的境界之所以高，都是来之“边界清晰”。你不管干什么事，你不管对谁负责任，请你先划清边界。边界之内我们认认真真，边界之外我们就不操心了。

写在最后

“划清边界”这件事，其实非常容易起冲突，因为你可能会动到别人的蛋糕。争论这种方法，并不是什么好的解决办法。

那么另外，口才这个东西，其实并没有想象的那么好。口才好有什么用，跟别人不停的辩论，赢了客户失去了生意，赢了领导丢了工作，赢了家人，失去了感情，所以不要那么天生好斗。要把握全局，才是真正的高手，作为架构师的你，别为了推自己的方案落地，弄得你死我活，而是要想到能不能让大家共赢。

年龄的增长不可怕，可怕的是从未成长！

感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。

音频版地址：【20211106】在技术上是如何实现分布式事务_V3https://www.ximalaya.com/keji/51588599/470071700

【20211106】在技术上是如何实现分布式事务_V3（TCC）相关推荐

  1. 【20211114】在技术上是如何实现分布式事务_V4（本地消息可靠消息）

    时间:2021年11月14日 作者:小蒋聊技术 大家好,欢迎来到小蒋聊技术.小蒋准备和大家一起聊聊技术的那些事. 如何实现分布式事务这个话题,想必大家已经都不陌生了.小蒋和大家已经聊了3种不同的实现方 ...

  2. 破解世界性技术难题！ GTS让分布式事务简单高效

    近日,2017云栖大会·深圳峰会如期举行,多项阿里云新产品对外发布.在企业级互联网架构分会场,来自阿里中间件(Aliware)的技术专家及合作伙伴,为现场参会嘉宾带来最新的传统IT架构到企业级互联网架 ...

  3. 分布式事务：TCC两阶段异步补偿型

    点击上方"田守枝的技术博客",关注我 提示:可能有人在公众号上看过这篇文章,这是我2018年2月份在我的博客上写的文章,现在搬到公众号上来,搬上来之前已经被其他公众号抄袭了,懒的投 ...

  4. [转]分布式事务之TCC服务设计和实现注意事项

    1.TCC简介 TCC是一种比较成熟的分布式事务解决方案,可用于解决跨库操作的数据一致性问题: TCC是服务化的两阶段编程模型,其Try.Confirm.Cancel 3个方法均由业务编码实现: 其中 ...

  5. 分布式事务模型--TCC

    本文来说下分布式事务模式之TCC,接着上文XA Specification来说 文章目录 概述 TCC TCC 模型将事务的提交划分为两个阶段 举个例子 特点剖析 本文小结 概述 事务是一组不可分组的 ...

  6. 分布式事务之TCC服务设计和实现注意事项！

    来源:云栖社区  |  作者:绍辉  |  原文地址见文末 常见的分布式解决方案有: 最大努力通知型事务 可靠消息一致性事务 TCC事务 一.TCC简介 TCC是一种比较成熟的分布式事务解决方案,可用 ...

  7. java分布式事务——seata,tcc解决方案总结！

    目录 1.分布式事务基础理论 1.1.CAP理论 1.2.BASE理论 2.分布式事务解决方案之2PC(两阶段提交) 2.2.1 XA方案 2.2.2 Seata方案 2.2.3分布式事务解决方案之T ...

  8. 分布式事务 - Seata - TCC模式

    目录 一.什么是TCC 二.AT & TCC区别 及 适用场景 三.代码集成示例 3.1 升级Seata 1.5.2 3.2 示例场景说明 3.3 TCC核心接口定义 3.4 TCC相关阶段规 ...

  9. 分布式事务框架-TCC

    TCC事务框架应该具备故障恢复机制 一个TCC事务框架,若是没有故障恢复的保障,是不称其为分布式事务框架的. 分布式事务管理框架的职责,不是做出全局事务提交/回滚的指令,而是管理全局事务提交/回滚的过 ...

最新文章

  1. PHP函数printf()、sprintf()的用法
  2. 关于JVM，你需要掌握这些！！
  3. 修改html字体大小
  4. stm32 堆和栈(stm32 Heap Stack)
  5. javascript学习之基本概念
  6. Android studio 另一个程序正在使用此文件，进程无法访问
  7. 不清楚 spring 的这几个知识点，面试直接挂了！
  8. 修改SDE中自动生成的web.xml文件
  9. React开发（229）:react删除的实现
  10. 解决cocos2dx调用removeFromParent后报错问题
  11. PTA c语言 选择法排序过程
  12. 跑步是冻龄，还是催人老？
  13. argparse 部分参数整理
  14. [HNOI2015] 亚瑟王
  15. css固定姓名显示长度，排列更整齐
  16. Calendar中add()和roll()函数的用法
  17. uniapp app 腾讯云 IM 通讯 UserSig 加密协议方案
  18. 福禄克CFP2-100-Q与OFP2-100-Q区别
  19. Java学习之【Object】
  20. 图像三维重建方法综述

热门文章

  1. SIGIR‘22 推荐系统论文之多样性篇
  2. 忘记密码情况下卸载诺顿杀毒软件的方法(未验证)
  3. PHP-企业微信二次开发-接收用户输入消息内容并响应相关业务逻辑
  4. 图解六种全面质量管理工具用法和举例
  5. 【花费9毛钱购买阿里云服务器搭建一个私有云盘-owncloud】
  6. 打造ChatGPT的团队：平均年龄32岁！华人成员：清北+名校深造
  7. 图解HTTP思维导图
  8. python实现对称加解密3DES算法
  9. 英语音标（Phonetic symbol）
  10. Wifi图标消失，只剩小飞机