从如何保证事务到如何保证分布式事务
事务特性
保证事务就是需要保证能实现这些事务特性
- 原子性
- 一致性
- 隔离性
- 持久性
本地事务如何保证
为什么会产生分布式事务
分布式事务如何保证
XA协议如何保证
- prepare和commit两阶段保证原子性
- 第一阶段中RM超时,按失败处理,对所有RM执行回滚
- 第二阶段中RM超时,持续对超时RM重复发送指令
TCC协议如何保证
XA和TCC的区别
- XA的思想是在资源管理层面将多个本地事务连通为一个全局事务
- 事务过程中会一直持有资源的锁,当RM过多时,系统吞吐量明显下降
- TM为单机,会有单点故障的问题
- TCC的核心思想是为资源预留中间态,比如冻结金额,提早释放资源的锁定,因此不会长时间持有资源的锁,拥有更高的吞吐量
- TCC在业务层面实现,因此对业务有较大的侵入
- 考虑到网络通信的原因,要求业务接口满足三点:允许空回滚,保持幂等性,防止资源悬挂
Saga协议如何保证
- 基于事务链的补偿性事务
- 事务链中的每一个事务通过提供一个逆向事务来补偿
- 当其中一个事务失败时,便沿着事务链进行逆向补偿,若补偿失败则一直重试
- 不保证事务隔离性,需要从业务上去规避:比如订票退款场景,退款了,但另外用户仍然看不到票
- 由于是一阶段提交,不存在对资源的长时间加锁,因此性能和吞吐量都非常高
基于事务消息
- 事务消息和本地消息要解决的核心问题都是本地事务与消息发送的一致性问题
- RocketMQ是目前为数不多能够支持事务消息的MQ
- 基于两阶段提交和定时任务回查
基于本地消息
- 消息记录在数据库中,通过定时任务扫描出待发送的记录交MQ
分布式事务中间件 Seata
- 支持TCC和Saga两种协议
- 针对TCC提供了一种业务侵入度为0的模式:AT(Automatic Transaction)
- AT模式的实现通过对SQL的执行进行代理和拦截,记录SQL执行前后的数据快照,记录在单独的表中,confirm则删除快照,cancel则通过快照进行恢复