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