小米网站 用什么做的,小程序开发教程电子书,wordpress 菜单两列显示不出来,成都服务器租赁#xff08;1#xff09;TCC模式
前面学了XA和AT模式#xff0c;这两种模式最终都能实现一致性#xff0c;和隔离性#xff0c;XA是强一致#xff0c;AT是最终一致#xff0c;隔离性呢XA是在第一阶段不提交#xff0c;基于事务本身的特性来完成隔离#xff0c;AT则是…1TCC模式
前面学了XA和AT模式这两种模式最终都能实现一致性和隔离性XA是强一致AT是最终一致隔离性呢XA是在第一阶段不提交基于事务本身的特性来完成隔离AT则是加了全局锁锁定资源去隔离事务本质上来看这两种都是加锁来实现的只要加了锁都会有性能的损耗如果追求的是极致的性能就需要使用其他的办法TCC 模式就是性能的体现他不需要去加锁
TCC是基于人工编码来实现的不想AT模式自动实现的在第一阶段形成快照二阶段才能恢复它多了一个生成快照的逻辑性能有损耗这一点TCC胜过了AT模式 成功扣减冻结金额 -资源预留 回滚 做反向操作冻结金额减三十余额加三十 可以看到TCC模式在做了在第一阶段完成了资源预留之后第二阶段不管是Confirm还是Cancel都是在操作自己预留的这份资源就导致了TCC跟AT模式有很大的区别
在第一阶段两种模式都是个提交各自的事务很快释放数据库锁在性能上都非常的好在第一阶段都会有有可能成功有可能失败造成数据不一致只有在第二阶段完成了Confirm和Cancel之后才有可能才能保证数据的最终一致它是最终一致会有中间状态
AT模式是需要加锁去实现隔离的需要在第一阶段跟第二阶段持有全局锁在一二阶段之间其他事务是不能操作这个资源的从而确保安全在TCC模式下是不需要隔离的因为在第一阶段每个事务冻结的金额是不一样的每个事务回滚还是提交操作的都是本事务自己冻结余额不会影响不需要加锁第二阶段各自操作各自预留的资源互不影响TCC模式不需要加锁就实现了隔离比AT模式好了很多很多 2TCC案例
并不是所有的事务都适合TCC模式来实现想下单的逻辑是新增的逻辑怎么去资源预留它不适合TCC模式用AT模式就很好第一阶段新增了第二阶段回滚另外一个事务它也要做新增它跟前一个事务没有关系扣减库存的服务可以用ACC模式来实现我们这里演示金额扣减服务
幂等性我们有一个业务接口你调用我一次也好多次也好最终达成的效果是一致的不会因为重复调用出现问题这叫做幂等性 怎么避免业务悬挂呢在执行try的时候判断是否回滚过回滚过try就不能够执行
判断执行空回滚呢在执行cancel的时候判断try是否执行了try没有执行做空回滚
需要在数据库里记录当前事务的状态当前的事务状态在try状态啊还是confirm状态啊cancel状态啊只有知道事务的状态才能做空回滚和避免业务悬挂
新建表冻结金额表 BussinessActionContextParameter注解这个注解标记的参数将来放到一个上下文对象里BussinessActionContext通过这个对象都可以拿到这个参数 创建新的接口AccountTCCService接口 创建余额表用它表示资源的预留锁定事务状态 实体类 Mapper 创建实现类 用户余额表中的money字段添加了using 表示没有负号这个余额不会扣成负数当扣成负数时会直接报错事务自动回滚因此余额不用做判断了 所以在方法try中直接扣除余额不会做余额判断了 修改Try在其中做悬挂处理 Confirm逻辑 回滚userID Money可以从加入到全局的参数中获取也可以查询数据库从数据中获取 修改回滚在其中做回滚判断和幂等处理:
这里的userID从全局参数中获取然后再toString一下 修改Controller 修改成AccountTCCService 重启服务
使用Postman发送请求发送正确的参数 库存表从6到4 订单多了一条 余额减200 余额冻结表没有数据因为操作是正确的 异常数据 库存没变 订单没有增加 余额没变 余额冻结表多了一条记录state为2回滚状态 3Saga模式 Saga最大的缺点没有隔离性事务与事务之间有可能出现脏写的一二阶段之间既没有全局锁也没有冻结资源它是由隔离的安全问题的 它会逐个的去执行事务在这个流程中只有有事务出现问题它会反向依次执行补偿逻辑从而保证整个事务的状态一致性典型的分阶段提交
事务执行是可以基于事件驱动的一个事件完成执行下一个事件事件驱动好处是吞吐能力比较强他不会阻塞和等待事件到了就去干某一键事情 但是事件什么时候去执行时间时不确定的时效性没有那么强 这种长事务的解决方案时效性比较差一些比较适合用于事务跨度比较大的业务比如跨银行的业务调用啊转账等等业务比较复杂的场景一般情况下用不到
AT用的最多TCC和XA选做一些补充就够了
