前世今生: 分布式事务1

Posted 2021-05-03 大魏分享

要搞清分布式事务，我们先想一个问题，分布式事务产生的原因是什么？

如图所示：

CP是在保证数据强一致性前提下，尽量实现高可用（如过半写入）。

AP是在保证高可用的前提下，尽量实现数据一致性（如异步一致）。

在ACID里，I是最难实现的。Isolation包含四个层级，如下表所示。在XA中，一般可以做到RC就可以了。

事务隔离级别	事务隔离描述	解决的问题	不能解决的问题
最低1	Read Uncommitted	无	脏读
2	Read Committed	脏读	不可重复读
3	Repeated  Read	脏读、不可重复读	幻读
最高4	Serialization	脏读、不可重复读、幻读	无

对于mysql而言，它是通过RC+MVCC实现RR的效果。但ACID整体上是不靠谱的，为啥？

因为ACID只是满足数据隔离性，但没有做法并发控制。

如果面向于实际使用场景，我们把上图分布式实现区分一下，结果如下：

也就是说，真实分布式场景中，80%是柔性事物，20%是刚性事务，即使在金融行业，也是这样。刚性事务通过2PC实现；柔性事物同步模式通过Sagas实现，异步模式通过事务消息实现。

我们先看一下刚性事务的最终实现：2PC。如下图所示。在下图中，RM管理共享资源，如DB。TM负责管理全局事务，如分配事务唯一标识、监控事务的执行进度、并负责事务的提交、回滚、失败、恢复等。

2PC的缺点在于：它是同步阻塞模型、数据库锁定时间过长、全局锁（隔离级别串行化）并发低、不适合长事务场景（RM特别多的情况）。

3PC没有安全解决2PC的问题，但又引入了新的问题。由于实际场景几乎没人使用，因此我不做介绍。

在介绍了刚性事务2PC后，接下来我们介绍柔性事务。柔性事物的理念是BASE。

BASE理论指的是：

• Basically Available（基本可用）

• Soft state（柔性状态--->中间状态：业务中间态、数据中间态）

• Eventually consistent（最终一致性）

我们举一个数据中间态的例子。一个转账业务，我们给转账业务数据分成两部分：可用金额要和冻结金额

接下来，我们看柔性事物的实现，先看Saga。

Saga本质是将一个分布式事务分为多个本地事务。每个本地事务只有执行和补偿。我们拿银行业余来说，有转账业务，转账业务的补偿事务就是：转账冲正，如下图所示。如果转账失败，就调用转账冲正进行事务补偿。

、

Saga的恢复模式分为：向后恢复（逆向补偿）和向前恢复（重试失败的事务）。

在隔离性方面，Sagas隔离是通过业务中间态实现的。例如金融系统的中间账户。

例如郭德纲向大魏转账，真实模式是：

郭德纲向中间账户转账失败，那么中间账户会删除记录。如果一段时间没删除，例如5s，那么中间账户就会想大魏转账。

前面提到的转账和冲正是互为逆方法。同样，CRUD中，insert和delete也是互为逆方法。因此我们需要为update操作提供逆方法。

那么，如何为update提供优雅的事务补偿呢？使用Seata AT。Seata AT就是在Sagas的基础上实现了自动补偿。目前自动补偿的方案都是往这个方向努力，看谁支持的 sql 语法更多，支持的db类型更多。

Seata AT实现的方法如下图：

未完待续...