TCC模式
一个分布式的全局事务，整体是两阶段提交 的模型。全局事务是由若干分支事务组成的，分支事务要满足 两阶段提交 的模型要求，即需要每个分支事务都具备自己的：
两阶段提交 的模型
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：
1.流程分析
举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。
阶段一（ Try ）：
检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30
初始余额：
余额充足，可以冻结：
此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。
阶段二（Confirm)：
假如要提交（Confirm），之前可用金额已经扣减，并转移到冻结金额。因此可用金额不变，直接冻结金额扣减30即可：
此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元
阶段二(Canncel)：
如果要回滚（Cancel），则释放之前冻结的金额，也就是冻结金额扣减30，可用余额增加30
2.事务悬挂 和 空回滚
假如一个分布式事务中包含两个分支事务，try阶段，一个分支成功执行，另一个分支事务阻塞：
如果阻塞时间太长，可能导致全局事务超时而触发二阶段的cancel操作。两个分支事务都会执行cancel操作：
空回滚
防悬挂
- 对于整个空回滚的分支事务，将来try方法阻塞结束依然会执行。但是整个全局事务其实已经结束了，因
- 此永远不会再有confirm或cancel，也就是说这个事务执行了一半，处于悬挂状态，这就是业务悬挂问题。此时业务应用应该要拒绝处理，返回异常。
3.总结
TCC的优点是什么？
TCC的缺点是什么？
原文地址:https://blog.csdn.net/weixin_48052161/article/details/134724409
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_17855.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
