标签：冻结 事务 xid userId ctx TCCP 分步 accountFreeze
分步式事务
TCC模式
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：
- Try：资源的检测和预留；
- Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
- Cancel：预留资源释放，可以理解为try的反向操作。
流程
- 阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30
初识余额：
余额充足，可以冻结：
此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。
- 阶段二（Confirm)：假如要提交（Confirm），则冻结金额扣减30
确认可以提交，不过之前可用金额已经扣减过了，这里只要清除冻结金额就好了：
此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元
优点和缺点
TCC的优点是什么？
- 一阶段完成直接提交事务，释放数据库资源，性能好
- 相比AT模型，无需生成快照，无需使用全局锁，性能最强
- 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
TCC的缺点是什么？
- 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
- 软状态，事务是最终一致
- 需要考虑Confirm和Cancel的失败情况，做好幂等处理
空回滚
当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。
业务悬挂
对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel，这就是业务悬挂。应当阻止执行空回滚后的try操作，避免悬挂
实现TCC
- 编写接口
@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);
}
- 编写实现类
@Service
public class AccountTCCServiceImpl implements AccountTCCService {
@Autowired
private AccountMapper accountMapper;
@Autowired
private AccountFreezeMapper accountFreezeMapper;
/**
* 这个是try方法，用来做扣减余额，
* 和冻结余额并更改状态的
* @param userId
* @param money
*/
@Override
@Transactional
public void deduct(String userId, int money) {
//0.获取事务id
String xid = RootContext.getXID();
//0.1事务悬挂判断
if(accountFreezeMapper.selectById(xid)!=null){
return;
}
//1.扣减可用余额
accountMapper.deduct(userId, money);
//2.记录冻结余额，事务状态
AccountFreeze accountFreeze = new AccountFreeze();
accountFreeze.setUserId(userId);
accountFreeze.setFreezeMoney(money);
accountFreeze.setState(AccountFreeze.State.TRY);
accountFreeze.setXid(xid);
accountFreezeMapper.insert(accountFreeze);
}
/**
* 这个是confirm方法，用来提交的。
* 一旦不需要回滚则删除冻结记录。
* @param ctx
* @return
*/
@Override
public boolean confirm(BusinessActionContext ctx) {
//0.获取事务id
String xid = ctx.getXid();
//1.根据id删除冻结记录
return accountFreezeMapper.deleteById(xid) == 1;
}
/**
* 这个方法用来回滚。
* 根据冻结记录回滚数据。
* 进行了空回滚和多次执行的判断
* @param ctx
* @return
*/
@Override
public boolean cancel(BusinessActionContext ctx) {
String xid = ctx.getXid();
//0.查询冻结记录
AccountFreeze accountFreeze = accountFreezeMapper.selectById(xid);
String userId = ctx.getActionContext("userId").toString();
//0.1空回滚的判断
if(accountFreeze==null){
accountFreeze.setUserId(userId);
accountFreeze.setFreezeMoney(0);
accountFreeze.setState(AccountFreeze.State.CANCEL);
accountFreeze.setXid(xid);
return true;
}
//0.2幂处理判断
if (accountFreeze.getState()== AccountFreeze.State.CANCEL){
return true;
}
//1.恢复可用余额
accountMapper.refund(accountFreeze.getUserId(), accountFreeze.getFreezeMoney());
//2.将冻结金额清零
accountFreeze.setFreezeMoney(0);
accountFreeze.setState(AccountFreeze.State.CANCEL);
int i = accountFreezeMapper.updateById(accountFreeze);
return i == 1;
}
}
Saga模式
Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。
其理论基础是Hector & Kenneth 在1987年发表的论文Sagas。
原理
在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga也分为两个阶段：
- 一阶段：直接提交本地事务
- 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
优点和缺点
优点：
- 事务参与者可以基于事件驱动实现异步调用，吞吐高
- 一阶段直接提交事务，无锁，性能好
- 不用编写TCC中的三个阶段，实现简单
缺点：
- 软状态持续时间不确定，时效性差
- 没有锁，没有事务隔离，会有脏写
四种模式对比
我们从以下几个方面来对比四种实现：
- 一致性：能否保证事务的一致性？强一致还是最终一致？
- 隔离性：事务之间的隔离性如何？
- 代码侵入：是否需要对业务代码改造？
- 性能：有无性能损耗？
- 场景：常见的业务场景
如图：
标签：冻结,事务,xid,userId,ctx,TCCP,分步,accountFreeze 来源： https://www.cnblogs.com/Boerk/p/16101248.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。