分布式事务Saga (一) TCC vs Saga

分布式事务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阶段占用的资源（如：库存服务的释放预占库存，支付服务的释放冻结的账户余额）

正常逻辑时序图

TCC 正常流程图.png

支付服务在调用try阶段失败的事务回滚

TCC Confirm异常流程图.png

本项目Saga流程

confirm 直接执行资源操作，（如：库存服务的减库存，支付服务的扣减账户余额）
cancel 回滚资源操作，这个地方的cancel与TCC中的cancel不一样，准确点说应该是回滚，（如：回滚库存服务的减库存操作，回滚支付服务的扣减账户余额的操作）。当然是业务层面实现的回滚，而非数据库事务层面的回滚

saga 正常流程图

saga 正常流程图.png

saga 异常流程图

saga 异常流程图.png

结论

可以看到Saga对比TCC少了一步try的操作，TCC无论最终事务成功失败都需要与事务参与方交互两次。而Saga在事务成功的情况下只需要与事务参与方交互一次, 如果事务失败，需要交互两次