之前在InfoQ上看过支付宝分享的SOA架构下的事务处理经验, 其中提到 TCC (Try-Confirm-Cancel) 模式。
自己思考了一下，实现一个支持TCC事务的业务服务在复杂场景下还是有难度，例如一个业务服务可能涉及到一系列的数据表的变化，如何才能保证在try以后这些数据被锁定（防止其他事务用掉,进而导致confirm的时候失败）?
希望有过TCC开发经验的同学分享一下心得。
参考这个开源实现：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