你再不知道分布式事务，我就真的生气了 _分布式事务

最近看了几篇有关于分布式事务的博文，做了一下笔记，并总结出这篇文章。

文章插图

图片来自 Pexels

文章插图

数据库事务
数据库事务(简称：事务)，是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。
这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。
数据库事务的几个典型特性：

原子性(Atomicity)
一致性(Consistency)
隔离性(Isolation)
持久性(Durabilily)

文章插图

简称就是 ACID：

原子性：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
一致性：指在事务开始之前和事务结束以后，数据不会被破坏，假如 A 账户给 B 账户转 10 块钱，不管成功与否，A 和 B 的总金额是不变的。
隔离性：多个事务并发访问时，事务之间是相互隔离的，即一个事务不影响其它事务运行效果。简言之，就是事务之间是进水不犯河水的。
持久性：表示事务完成以后，该事务对数据库所作的操作更改，将持久地保存在数据库之中。

事务的实现原理
本地事务
传统的单服务器，单关系型数据库下的事务，就是本地事务。本地事务由资源管理器管理，JDBC 事务就是一个非常典型的本地事务。

文章插图

事务日志
InnoDB 事务日志包括 redo log 和 undo log 。
redo log(重做日志)：通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样，它用来恢复提交后的物理数据页。
undo log(回滚日志)：是逻辑日志，和 redo log 记录物理日志的不一样。
可以这样认为，当 delete 一条记录时，undo log 中会记录一条对应的 insert 记录，当 update 一条记录时，它记录一条对应相反的 update 记录。
事务 ACID 特性的实现思想：

原子性：是使用 undo log 来实现的，如果事务执行过程中出错或者用户执行了 rollback，系统通过 undo log 日志返回事务开始的状态。
持久性：使用 redo log 来实现，只要 redo log 日志持久化了，当系统崩溃，即可通过 redo log 把数据恢复。
隔离性：通过锁以及 MVCC，使事务相互隔离开。
一致性：通过回滚、恢复，以及并发情况下的隔离性，从而实现一致性。

分布式事务
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单来说，分布式事务指的就是分布式系统中的事务，它的存在就是为了保证不同数据库节点的数据一致性。
为什么需要分布式事务?接下来分两方面阐述：
微服务架构下的分布式事务
随着互联网的快速发展，轻盈且功能划分明确的微服务，登上了历史舞台。
比如，一个用户下订单，购买直播礼物的服务，被拆分成三个 service，分别是金币服务(coinService)，下订单服务(orderService)、礼物服务(giftService) 。
这些服务都部署在不同的机器上(节点)，对应的数据库(金币数据库、订单数据库、礼物数据库)也在不同节点上。

文章插图

用户下单购买礼物，礼物数据库、金币数据库、订单数据库在不同节点上，用本地事务是不可以的，那么如何保证不同数据库(节点)上的数据一致性呢?这就需要分布式事务啦!
分库分表下的分布式事务
随着业务的发展，数据库的数据日益庞大，超过千万级别的数据，我们就需要对它分库分表(以前公司是用 Mycat 分库分表，后来用 Sharding-JDBC) 。
一分库，数据又分布在不同节点上啦，比如有的在深圳机房，有的在北京机房~你再想用本地事务去保证，已经无动于衷啦~还是需要分布式事务啦。
比如 A 转 10 块给 B，A 的账户数据是在北京机房，B 的账户数据是在深圳机房。
流程如下：