分布式事务方案

银行跨行转账业务是一个典型分布式事务场景，假设 A 需要跨行转账给 B，那么就涉及两个银行的数据，无法通过一个数据库的本地事务保证转账的 ACID，只能够通过分布式事务来解决。分布式事务就是指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。在上述转账的业务中，用户 A-100 操作和用户 B+100 操作不是位于同一个节点上。本质上来说，分布式事务就是为了保证在分布式场景下，数据操作的正确执行。

如何选择最适合你的分布式事务方案

多个微服务组合成原子操作

有一类业务场景是需要把多个微服务组合成原子操作：假设您有一个活动业务，用户点击领取按钮后，会领取一张优惠券，和一个月的会员。优惠券和会员分别属于不同的服务，需要都被调用，不希望出现一个服务调用成功，另一个因为网络或者其他故障导致没有成功。

这个场景适合可靠消息方案，可以使用 rocketmq、rabbitmq 等，发送给消息队列的消息，一定要等收到队列接收确认，再返回应用程序。

有一类业务与前一种业务情况类似，但有一些差别：假设您有一个新用户注册成功后，领取一张优惠券和一个月会员。如果注册不成功，不希望调用领取；只有注册成功才领取。这种情况，适合本地消息方案，或者事务消息方案。这两种方案都能保证本地事务和消息的原子性。

订单类对一致性要求较高的业务

订单交易类业务，涉及资金、库存、优惠券等多个服务，完成一个订单，需要相关的各个服务组合成一个整体可回滚的事务。如果订单进行过程中金额先扣减，后续因为库存不够只能退款，把金额补偿加回来。在这个过程中用户看到了金额减少，又金额变回来，体验很差。一般这类业务都会先冻结资金，如果订单能成功，再扣减资金；不能成功，则解冻资金，这样能够让资金信息对用户更友好。

这种场景适合 TCC 方案，可以在 TCC 的 Try 中冻结资金，Confirm 中扣减资金，Cancel 中解冻资金；

一致性要求不高的可回滚业务

如果业务对事务中的一致性要求不高，允许用户看到中间状态，例如用户的积分数据等。

这种模式适用 SAGA 模式，SAGA 对比与 TCC，只有正向操作和逆向补偿操作，会更加简单；

耗时较久的全局事务

耗时较旧的全局事务适合可靠消息和 SAGA，不适合 TCC 和 XA，因为大多数的 XA 和 TCC 实现，为了方便用户灵活的定义事务，通常把事务的进度保存在应用程序，一旦事务进行中应用程序崩溃，无法往前进行下一步，只能回滚。

SAGA 和可靠消息，把事务进度保存在数据库或消息系统中，任何一个组件临时的失败，如果重试成功，能够让事务继续。其中如果整个事务是需要回滚的，那么适合 SAGA，不需要回滚的，适合可靠消息

并发度较低的业务

如果业务并发度不高，事务又需要支持回滚，那么适合 XA 方案。XA 方案，除了并发不高，也还需要本地数据库能支持 XA 接口。这个方案的优点是，使用上较简单，比较接近本地事务。