84669 person learning
152542 person learning
20005 person learning
5487 person learning
7821 person learning
359900 person learning
3350 person learning
180660 person learning
48569 person learning
18603 person learning
40936 person learning
1549 person learning
1183 person learning
32909 person learning
之前在InfoQ上看过支付宝分享的SOA架构下的事务处理经验, 其中提到 TCC (Try-Confirm-Cancel) 模式。
自己思考了一下，实现一个支持TCC事务的业务服务在复杂场景下还是有难度，例如一个业务服务可能涉及到一系列的数据表的变化，如何才能保证在try以后这些数据被锁定（防止其他事务用掉,进而导致confirm的时候失败）?
希望有过TCC开发经验的同学分享一下心得。
认证0级讲师
参考这个开源实现：https://github.com/changmingxie/tcc-transaction
TCC是分布式事务实现的一种方式
TRYING 阶段主要是对业务系统做检测及资源预留 CONFIRMING 阶段主要是对业务系统做确认提交，TRYING阶段执行成功并开始执行CONFIRMING阶段时，默认 CONFIRMING阶段是不会出错的。即：只要TRYING成功，CONFIRMING一定成功。 CANCELING 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。而幂等性则是指业务方法调用一次与调用多次的执行返回结果是一样的。举个支付项目的例子：
支付系统接收到会员的支付请求后，需要扣减会员账户余额、增加会员积分（暂时假设需要同步实现）增加商户账户余额再假设：会员系统、商户系统、积分系统是独立的三个子系统，无法通过传统的事务方式进行处理。 TRYING阶段：我们需要做的就是会员资金账户的资金预留，即：冻结会员账户的金额（订单金额） CONFIRMING阶段：我们需要做的就是会员积分账户增加积分余额，商户账户增加账户余额 CANCELING阶段：该阶段需要执行的就是解冻释放我们扣减的会员余额以上所有的操作需要满足幂等性，幂等性的实现方式可以是：
1、通过唯一键值做处理，即每次调用的时候传入唯一键值，通过唯一键值判断业务是否被操作，如果已被操作，则不再重复操作2、通过状态机处理，给业务数据设置状态，通过业务状态判断是否需要重复执行另外：你也可以看下这篇博客，上面是以传统电商平台支付系统为例的一套分布式事务处理实现，讲的也比较深
http://www.roncoo.com/article/detail/124243
可以参考一下开源的TCC实现ByteTCC。
ByteTCC是一个基于TCC（Try/Confirm/Cancel）事务补偿机制的分布式事务管理器，兼容JTA，因此可以很好的与EJB、Spring等容器（本文档下文说明中将以Spring容器为例）进行集成，支持Spring容器的声明式事务。
用户指南：https://github.com/liuyangmin...
微服务的话可以考虑一下由Atomikos提出的基于HTTP的RESTful TCC补偿模式, 有实战如下
https://github.com/prontera/s...
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
参考这个开源实现：https://github.com/changmingxie/tcc-transaction
TCC是分布式事务实现的一种方式
TRYING 阶段主要是对业务系统做检测及资源预留
CONFIRMING 阶段主要是对业务系统做确认提交，TRYING阶段执行成功并开始执行CONFIRMING阶段时，默认 CONFIRMING阶段是不会出错的。即：只要TRYING成功，CONFIRMING一定成功。
CANCELING 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
而幂等性则是指业务方法调用一次与调用多次的执行返回结果是一样的。
举个支付项目的例子：
支付系统接收到会员的支付请求后，需要扣减会员账户余额、增加会员积分（暂时假设需要同步实现）增加商户账户余额
再假设：会员系统、商户系统、积分系统是独立的三个子系统，无法通过传统的事务方式进行处理。
TRYING阶段：我们需要做的就是会员资金账户的资金预留，即：冻结会员账户的金额（订单金额）
CONFIRMING阶段：我们需要做的就是会员积分账户增加积分余额，商户账户增加账户余额
CANCELING阶段：该阶段需要执行的就是解冻释放我们扣减的会员余额
以上所有的操作需要满足幂等性，幂等性的实现方式可以是：
1、通过唯一键值做处理，即每次调用的时候传入唯一键值，通过唯一键值判断业务是否被操作，如果已被操作，则不再重复操作
2、通过状态机处理，给业务数据设置状态，通过业务状态判断是否需要重复执行
另外：你也可以看下这篇博客，上面是以传统电商平台支付系统为例的一套分布式事务处理实现，讲的也比较深
可以参考一下开源的TCC实现ByteTCC。
ByteTCC是一个基于TCC（Try/Confirm/Cancel）事务补偿机制的分布式事务管理器，兼容JTA，因此可以很好的与EJB、Spring等容器（本文档下文说明中将以Spring容器为例）进行集成，支持Spring容器的声明式事务。
用户指南：https://github.com/liuyangmin...
微服务的话可以考虑一下由Atomikos提出的基于HTTP的RESTful TCC补偿模式, 有实战如下
https://github.com/prontera/s...