微信公众号网站建设,文化礼堂建设情况网站,做网站是先做后台还是前端,江西企业 网站建设目录 基本介绍
起源
概述
案例流程分析
TCC注意事项
空回滚
幂等
悬挂
具体使用
LocalTCC
TwoPhaseBusinessAction
小结 基本介绍
起源
关于TCC的概念#xff0c;最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apost…目录 基本介绍
起源
概述
案例流程分析
TCC注意事项
空回滚
幂等
悬挂
具体使用
LocalTCC
TwoPhaseBusinessAction
小结 基本介绍
起源
关于TCC的概念最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
在该论文中TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司其注册了TCC商标。
概述
TCC是Try-Confirm-Cancel的简称。
TCC模式与AT模式非常相似每阶段都是独立事务不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法 Try资源的检测和预留。做业务检查(一致性)及资源预留(隔离)此阶段仅是一个初步操作它和后续的Confirm 一起才能真正构成一个完整的业务逻辑。 Confirm完成资源操作业务要求 Try 成功 Confirm 一定要能成功。做确认提交Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下采用TCC则 认为 Confirm阶段是不会出错的。即只要Try成功Confirm一定成功。若Confirm阶段真的出错了需引入重试机制或人工处理。 Cancel预留资源释放可以理解为try的反向操作。在业务执行错误需要回滚的状态下执行分支事务的业务取消预留资源释放。通常情况下采 用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了需引入重试机制或人工处理。 TM首先发起所有的分支事务的try操作任何一个分支事务的try操作执行失败TM将会发起所有分支事务的Cancel操作若try操作全部成功TM将会发起所有分支事务的Confirm操作其中Confirm/Cancel 操作若执行失败TM会进行重试。 与AT模式与TCC模式的对比 AT模式 TCC模式一阶段 prepare 在本地事务中一并提交业务数据更新和相应回滚日志记录调用 自定义的 prepare 逻辑二阶段 commit马上成功结束自动异步批量清理回滚日志调用 自定义的commit 逻辑二阶段 rollback通过回滚日志自动 生成补偿操作完成数据回滚。调用 自定义的rollback 逻辑其他支持本地 ACID 事务 的 关系型数据库不依赖于底层数据资源的事务支持 TCC支持把自定义的分支事务纳入到全局事务的管理中。 案例流程分析
假设一个扣减用户余额的业务。假设账户A原来余额是100需要余额扣减30元。 阶段一 Try 检查余额是否充足如果充足则冻结金额增加30元可用余额扣除30 总金额 冻结金额 可用金额数量依然是100不变。事务直接提交无需等待其它事务。
阶段二Confirm)现在库存充足可以提交Confirm则冻结金额扣减30确认可以提交不过之前可用金额已经扣减过了这里只要清除冻结金额就好了 阶段二(Canncel)如果库存不足需要回滚Cancel则冻结金额扣减30可用余额增加30需要回滚那么就要释放冻结金额恢复可用金额 TCC注意事项
空回滚
在没有调用 TCC 资源 Try 方法的情况下调用了二阶段的 Cancel 方法Cancel 方法需要识别出这是一个空回 滚然后直接返回成功。出现原因是当一个分支事务所在服务宕机或网络异常分支事务调用记录为失败这个时候其实是没有执行Try阶 段当故障恢复后分布式事务进行回滚则会调用二阶段的Cancel方法从而形成空回滚。解决思路是关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行如果执行了那就是正常回 滚如果没执行那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录全局事务ID贯穿整个分 布式事务调用链条。再额外增加一张分支事务记录表其中有全局事务 ID 和分支事务 ID第一阶段 Try 方法里会 插入一条记录表示一阶段执行了。Cancel 接口里读取该记录如果该记录存在则正常回滚如果该记录不存 在则是空回滚。 幂等
为了保证TCC二阶段提交重试机制不会引发数据不一致要求 TCC 的二阶段 Try、 Confirm 和 Cancel 接口保证幂等这样不会重复使用或者释放资源。如果幂等控制没有做好很有可能导致数据 不一致等严重问题。解决思路在上述“分支事务记录”中增加执行状态每次执行前都查询该状态。
悬挂
悬挂就是对于一个分布式事务其二阶段 Cancel 接口比 Try 接口先执行。出现原因是在 RPC 调用分支事务try时先注册分支事务再执行RPC调用如果此时 RPC 调用的网络发生拥堵 通常 RPC 调用是有超时时间的RPC 超时以后TM就会通知RM回滚该分布式事务可能回滚完成后RPC 请求 才到达参与者真正执行而一个 Try 方法预留的业务资源只有该分布式事务才能使用该分布式事务第一阶段预 留的业务资源就再也没有人能够处理了对于这种情况我们就称为悬挂即业务资源预留后没法继续处理。解决思路是如果二阶段执行完成那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下“分支 事务记录”表中是否已经有二阶段事务记录如果有则不执行Try。 具体使用
LocalTCC
该注解需要添加到上面描述的接口上表示实现该接口的类被 seata 来管理seata 根据事务的状态自动调用我们定义的方法如果没问题则调用 Commit 方法否则调用 Rollback 方法。
LocalTCC
public interface AccountTCCService {}
TwoPhaseBusinessAction
该注解用在接口的 Try 方法上该注解的用法如下:
LocalTCC
public interface AccountTCCService {TwoPhaseBusinessAction(name deduct, commitMethod confirm, rollbackMethod cancel)void deduct(BusinessActionContextParameter(paramName userId) String userId,BusinessActionContextParameter(paramName money)int money);boolean confirm(BusinessActionContext ctx);boolean cancel(BusinessActionContext ctx);
}
该注解包含这几个属性
name 为 tcc 方法的 bean 名称需要全局唯一一般写方法名即可commitMethod 自然地写 Commit 方法的方法名rollbackMethod 写 Rollback 方法的方法名 BusinessActionContextParameter 该注解用来修饰 Try 方法的入参被修饰的入参可以在 Commit 方法和 Rollback 方法中通过 BusinessActionContext 获取。 最后对接口进行实现即可
Service
Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {Autowiredprivate AccountMapper accountMapper;Autowiredprivate AccountFreezeMapper freezeMapper;OverrideTransactionalpublic void deduct(String userId, int money) {// 0.获取事务idString xid RootContext.getXID();// 1.扣减可用余额accountMapper.deduct(userId, money);// 2.记录冻结金额事务状态AccountFreeze freeze new AccountFreeze();freeze.setUserId(userId);freeze.setFreezeMoney(money);freeze.setState(AccountFreeze.State.TRY);freeze.setXid(xid);freezeMapper.insert(freeze);}Overridepublic boolean confirm(BusinessActionContext ctx) {// 1.获取事务idString xid ctx.getXid();// 2.根据id删除冻结记录int count freezeMapper.deleteById(xid);return count 1;}Overridepublic boolean cancel(BusinessActionContext ctx) {// 0.查询冻结记录String xid ctx.getXid();AccountFreeze freeze freezeMapper.selectById(xid);// 1.恢复可用余额accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());// 2.将冻结金额清零状态改为CANCELfreeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);int count freezeMapper.updateById(freeze);return count 1;}
}
小结
性能好
模式AP,存在数据不一致的中间状态
难易程度复杂SEATA TC只负责全局事务的提交与回滚指令具体的回滚处理全靠程序员自己实现(手动写代码)
使用要求
所有服务与数据库必须要自己拥有管理权支持异构数据库可以使用不同选型实现
