博客

2PC模式 (XA Transactions)

核心：事务协调器，协调是否提交和回滚

2PC(2 phrase commit

二阶段提交

)，又叫做：XA Transactions

MySQL从5.5版本开始支持，SQL Server 2005开始支持，Oracle 7 开始支持。

其中，XA 是一个二阶段提交协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及事务的数据库预提交(precommit)此操作，并反映是否可以提交。

第二阶段：事务协调器要求每个数据库提交数据。

其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。

2PC模式在高并发场景下的不太理想，分布式场景下并不会选择这种模式

柔性事务-TCC事务补偿型方案

核心：自己实现回滚业务

刚性事务：遵循ACID原则，强一致性。

柔性事务：遵循BASE理论，最终一致性。

与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致性。

try代码模块中需要自己编写业务逻辑，Confirm代码块中会提交数据，那么在Cancel中则需要编写回滚逻辑。

柔性事务-最大努力通知型事务

核心：异步回调通知，同步数据

按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通信时，比如：调用微信或者支付宝支付后的支付结果。这种方案也是结合MQ进行实现，例如：通过MQ发送Http请求，设置最大通知次数。达到通知次数后即不再通知。

案例：银行通知、商户通知等(各大交易业务平台间的商户通知：多次通知、查询核对、对账文件)，支付宝的支付成功异步回调。

柔性事务-可靠消息+最终一致性方案（异步确保型）

核心：子业务失败，主业务发送异步消息通知回滚

实现：业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才会真正发送。