分布式事务（一）--数据库事务&分布式事务

数据库事务

数据库事务由一组sql语句组成。

所有sql语句执行成功则事务整体成功；任一条sql语句失败则事务整体失败，数据恢复到事务之前的状态。

下面以转账为例进一步说明。
A 账户向 B 账户转账，需要更新两个账户的记录：

- A 账户减金额
update user set money=money-100 where id='A'
- B 账户加金额
update user set money=money+100 where id='B' 

• 两条sql语句都成功则转账成功。
• 任意一条sql语句失败，恢复以前的状态。

数据操作的最小单元是事务，而不是一条sql语句！

Mysql 事务操作

开始事务

start transaction;
- 或
begin; 

事务开始后，对数据的增删改操作不直接修改数据表，而是被记录在日志文件中。

提交事务

commit; 

将日志中记录的操作，永久保存到数据表，并清空日志文件。

回滚事务

rollback;

直接清空日志文件

事务特性 ACID

A - 原子性 Atomic

一个事务是一个不可分割的工作单元，事务中包括的操作要么都做，要么都不做。

数据操作的最小单元是事务，而不是SQL语句 。

C - 一致性 Consistency

事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。

例如：

• 转账前 a+b = 100
• 转帐后 a+b = 100

I - 隔离性 Isolation

一个事务的执行不能被其他事务干扰。

即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

D - 持久性 Durancy

一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

数据库并发访问冲突问题

脏读

读取到其他事务未提交的数据。

不可重复读

• 重复读取同一数据时，与之前读取的数据不一致。
• 一个事务提交的数据，可以被另一个事务立即读取。

幻读

• 读取到已经被删除的数据。
• 读取不到新插入的数据。

Mysql 的四种事务隔离级别

事务之间为了避免互相干扰，执行时要进行隔离。也就是A执行时B要等待。但严格的隔离会造成性能的下降。

数据库为了兼顾数据安全和性能，可以在一定程度上允许多个事务并行执行。

Mysql 提供了四种隔离级别从低到高：

• READ-UNCOMMITTED
• READ-COMMITTED
• REPEATABLE-READ
• SERIALIZABLE

隔离级别越高数据越安全；越低性能越好，但会造成数据访问的问题：

可能引发的问题	READ-UNCOMMITTED	READ-COMMITTED	REPEATABLE-READ	SERIALIZABLE
幻读	√	√	√	×
不可重复读	√	√	×	×
脏读	√	×	×	×

Mysql 设置隔离级别

set tx_isolation='read-uncommitted';

set tx_isolation='read-committed';

# repeatable-read 是Mysql默认的隔离级别
set tx_isolation='repeatable-read';

set tx_isolation='serializable';

oracle mysql 8 使用 transaction_isolation 系统变量：

set transaction_isolation='read-uncommitted';

set transaction_isolation='read-committed';

# repeatable-read 是Mysql默认的隔离级别
set transaction_isolation='repeatable-read';

set transaction_isolation='serializable';

注意：set设置的变量只对当前会话有效。需要进行全局设置使用 set global

分布式事务

首先这是普通事务：

下面是分布式事务：

在微服务系统中，每个微服务应用都可能会有自己的数据库，它们首先需要控制自己的本地事务。

一项业务操作可能会调用执行多个微服务。如何保证多个服务执行的多个数据库的操作整体成功或整体失败？这就是分布式事务要解决的问题。

理论部分

CAP 和 BASE 是对大规模互联网系统分布式实践的理论总结，如果没有实践为基础理论则难以理解。

这里建议先对分布式事务进行实践，之后再来阅读理论来互相印证。

CAP

请参考 百度百科 - CAP原则。

在分布式系统中，由于网络原因出现子系统之间无法通信的情况，就会造成分区。一般分布式系统中必须容忍这种情况，那么就需要在A和C之间进行取舍。

在分布式事务中，

• 如果保证CP，就意味着要让所有子系统的数据操作要么全部成功，要么全部失败，不允许有不一致的情况发生。但是强一致性会造成性能下降。
• 如果保证AP，就意味着可以牺牲一定的一致性，允许在各个子系统中存在有的数据操作成功，有的数据操作失败的情况，只要通过后续处理，能够达到最终一致即可。

BASE

参考 百度百科 - BASE
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。

BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。
注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子：

• 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
• 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
• 弱状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• 最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

分布式事务方案

分布式事务有以下解决方案：

• XA
• TCC
• Seata 框架 AT 事务
• SAGA
• 可靠消息最终一致性
• 最大努力通知

后面我们会对 Seata 框架 AT 事务、TCC 和 可靠消息最终一致性 三个方案进行实践。