分布式事务八股文

分布式事务八股文

分布式事务的实现方式主要有以下几种:

1. 两阶段提交(2PC, Two-Phase Commit)

原理

> 这个两阶段提交,跟 Mysql redolog 和 binlog 这个两阶段提交完全不是一个东西(MySQL-基础概念篇-1-日志)。注意区分

2. 三阶段提交(3PC, Three-Phase Commit)

原理


3. 本地消息表(异步保证最终一致性)

原理

这种方式说白了就是 A 的事务先提交,然后 rpc 到 B 进行不停地重试,这个很基础很原始,不推荐使用。


4. TCC(Try-Confirm-Cancel)

原理

假设订单跟库存是两个服务。
我理解的两阶段提交,分布式事务,首先 a 想要创建订单就,rpc 到 b 扣库存,扣成功,并记录状态为预扣,然后通知 a 可以创建订单了,a 把订单创建成功了,再把库存扣件日志设置为提交,如果一个库存的记录一直都是预扣状态,超过一段时间,这个库存就会加回去。
这个其实就是 TCC 模型

TCC 更像将下单支付场景,进行了抽象,跟分布式事务并没有直接的联系,分成了尝试下单(try),成功下单(confirm),下单失败(cancel)三种状态,
大多数的支付场景,都有超时未支付自动取消订单的提示
而如果是分布式的场景,即订单服务和库存是两个微服务。这才跟分布式扯上关系。不过依然需要一个事务的协调者,这个时候,其实就跟两阶段提交没啥区别了,两阶段提交会有的问题,TCC 在分布式下也会有

在分布式架构中,需要一个 TCC 事务管理器 来协调订单和库存服务。可以使用:

分布式事务 Seata 及其三种模式详解

5. Saga(长事务模式)

原理

Saga 跟 TCC 还有两阶段提交不一样的是,saga 是将任务分为一个一个的,然后一个一个的执行,而 TCC 是将任务分成阶段,多个任务在一个阶段一起 try,然后都成功了,再一起 confirm,否则,就一起 cancel
就是很像拆分和竖向拆分的意思,

但是只要涉及到分布式的处理,就需要一个中心化的事务协调者,比如 seata


6. 基于 MQ 的事务消息(可靠事件模式)

原理

优点

缺点


总结

方案 一致性 事务类型 适用场景 复杂度
2PC 强一致性 短事务 银行转账等强一致性要求的场景
3PC 强一致性 短事务 改进 2PC,但仍有不一致风险
本地消息表 最终一致性 长事务 订单、支付、库存扣减
TCC 强一致性 短事务 需要预留资源的事务,如机票预订
Saga 最终一致性 长事务 订单、物流等长事务
事务消息(MQ) 最终一致性 长事务 高并发、异步场景

不同业务场景适用不同的分布式事务方案,比如:

你目前的业务场景是怎样的?如果需要支持高并发(如 70000QPS),本地消息表、TCC 或 MQ 事务消息可能是更合适的选择。