TCC事务介绍在08年软件开发2.0技术大会上，支付宝(Alipay )程立进行了PPT大规模SOA系统中的分布式事务处理，提出了TCC概念。 在网上搜索分布式事务相关博客时，基本上都提到了这个PPT。 目前，许多分布式事务的开源项目也是基于TCC的思想实现的。
TCC将事务提交分为三个操作：三次确认取消3。
Try :确保业务资源/数据有效性Confirm :确认业务操作的执行Cancel :中止业务操作的TCC事务处理流程类似于2PC的两级提交，而2PC通常
TCC电路图，照片来自阿里公众号文章
TCC的优缺点
TCC的优点：通过应用自定义的数据库操作粒度，可以减少锁定冲突并提高吞吐量。
TCC的不足之处：
1、对应用的入侵性强。 业务逻辑各分支需要实现try、confirm、cancel三个操作，应用入侵性强，改造成本高。 2、实现难度大。 每个失败原因(如网络状态、系统故障等)都必须实现不同的回滚策略。 为了满足一致性要求，confirm和cancel接口必须实现幂等。 TCC事务应用场景用户下单用余额红包支付看看TCC事务的具体应用。 假设用户的订单操作来自三个系统的订单系统、资金账户系统、红包账户系统，订单成功需要同时调用资金账户服务和红包服务完成支付
假设您购买商品1000元，并使用账户红包200元、余额800元确认付款。
Try操作
tryX订单系统创建计划支付的订单
tryY冻结账户红包200元
tryZ冻结资金账户800元
Confirm操作
confirmX订单已成功支付
确认扣除账户红包200元
confirmZ扣除资金账户800元
Cancel操作
cancelX订单处理异常，资金红包退回，订单支付失败
cancelY冻结红包失败、账户余额返还、订单支付失败
cancelZ余额冻结失败、账户红包返还、订单支付失败
TCC开源项目实战tcc-transaction tcc-transaction是TCC型事务Java的实现，tcc-transaction不与底层rpc框架结合，也就是说do ubbbbase 首先可以感谢使用http等的tcc-transaction事例有dubbo、http实现，这里使用dubbo事例。
事例的具体功能其实是对上面介绍的订单使用余额红包进行支付。
TCC-transactiontransactiontransactionmanager日志持久化支持多种方法
引用公式1.2指南的说明。 tcc-transaction框架使用事务存储库持久性事务日志。 filesystemtransactionrepository、springjdbctransactionrepository、RedisTransactionRepository或zokeeepertransactionreposions
1 .准备项目假设本地环境MySQL、Zookeeper已就绪
使用IDEA本地克隆项目
使用示例为tcc-transaction-dubbo-sample
tcc-transaction-dubbo-capital资金账户dubbo服务TCC-transaction-dubbo-capital-API资金账户dubbo接口定义TCC-transaction-dubo
运行数据库脚本： TCC-transactionTCC-transaction-tutorial-samplesrcdb scriptscreate _ db _ cap.SQL ()
TCC-transactionTCC-transaction-tutorial-samplesrcdb scriptscreate _ db _ red.SQL (红包账户)。
TCC-transactionTCC-transaction-tutorial-samplesrcdb scriptscreate _ db _ TCC.SQL (
更改项目配置： Zookeeper配置
zookeeper.ad
dress=127.0.0.1:2181如果非默认配置，需要将tcc-transaction-dubbo-sample 下的模块全部修改JDBC连接配置：
jdbc.driverClassName=com.mysql.jdbc.Drivertcc.jdbc.url=jdbc:mysql://127.0.0.1:3306/TCC?useUnicode=true&怕孤单的钥匙=UTF-8&allowMultiQueries=truejdbc.username=rootjdbc.password=如果非默认配置，需要将tcc-transaction-dubbo-sample，tcc-transaction-sample-domain 下项目模块修改 2. 项目发布实例目前都是使用的Tomcat发布，我们先部署Tomcat：
tcc-transaction-dubbo-capital 服务 http://192.168.10.199:8881/tcc-transaction-dubbo-order 服务 http://192.168.10.199:8882/tcc-transaction-dubbo-capital 服务 http://192.168.10.199:8883/服务全部启动成功： 3. 多种事务场景测试 第一种情况：红包账户冻结成功(try)、资金账户冻结成功(try)，订单操作异常(try)
模拟异常代码：
购买结果：
此时订单支付失败，红包账户冻结金额、资金账户冻结金额全部退回。
通过多种类似方式测试，例如：红包账户冻结异常、资金账户冻结异常，都会调cancel，退回冻结资源。所以在try阶段的任意一方异常，都会执行全局回滚。
第二种情况：订单处理成功(confirm)，资金账户扣减成功(confirm)，但红包账户扣减失败(confirm)
模拟异常代码，在红包扣减 confirm 操作制造异常：
购买结果：
此时订单为支付成功，但实际红包金额还处在冻结状态，事务管理器记录订单confirm操作未执行成功，系统会不断重试调用订单的confirm操作，直到红包扣减成功。
手动将红包服务异常代码去掉，重启服务，等到下一次重试，红包冻结金额被扣除成功。
第三种情况: 资金账户冻结成功(try)，红包账户冻结成功(try)，订单处理失败(confirm)
模拟异常代码，在订单 confirm 操作制造异常：
购买结果：
此时订单支付成功，但实际资金账户冻结金额、红包冻结金额都还没有扣除成功，事务管理器记录订单confirm操作未执行成功，系统会通过不断重试订单的confirm操作，直到资金账户和红包账户扣减成功。
手动将异常代码去掉，重启服务，等到下一次重试，红包和资金账户冻结金额被扣除。
第四种情况：在第一种情况下，订单cancel操作处理失败(cancel)
模拟异常代码，在第一种情况下基础，在cancel操作上在制造异常：
购买结果：
此时订单支付失败，资金账户、红包账户冻结成功，事务管理器记录订单cancel操作失败，系统会不断重试订单的cancel操作，直到资金账户和红包账户冻结金额退回账户。
手动将异常代码去掉，重启服务，下一次重试cancel操作，资金账户和红包账户冻结金额退回。
总结： try 操作成功，进入 confirm 操作，只要 confirm 处理失败（不管是协调者挂了，还是参与者处理失败或超时），系统通过不断重试直到处理成功。 进入 cancel 操作也是一样，只要 cancel 处理失败，系统通过不断重试直到处理成功。
引用一段对话，具体说明TCC使用场景，以及和2PC对比：
问题1、对于转账的cancel事务，相对简单，只要把账务冲负即可。可一般的业务逻辑会涉及很多流程、单证等操作，尤其是历史系统，应该很难改造成tcc结构的吧，不知道你们用tcc用在什么场景下？2、我第一次是在支付宝架构师程立PPT中听说tcc结构的，不知道你的实现跟阿里系的实现是什么关系，目前应用的规模大吗？3、我理解try程序完成后，立即提交try事务，不会有锁事务竞争。可这个时候账户余额的状态也被设置成了类似不可读的状态吧，依然不可以在其他业务中查询账户余额，那么这种方案比2PC优势具体在什么地方？ 回答1、 我的感觉TCC是比较适合具有较强一致性要求的场景，账务系统就是这样场景；应用TCC也有一定的开发成本，如果没有强一致性要求，可以考虑其他补偿型方案；2、目前已应用在线上环境多个应用，主要就是应用账务系统里使用；因为不是开源的，我没有看过阿里的实现，部分借鉴了他们的思路；希望有机会能看看；3、在Try结束后，账户余额会有部分资金冻结，其他业务不可以使用冻结资金；和2PC比较的话，理解下来有两点：· 2PC是基于资源层（如数据库），TCC是基于SOA服务· 2PC是是用全局事务，数据被lock的时间跨整个事务，直到全局事务结束；而TCC里每个对资源操作的是本地事务，数据被lock的时间短，可扩展性好其实目前阿里分布式事务解决方案–GTS(Gloabel Trasaction Service)正在公测中，详情可以参考这篇公众号文章：GTS来了！阿里微服务架构下的分布式事务解决方案
转自:
https://www.liangzl.com/get-article-detail-525.html