分布式事务Saga (一) TCC vs Saga
分布式事务Saga(二)事务管理者SagaTransactionalAspect
分布式事务Saga(三)事务参与方管理SagaParticipantAspect
分布式事务Saga(四)事务恢复SagaRecoveryManager
项目地址:https://github.com/yangxb2010000/saga
该项目的实现本质上说不是一个严格意义上的Saga实现,更像是一个简化版的TCC事务
先对比一下Saga与TCC的区别
TCC流程
Try 预留资源 (如:库存服务的预占库存,支付服务的冻结部分账户余额)
Confirm 如果所有的事务参与者try 操作都执行成功了,就会调用所有事务参与者的confirm操作,确认资源。(如:库存服务的减库存,支付服务的扣减账户余额)
Cancel 如果有事务参与者在try阶段执行失败,就调用所有已执行try阶段成功的参与方的cancel方法,释放try阶段占用的资源(如:库存服务的释放预占库存,支付服务的释放冻结的账户余额)
正常逻辑时序图
支付服务在调用try阶段失败的事务回滚
本项目Saga流程
confirm 直接执行资源操作,(如:库存服务的减库存,支付服务的扣减账户余额)
cancel 回滚资源操作,这个地方的cancel与TCC中的cancel不一样,准确点说应该是回滚,(如:回滚库存服务的减库存操作,回滚支付服务的扣减账户余额的操作)。当然是业务层面实现的回滚,而非数据库事务层面的回滚
saga 正常流程图
saga 异常流程图
结论
可以看到Saga对比TCC少了一步try的操作,TCC无论最终事务成功失败都需要与事务参与方交互两次。而Saga在事务成功的情况下只需要与事务参与方交互一次, 如果事务失败,需要交互两次