聊聊分布式事务

分布式事务，算是分布式系统极为重要的一个模块。

分布式事务的概念，网上随手可见，我不多讲。

今天主要想聊聊，分布式事务的解决思路及其适用场景。

在说具体思路之前，我先假设一个业务调度功能，分别会调用A、B、C三个服务。

要保证这三个服务的事务，该怎么办呢？

可靠消息队列

A业务完成并提交数据库事务后，发送消息；B收到消息后，完成业务并提交数据库事务后，发送消息；

C收到消息后，完成业务并提交数据库事务。

整个过程，要保证尽一切可能完成，极端情况甚至需要人工介入。

优点：系统性能好（无需数据库锁）。

缺点：只能保证最终一致性，且可能需要人工介入。

适用场景：比如支付公司，交易后清分，便很适合通过可靠消息队列来解耦，能极大提升交易下单接口性能。

 

XA

通过数据库事务来实现。

优点：真正的数据库级别事务。

缺点：性能低。若A、B、C跨公司，则完全无法实现。

 

TCC

分为Try、Commit、Cancel两个阶段

先预留业务资源，成功则Commit，失败则Cancel。

优点：1. 提前预留资源，可以解决AT方案中资源可能无法回收的问题。

　　    2. 预留资源无需加锁操作，所以性能好。

缺点：1. 实现复杂，容易出错，且有些业务无法预留业务资源。

　　　2. try阶段对性能有损耗。

适用场景：通过账户交易下单类业务。比如将钱充值到加油App后，

通过App账户加油。（这个业务，必须先加油，再扣钱，所以必须锁住账户余额）

 

AT

A、B、C分别执行并提交本地数据库事务，当失败时，执行逆向SQL。这个方案，需要借助框架，逆向

SQL是框架自动生成且由框架自动执行。

优点：性能高，业务端实现简单。

缺点：由于没有预留业务资源，可能导致资源无法回收。

适用场景：公司内部系统，跨公司系统无法使用。

 

SAGA

业务编排 + 反向补偿，反向补偿又分为实时补偿和定时补偿。

优点：性能高，跨公司事务也能支持。

缺点：可能出现业务无法补偿的情况，所以对业务编排有要求。

适用场景：跨公司类的长事务业务。