介绍
业务活动管理器介绍:
就是类似于集中管理器:
以支付宝和余额宝为例进行说明.
支付宝完成扣钱的动作时,记录消息数据,将消息数据和业务数据存在同一个数据库实例中.
Begin Transaction
update A set amount=amount-1000 where uid=100;
insert into message(uid,amount,status) values (1,1000,1)
End Transaction
Commit;
TCC主要用来解决应用业务操作原子性的问题。
跨应用的业务操作原子性要求,其实是比较常见的。
比如在第三方支付场景中的组合支付,用户在电商网站购物后,要同时使用余额和红包支付该笔订单,而余额系统和红包系统分别是不同的应用系统,支付系统在调用这两个系统进行支付时,就需要保证余额扣减和红包使用要么同时成功,要么同时失败。
TCC 算法介绍
Try:尝试执行业务。
- 完成所有业务检查(一致性)
- 预留必须业务资源(准隔离性)
Confirm:确认执行业务
- 真正执行业务
- 不做任何业务检查
- 只使用Try阶段预留的业务资源
Cancel:取消执行业务
- 释放Try阶段预留的业务资源
案例介绍
账务拆分的业务场景如下,分别位于三个不同分库的帐户A、B、C。A和B一起向C转帐共80元:A向C转账30,B向C转账50元。
Try:尝试执行业务。
- 完成所有业务检查(一致性):检查A、B、C的帐户状态是否正常,帐户A的余额是否不少于30元,帐户B的余额是否不少于50元。
- 预留必须业务资源(准隔离性):帐户A的冻结金额增加30元,帐户B的冻结金额增加50元,这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中,帐户A和B的可用余额不够的情况。
Confirm:确认执行业务
- 真正执行业务:如果Try阶段帐户A、B、C状态正常,且帐户A、B余额够用,则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。
- 不做任何业务检查:这时已经不需要做业务检查,Try阶段已经完成了业务检查。
- 只使用Try阶段预留的业务资源:只需要使用Try阶段帐户A和帐户B冻结的金额即可。
Cancel:取消执行业务
- 释放Try阶段预留的业务资源:如果Try阶段部分成功,比如帐户A的余额够用,且冻结相应金额成功,帐户B的余额不够而冻结失败,则需要对帐户A做Cancel操作,将帐户A被冻结的金额解冻掉。
###TCC的优点和限制
TCC事务的优点
- 解决了跨应用业务操作的原子性问题,在诸如组合支付、账务拆分场景非常实用。
- TCC实际上把数据库层的二阶段提交上提到了应用层来实现,对于数据库来说是一阶段提交,规避了数据库层的2PC性能低下问题。
TCC事务的缺点
- TCC的Try、Confirm和Cancel操作功能需业务提供,开发成本高。
参考:https://blog.csdn.net/kobejayandy/article/details/54783212