初识分布式事务

实际的开发中，分布式事务的产生的原因主要来源于 服务、存储的拆分

分布式事务的解决方案：

2pc

有一个节点作为协调者，其他节点是参与者

第一阶段先去锁定相应的事务资源，没问题的话 第二阶段再去执行

存在资源阻塞 && 协调者单点故障的问题

3pc

三个阶段：询问，锁定资源，真正执行

在协调者和参与者中都加入了超时机制

TCC

TCC 把事务运行过程分成 Try、Confirm / Cancel 两个阶段，每个阶段的逻辑由业务代码控制，避免了长事务，可以获取更高的性能。

基于业务层面的事务控制，每个事务分支（订单服务、库存服务）都需要自己去实现对应的try、confirm/cancel接口，侵入比较强。

TM: Transaction Manager，事务管理器，负责整个TCC事务的协调控制。

TC: Transaction Coordinator，事务协调者。

•Try阶段：调用try接口，尝试执行业务，完成所有的业务检查、预留业务资源。
订单服务，添加一个预备状态，修改为Updating，冻结当期订单的操作，而不是直接修改为支付成功。
库存服务，冻结库存，扩展字段，可以添加新的库存冻结表。
•Comfirm/Cancel阶段：两个是互斥的，只能执行其中的一个，都需要幂等性，要允许失败重试。
Comfirm：把前面的try阶段锁定的资源提交，类比数据库的Commit操作。在支付场景中，包括订单状态从更新中更新为支付成功。库存数据扣减在try冻结的库存。
Cancel：业务上的回滚操作。订单服务，撤销预备状态，还原为待支付状态或者取消状态，库存服务删除冻结的库存，添加到可用的库存中。

本地消息表：

优点：实现逻辑比较简单，开发成本比较低。
缺点：与业务场景绑定，高耦合。本地消息表与业务表在一个库中，占用业务系统资源，影响数据库性能。

MQ 事务消息方案

上一节 blog 已写