乐趣区

关于分布式事务:分布式事务一数据库事务分布式事务

jiezi

数据库事务

数据库事务由一组 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 和 可靠消息最终一致性 三个计划进行实际。

退出移动版