分布式事务

2PC

强一致性。

数据库层实现，参与的数据库需要实现XA协议。事务协调器、资源管理器。

资源锁定阶段。

资源提交阶段。

缺点：容易死锁，吞吐量低。

消息中间表

最终一致性。

A通过MQ通知B，同时把消息持久化为已发送状态，如果B消费了，回调A更新状态为完成。

避免消息丢失的场景，A定时抓取时间间隔较久，且已发送状态的消息，重新发送。

TCC

应用层实现，各阶段的资源需要有中间状态，比如库存应该有冻结/预占库存数、可用库存、扣减库存数。

• Try阶段：下单时通过Try操作去扣除库存预留资源。

• Confirm阶段：确认执行业务操作，在只预留的资源基础上，发起购买请求。

• Cancel阶段：只要涉及到的相关业务中，有一个业务方预留资源未成功，则取消所有业务资源的预留请求。

Saga

服务执行与补偿

Saga 模式是 SEATA 提供的长事务解决方案。Saga 模式下，分布式事务内存在多个参与者，每一个参与者都是一个冲正补偿服务，用户需要根据业务场景实现其正向操作（原服务）和逆向回滚操作（补偿服务）。在事务执行过程中，首先会依次执行各参与者的正向操作，如所有正向操作执行成功，则事务提交。如任一正向操作执行失败，则事务会执行之前各参与者的逆向回滚操作，回滚已提交的参与者，直至事务退回至其初始状态。

允许服务空补偿

空补偿，指的是原服务未执行，补偿服务已执行。大致场景如下：

针对该问题，在服务设计时，需要允许空补偿，即在没有找到要补偿的业务主键时，返回补偿成功，并将原业务主键记录下来，标记该业务流水已补偿成功。

服务防悬挂控制

悬挂，指的是补偿服务比原服务先执行。大致场景如下：

此时，需要检查当前业务主键是否已经在空补偿记录下来的业务主键中存在，如果存在则要拒绝执行该笔服务，以免造成数据不一致。

服务幂等控制

在分布式事务执行过程中，原服务与补偿服务都需要保证幂等性。由于网络连接可能超时，可以设置重试策略，重试发生时要通过幂等控制避免业务数据重复更新。