分布式事物--TCC
2024-07-20 18:31:00 0 举报AI智能生成
分布式事物--TCC
作者其他创作
大纲/内容
核心思想
针对每个操作，都要注册一个<br>与其对应的确认和补偿（撤销）操作<br>
Try
含义
这个阶段对各个服务的资源做检测<br>以及对资源进行锁定或者预留【锁定资源】<br>
用法
订单服务：先置一个中间状态“UPDATING”，而不是直接设置“支付成功”状态
库存服务：先用一个冻结库存字段保存冻结库存数，而不是直接扣掉库存
Confirm
含义
执行真正的业务操作，不作任何业务检查，<br>只使用Try阶段预留的业务资源，<br>Confirm操作要求具备幂等设计，<br>Confirm失败后需要进行重试
用法
订单服务：将订单的中间状态变更为PAYED-支付成功
库存服务：将冻结库存数清零，同时扣减掉真正的库存<br>
Cancel
含义
如果任何一个服务的业务方法执行出错，<br>那么这里就需要进行补偿，即执行回滚操作，<br>释放Try阶段预留的业务资源 ，<br>Cancel操作要求具备幂等设计，Cancel失败后需要进行重试【释放资源】<br>
用法
订单服务：将订单的状态设置为“CANCELED”
库存服务：将冻结库存扣减掉，加回到可销售库存里去<br>
空回滚和空悬挂【业务悬挂】
防悬挂【业务悬挂】
应当阻止执行空回滚后的try操作，避免悬挂
空回滚
在未执行try操作时先执行了cancel操作，这时cancel不能做回滚
解决方案
用表记录当前事务id和执行状态
优缺点
优点
2PC比起来，实现以及流程相对简单
性能也可以得到提升<br>
缺点
TCC模型对业务的侵入性太强，需要改造代码多，由一个变成三个
适用场景
对金额要求性很高的业务场景<br>
银行核心主机的账务系统，不容半点差池<br>
在一般的业务场景下，尽量别没事就用TCC作为分布式事务的解决方案
微服务的场景
架构图
<br>
开源框架
tcc-transaction框架
提供了跟dubbo的整合,对spring cloud支持不好
himly框架
支持spring cloud，dubbo
spring xml来进行配置<br>
ByteTCC框架<br>
支持spring&nbsp;cloud，dubbo<br>
还支持saga事务，长事务
使用说明wiki
<br>
源码阅读<br>
启动
不含FeginClient 服务器启动
含FeginClient服务器启动
关键点
原来的feign调用被代理一层，请求的真实url应该被改过，改成了请求这一个controller的方法
类
CompensableFeignBeanPostProcessor
CompensableCoordinatorController
后台线程
读取这份日志文件，重新执行上一次没有执行完成的分布式事务
初始化一条CompensableWork线程
<span style="font-size: inherit;">每隔60秒获取所有的分布式事务</span><br style="font-size: inherit;"><span style="font-size: inherit;">找到它们内部关联的出现故障的分布式子事务<br></span>执行recover操作，调用你的commit或者rollback接口，尝试完成你的分布式事务<br>
执行过程<br>
调用所有系统都Try成功
主业务服务调用A,B系统Try 成功，C系统Try失败
主业务服务会调用A,B 系统会调用Cancel 回滚。C系统借助@transaction本地回滚
调用confirm或cancel失败了
基于CompensableWork的工作机制去不断重试的完成分布式事物
tcc分布式事务执行到一半，系统宕机
调用链
0 条评论
下一页
