最近看了几篇有关于分布式事务的博文，做了一下笔记，并总结出这篇文章。
图片来自 Pexels
数据库事务
数据库事务(简称：事务)，是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。
这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。
数据库事务的几个典型特性：
简称就是 ACID：
事务的实现原理
本地事务
传统的单服务器，单关系型数据库下的事务，就是本地事务。本地事务由资源管理器管理，JDBC 事务就是一个非常典型的本地事务。
事务日志
InnoDB 事务日志包括 redo log 和 undo log。
redo log(重做日志)：通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样，它用来恢复提交后的物理数据页。
undo log(回滚日志)：是逻辑日志，和 redo log 记录物理日志的不一样。
可以这样认为，当 delete 一条记录时，undo log 中会记录一条对应的 insert 记录，当 update 一条记录时，它记录一条对应相反的 update 记录。
事务 ACID 特性的实现思想：
分布式事务
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单来说，分布式事务指的就是分布式系统中的事务，它的存在就是为了保证不同数据库节点的数据一致性。
为什么需要分布式事务?接下来分两方面阐述：
微服务架构下的分布式事务
随着互联网的快速发展，轻盈且功能划分明确的微服务，登上了历史舞台。
比如，一个用户下订单，购买直播礼物的服务，被拆分成三个 service，分别是金币服务(coinService)，下订单服务(orderService)、礼物服务(giftService)。
这些服务都部署在不同的机器上(节点)，对应的数据库(金币数据库、订单数据库、礼物数据库)也在不同节点上。
用户下单购买礼物，礼物数据库、金币数据库、订单数据库在不同节点上，用本地事务是不可以的，那么如何保证不同数据库(节点)上的数据一致性呢?这就需要分布式事务啦!
分库分表下的分布式事务
随着业务的发展，数据库的数据日益庞大，超过千万级别的数据，我们就需要对它分库分表(以前公司是用 Mycat 分库分表，后来用 Sharding-JDBC)。
一分库，数据又分布在不同节点上啦，比如有的在深圳机房，有的在北京机房~你再想用本地事务去保证，已经无动于衷啦~还是需要分布式事务啦。
比如 A 转 10 块给 B，A 的账户数据是在北京机房，B 的账户数据是在深圳机房。
流程如下：
CAP 理论&BASE 理论
学习分布式事务，当然需要了解 CAP 理论和BASE 理论。
CAP 理论
CAP 理论作为分布式系统的基础理论，指的是在一个分布式系统中， Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)，这三个要素最多只能同时实现两点。
一致性(C，Consistency)：一致性是指数据在多个副本之间能否保持一致的特性。
例如一个数据在某个分区节点更新之后，在其他分区节点读出来的数据也是更新之后的数据。
可用性(A：Availability)：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是"有限时间内"和"返回结果"。
分区容错性(P，Partition tolerance)：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务。
BASE 理论
BASE 理论， 是对 CAP 中 AP 的一个扩展，对于我们的业务系统，我们考虑牺牲一致性来换取系统的可用性和分区容错性。
BASE 是 Basically Available(基本可用)，Soft State(软状态)和 Eventually Consistent(最终一致性)三个短语的缩写。
Basically Available：基本可用。通过支持局部故障而不是系统全局故障来实现的。
如将用户分区在 5 个数据库服务器上，一个用户数据库的故障只影响这台特定主机那 20% 的用户，其他用户不受影响。
Soft State：软状态。状态可以有一段时间不同步。
Eventually Consistent：最终一致。最终数据是一致的就可以了，而不是时时保持强一致。
分布式事务的几种解决方案
分布式事务解决方案主要有以下这几种：
二阶段提交方案
二阶段提交方案是常用的分布式事务解决方案。事务的提交分为两个阶段：准备阶段和提交执行方案。
二阶段提交成功的情况：
如图：
二阶段提交失败的情况：
资源管理器根据事务管理器的指令回滚本地事务操作，释放所有事务处理过程中使用的锁资源 。
2PC 方案实现起来简单，成本较低，但是主要有以下缺点：
TCC(补偿机制)
TCC 采用了补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿(撤销)操作。
TCC(Try-Confirm-Cancel)是通过对业务逻辑的分解来实现分布式事务。
针对一个具体的业务服务，TCC 分布式事务模型需要业务系统都实现一下三段逻辑：
TCC 分布式事务模型包括如下三部分：
下面再拿用户下单购买礼物作为例子来模拟 TCC 实现分布式事务的过程：假设用户 A 余额为 100 金币，拥有的礼物为 5 朵。A 花了 10 个金币，下订单，购买 10 朵玫瑰。余额、订单、礼物都在不同数据库。
TCC 的 Try 阶段：
TCC 的 Confirm 阶段：
TCC 的 Cancel 阶段：
TCC 方案让应用可以自定义数据库操作的粒度，降低了锁冲突，可以提升性能。
但是也有以下缺点：
本地消息表
eBay 最初提出本地消息表这个方案，来解决分布式事务问题。业界目前使用这种方案是比较多的，它的核心思想就是将分布式事务拆分成本地事务进行处理。
可以看一下基本的实现流程图：
基本实现思路如下。
发送消息方：
消息消费方：
生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。
优缺点：该方案的优点是很好地解决了分布式事务问题，实现了最终一致性。缺点是消息表会耦合到业务系统中。
最大努力通知
什么是最大通知?最大努力通知也是一种分布式事务解决方案。
下面是企业网银转账一个例子：
最大努力通知方案的目标，就是发起通知方通过一定的机制，最大努力将业务处理结果通知到接收方。
最大努力通知实现机制如下：
最大努力通知解决方案：要实现最大努力通知，可以采用 MQ 的 ACK 机制。
方案如下：
转账业务实现流程图：
交互流程如下：
Saga 事务
Saga 事务由普林斯顿大学的 Hector Garcia-Molina 和 Kenneth Salem 提出。
其核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。
Saga 简介：
Saga 的执行顺序：
Saga 两种恢复策略：
举个例子，假设用户下订单，花 10 块钱购买了 10 多玫瑰，则有：
假设事务执行到 T4 发生异常回滚，在 C4 的要把玫瑰给库存加回去的时候，发现用户的玫瑰都用掉了，这是 Saga 的一个缺点，由于事务之间没有隔离性导致的问题。
可以通过以下方案解决这个问题：
参考与感谢：
京公网安备 11010802035086号