分布式事务

分布式事务

几种思路

基于校对（被动方校对+服务操作可查询）

主动方在本地事务中执行自己的业务逻辑，并向被动方传递消息。（问题，如何保证消息在事务提交后才发送？？？）

不关心被动方的执行。

如果消息丢失，被动方通过回查主动方恢复消息。

成本：

设计一个校对系统。

设计服务操作查询系统。

使用范围：

跨企业的业务活动。如对接第三方的支付。

对业务最终一致性的时间敏感度低。

保证消息在事务提交后才发送

基于可靠消息（主动方维护可靠消息系统+幂等性操作原则）

基于半消息的处理方式（半事务消息+可靠状态确认+事务回查）

消息投递拆分为两部分，第一步先写消息，执行本地事务。

第二步投递消息。类似rocketmq的事务消息。本地事务执行成功则提交消息，失败则取消消息。

TCC

Try confirm/cancel

开发难度大，只适用于业务简单，对实时性要求高的场景。

Xa模式

两阶段提交

问题，阻塞问题

三阶段提交

增加询问阶段

增加解决两阶段提交中因为超时问题的处理机制

Seata

AT模式

这里的undolog不是数据库的undolog，使at模式下自定义的mysql表。

原理

第一阶段 执行本地事务

获取全局锁

事务提交并生成undolog日志。

释放全局锁

第二阶段 提交事务或回滚

通过undolog日志进行回滚，区别与传统的两阶段提交一直阻塞，性能会更好。

隔离性保证

写隔离（通过全局锁）

Tx1获取本地锁，并执行更新操作。

Tx1获取全局锁，并执行事务提交。

释放本地锁。 Tx2获取本地锁，并执行更新操作。

Tx2获取全局锁，并执行事务提交。

因为此时全局锁被tx1占用，尝试获取全局锁，会超时。

Tx1事务回滚，尝试获取本地锁。

此时本地锁被tx2占用，会一直重试，不会超时。 Tx2获取全局锁失败，超时释放。

Tx1获取本地锁并回滚。

因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生 脏写 的问题。##

读隔离（通过全局锁）

为什么全局事务默认使用读未提交？

Tx1获取本地锁，并执行更新操作。

Tx1获取全局锁，并执行事务提交。

释放本地锁。 Tx2执行查询操作，并为select for update生成代理。

Tx2尝试获取全局锁。

此时全局锁被tx1占用，尝试获取全局锁，会阻塞。

Tx1事务回滚。 Tx2获取到全局锁，读到tx1回滚的数据。

因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生 脏读 的问题。##

SEGA模式

事件/编排式

完成本地事务就发送一个事件，通知下一个事件进行处理，一直向下传递。直到最后一个本地事务执行完，整个事务执行完毕。

命令/回执模式

类似于模板方法，依次执行每部操作。