Consumer和Provider about tcc-transaction

[changmingxie]

XiaoxinHao 你好！

1. 我的感觉TCC是比较适合具有较强一致性要求的场景，账务系统就是这样场景；应用TCC也有一定的开发成本，如果没有强一致性要求，可以考虑其他补偿型方案；
2. 目前已应用在线上环境多个应用，主要就是应用账务系统里使用；因为不是开源的，我没有看过阿里的实现，部分借鉴了他们的思路；希望有机会能看看；
3. 在Try结束后，账户余额会有部分资金冻结，其他业务不可以使用冻结资金；和2PC比较的话，理解下来有两点：

• 2PC是基于资源层（如数据库），TCC是基于SOA服务
• 2PC是是用全局事务，数据被lock的时间跨整个事务，直到全局事务结束；而TCC里每个对资源操作的是本地事务，数据被lock的时间短，可扩展性好

谢谢你blog中的文档，写的很好！另外，现在有细微的代码结构调整。

[changmingxie]

以TransferService.transferWithMultipleConsumer方法来说,下面是其方法实现：
@Compensable(confirmMethod = "transferWithMultipleConsumerConfirm", cancelMethod = "transferWithMultipleConsumerCancel")
@transactional
public void transferWithMultipleConsumer(long fromAccountId, long toAccountId, int amount) {
System.out.println("transferWithMultipleConsumer called");
accountService.transferFrom(null, fromAccountId, amount);
accountService.transferTo(null, toAccountId, amount);
}

ROOT就是TransferService.transferWithMultipleConsumer,
Consumer是TransferService.transferWithMultipleConsumer里调用的两个stub方法：accountServiceProxy.transferFrom 和accountServiceProxy.transferTo
Provider 则分别是那两个stub方法的服务实现者：accountServiceImpl.transferFrom和accountServiceImpl.transferTo;

在真实的rpc调用中，比如dubbo, stub方法就是提供给服务调用者的api.

[XiaoxinHao]

changmingxie您好，看到您的源码，非常激动啊，解决了我好久的困惑。同时将我的理解放在了我的博客http://ituski.iteye.com/blog/2278085中，如有错误欢迎批评指正。
这里有两个问题，不知道是否方便解答：
1、对于转账的cancel事务，相对简单，只要把账务冲负即可。可一般的业务逻辑会涉及很多流程、单证等操作，尤其是历史系统，应该很难改造成tcc结构的吧，不知道你们用tcc用在什么场景下？
2、我第一次是在支付宝架构师程立PPT中听说tcc结构的，不知道你的实现跟阿里系的实现是什么关系，目前应用的规模大吗？
3、我理解try程序完成后，立即提交try事务，不会有锁事务竞争。可这个时候账户余额的状态也被设置成了类似不可读的状态吧，依然不可以在其他业务中查询账户余额，那么这种方案比2PC优势具体在什么地方？

[wilsonp]

@changmingxie thx
我觉得这三个概念是理解你代码中事务处理的关键
但对try阶段还是有点疑问：
在readme中有如下内容：
完成所有业务检查（一致性）
预留必须业务资源（准隔离性）
1、这里的【完成所有业务检查】也是针对本地事务的吗？但一致性是针对多个异地事务的数据一致性来说的，这里如何做到所有业务检查呢？或者说是每个处于try阶段的各个本地事务自己检查？
2、预留必须的业务资源？这个能否举个例子呢..
再次感谢

[XiaoxinHao]

@changmingxie 好人哪，非常感谢回答哈！还有几个问题希望能交流下：
1、举例如TransferService的transfer方法使用了AccountServiceProxy的transferTo方法，这个是同步的。目前tcc是否更适合用在同步过程中，而不适合在异步过程中？
2、按照tcc的场景，TransferService和AccountService是在两个独立数据库下的，那么如果AccountService做rollback后，怎么通知TransferService也做rollback？即TransferService和AccountService的数据库下各自的TCC_TRANSACTION表怎么做同步？
3、如果不考虑2PC锁事务较长的问题，我有考虑过自己实现跨应用的2PC事务，基本思路为：每个节点的事务注册在ZK节点上，在事务准备完成后做xaResource的prepare，并修改ZK节点的状态，待所有节点prepare后，各自负责commit。不知道这个方案是否有实际价值？
4、关于2PC有个地方没太明白：JTA实现中，xaResource的prepare具体做了哪些工作，为什么2PC要有这个过程，不能在statement的excute成功后即视为资源准备就绪了吗？

[changmingxie]

@wilsonp
针对你的问题：
1、try阶段每个业务自己处理自己的业务检查
2、预留必须的业务资源，举个例子，转账A->B 100，在try阶段转出方A的余额先冻结100元，就是预留余额资源；在confirm阶段把冻结的钱清空就行了，不需要再竞争余额资源；如果cancel了，再把冻结的钱回填到A的余额上，也不需要竞争余额资源；

[XiaoxinHao]

@changmingxie 细想有一步想确认下：你给的样例中TransferService和AccountService实际上是在一个JVM中的，如果两个service为跨域独立的soa服务，能够适用你的程序吗？

[changmingxie]

@XiaoxinHao,

1. TCC 适用同步的，强一致性的场景；
2. TransferService.transfer 和AccountService.transferTo是TCC的两个参与者，在TCC的try阶段，只要有一个参与者失败了，TCC框架就会调用所有参与者的cancel方法，这样TransferService和AccountService操作的各自数据库会rollback。
3. 你的意思是提供的服务实现XA协议么？
4. XA协议建议查看相关协议文档，有详细介绍呢；
5. TCC本来就是为独立部署的SOA服务而设计的。Unit Test是使用跨线程调用来模拟独立部署的SOA服务；所以多JVM支持是没有问题的。

[finezsz]

有个疑问，如果回滚失败了怎么办

[lechiw]

@finezsz 我最近也在研究tcc-transaction框架，我正好看到过相关问题，我可以尝试回答下，在confirm和cancel(回滚)阶段，如果执行失败了，框架会进行maxRetryCount次尝试重复执行，maxRetryCount是可配置的，如果在maxRetryCount次后仍然失败，还可以进行人工干预进行回滚处理