乐趣区

关于分布式事务:一天吃透分布式事务面试八股文

jiezi

本文曾经收录到 Github 仓库，该仓库蕴含 计算机根底、Java 根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享 等外围知识点，欢送 star~

Github 地址：https://github.com/Tyson0314/Java-learning

简介

事务

事务是应用程序中一系列紧密的操作，所有操作必须胜利实现，否则在每个操作中所作的所有更改都会被吊销。也就是事务具备原子性，一个事务中的一系列的操作要么全副胜利，要么一个都不做。事务应该具备 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 个性。

分布式事务

分布式事务是指事务的参与者，反对事务的服务器，资源服务器以及事务管理器别离位于分布式系统的不同节点之上。通常一个分布式事务中会波及对多个数据源或业务零碎的操作。分布式事务也能够被定义为一种嵌套型的事务，同时也就具备了 ACID 事务的个性。

强一致性、弱一致性、最终一致性

强一致性

任何一次读都能读到某个数据的最近一次写的数据。零碎中的所有过程，看到的操作程序，都和全局时钟下的程序统一。简言之，在任意时刻，所有节点中的数据是一样的。

弱一致性

数据更新后，如果能容忍后续的拜访只能拜访到局部或者全副拜访不到，则是弱一致性。

最终一致性

不保障在任意时刻任意节点上的同一份数据都是雷同的，然而随着工夫的迁徙，不同节点上的同一份数据总是在向趋同的方向变动。简略说，就是在一段时间后，节点间的数据会最终达到统一状态。

因为分布式事务计划，无奈做到齐全的 ACID 的保障，没有一种完满的计划，可能解决掉所有业务问题。因而在理论利用中，会依据业务的不同个性，抉择最适宜的分布式事务计划。

分布式事务的根底

CAP 实践

Consistency（一致性）：数据统一更新，所有数据变动都是同步的（强一致性）。

Availability（可用性）：好的响应性能。

Partition tolerance（分区容错性）：可靠性。

定理：任何分布式系统 只可同时满足二点，没法三者兼顾。

CA 零碎（放弃 P）：指将所有数据（或者仅仅是那些与事务相干的数据）都放在一个分布式节点上，就不会存在网络分区。所以强一致性以及可用性失去满足。

CP 零碎（放弃 A）：如果要求数据在各个服务器上是强统一的，然而网络分区会导致同步工夫有限缩短，那么如此一来可用性就得不到保障了。保持事务 ACID（原子性、一致性、隔离性和持久性）的传统数据库以及对后果一致性十分敏感的利用通常会做出这样的抉择。

AP 零碎（放弃 C）：这里所说的放弃一致性，并不是齐全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。如果即要求零碎高可用又要求分区容错，那么就要放弃一致性了。因为一旦产生网络分区，节点之间将无奈通信，为了满足高可用，每个节点只能用本地数据提供服务，这样就会导致数据不统一。一些恪守 BASE 准则数据库，（如：Cassandra、CouchDB 等）往往会放宽对一致性的要求（满足最终一致性即可），一次来获取根本的可用性。

BASE 实践

BASE 是 Basically Available(根本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对 CAP 中 AP 的一个扩大。

  1. 根本可用: 分布式系统在呈现故障时，容许损失局部可用性能，保障外围性能可用。
  2. 软状态: 容许零碎中存在中间状态，这个状态不影响零碎可用性，这里指的是 CAP 中的不统一。
  3. 最终统一: 最终统一是指通过一段时间后，所有节点数据都将会达到统一。

BASE 解决了 CAP 中实践没有网络提早，在 BASE 中用软状态和最终统一，保障了提早后的一致性。BASE 和 ACID 是相同的，它齐全不同于 ACID 的强一致性模型，而是通过就义强一致性来取得可用性，并容许数据在一段时间内是不统一的，但最终达到统一状态。

分布式事务解决方案

分布式事务的实现次要有以下 6 种计划：

  • 2PC 计划
  • TCC 计划
  • 本地音讯表
  • MQ 事务
  • Saga 事务
  • 最大致力告诉计划

2PC 计划

2PC 计划分为两阶段:

第一阶段：事务管理器要求每个波及到事务的数据库预提交 (precommit) 此操作，并反映是否能够提交.

第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据。

长处：尽量保障了数据的强统一，实现老本较低，在各大支流数据库都有本人实现，对于 MySQL 是从 5.5 开始反对。

毛病:

  • 单点问题: 事务管理器在整个流程中表演的角色很要害，如果其宕机，比方在第一阶段曾经实现，在第二阶段正筹备提交的时候事务管理器宕机，资源管理器就会始终阻塞，导致数据库无奈应用。
  • 同步阻塞: 在准备就绪之后，资源管理器中的资源始终处于阻塞，直到提交实现，开释资源。
  • 数据不统一: 两阶段提交协定尽管为分布式数据强一致性所设计，但依然存在数据不一致性的可能，比方在第二阶段中，假如协调者收回了事务 commit 的告诉，然而因为网络问题该告诉仅被一部分参与者所收到并执行了 commit 操作，其余的参与者则因为没有收到告诉始终处于阻塞状态，这时候就产生了数据的不一致性。

总的来说，2PC 计划比较简单，老本较低，然而其单点问题，以及不能反对高并发（因为同步阻塞）仍然是其最大的弱点。

TCC

TCC 的全称是：Try、Confirm、Cancel。

  • Try 阶段 ：这个阶段说的是对各个服务的资源做检测以及对资源进行 锁定或者预留。
  • Confirm 阶段：这个阶段说的是在各个服务中执行理论的操作。
  • Cancel 阶段 ：如果任何一个服务的业务办法执行出错，那么这里就须要 进行弥补，就是执行曾经执行胜利的业务逻辑的回滚操作。（把那些执行胜利的回滚）

举个简略的例子如果你用 100 元买了一瓶水，Try 阶段: 你须要向你的钱包查看是否够 100 元并锁住这 100 元，水也是一样的。

如果有一个失败，则进行 cancel(开释这 100 元和这一瓶水)，如果 cancel 失败不论什么失败都进行重试 cancel，所以须要放弃幂等。

如果都胜利，则进行 confirm, 确认这 100 元扣，和这一瓶水被卖，如果 confirm 失败无论什么失败则重试(会依附流动日志进行重试)。

这种计划说实话简直很少人应用，然而也有应用的场景。因为这个 事务回滚实际上是重大依赖于你本人写代码来回滚和弥补 了，会造成弥补代码微小。

本地音讯表

本地音讯表的外围是将须要分布式解决的工作通过消息日志的形式来异步执行。消息日志能够存储到本地文本、数据库或音讯队列，再通过业务规定主动或人工发动重试。人工重试更多的是利用于领取场景，通过对账系统对预先问题的解决。

对于本地音讯队列来说外围是把大事务转变为小事务。还是举下面用 100 元去买一瓶水的例子。

1. 当你扣钱的时候，你须要在你扣钱的服务器上新减少一个本地音讯表，你须要把你扣钱和写入减去水的库存到本地音讯表放入同一个事务(依附数据库本地事务保障一致性。

2. 这个时候有个定时工作去轮询这个本地事务表，把没有发送的音讯，扔给商品库存服务器，叫他减去水的库存，达到商品服务器之后这个时候得先写入这个服务器的事务表，而后进行扣减，扣减胜利后，更新事务表中的状态。

3. 商品服务器通过定时工作扫描音讯表或者间接告诉扣钱服务器，扣钱服务器本地音讯表进行状态更新。

4. 针对一些异常情况，定时扫描未胜利解决的音讯，进行从新发送，在商品服务器接到音讯之后，首先判断是否是反复的，如果曾经接管，在判断是否执行，如果执行在马上又进行告诉事务，如果未执行，须要从新执行须要由业务保障幂等，也就是不会多扣一瓶水。

本地音讯队列是 BASE 实践，是最终统一模型，实用于对一致性要求不高的。实现这个模型时须要留神重试的幂等。

MQ 事务

基于 MQ 的分布式事务计划其实是对本地音讯表的封装，将本地音讯表基于 MQ 外部，其余方面的协定根本与本地音讯表统一。

MQ 事务计划整体流程和本地音讯表的流程很类似，如下图：

从上图能够看出和本地音讯表计划惟一不同就是将本地音讯表存在了 MQ 外部，而不是业务数据库中。

那么 MQ 外部的解决尤为重要，上面次要基于 RocketMQ 4.3 之后的版本介绍 MQ 的分布式事务计划。

在本地音讯表计划中，保障事务被动方发写业务表数据和写音讯表数据的一致性是基于数据库事务，RocketMQ 的事务音讯绝对于一般 MQ 提供了 2PC 的提交接口，计划如下：

失常状况：事务被动方发消息

这种状况下，事务被动方服务失常，没有产生故障，发消息流程如下：

  • 发送方向 MQ 服务端 (MQ Server) 发送 half 音讯。
  • MQ Server 将音讯长久化胜利之后，向发送方 ack 确认音讯曾经发送胜利。
  • 发送方开始执行本地事务逻辑。
  • 发送方依据本地事务执行后果向 MQ Server 提交二次确认（commit 或是 rollback）。
  • MQ Server 收到 commit 状态则将半音讯标记为可投递，订阅方最终将收到该音讯；MQ Server 收到 rollback 状态则删除半音讯，订阅方将不会承受该音讯。

异常情况：事务被动方音讯复原

在断网或者利用重启等异常情况下，图中 4 提交的二次确认超时未达到 MQ Server，此时解决逻辑如下：

  • MQ Server 对该音讯发动音讯回查。
  • 发送方收到音讯回查后，须要查看对应音讯的本地事务执行的最终后果。
  • 发送方依据查看失去的本地事务的最终状态再次提交二次确认。
  • MQ Server 基于 commit/rollback 对音讯进行投递或者删除。

长处

相比本地音讯表计划，MQ 事务计划长处是：

  • 音讯数据独立存储，升高业务零碎与音讯零碎之间的耦合。
  • 吞吐量大于应用本地音讯表计划。

毛病

  • 一次音讯发送须要两次网络申请(half 音讯 + commit/rollback 音讯)。
  • 业务解决服务须要实现音讯状态回查接口。

Saga 事务

Saga 是由一系列的本地事务形成。每一个本地事务在更新完数据库之后，会公布一条音讯或者一个事件来触发 Saga 中的下一个本地事务的执行。如果一个本地事务因为某些业务规定无奈满足而失败，Saga 会执行在这个失败的事务之前胜利提交的所有事务的弥补操作。

Saga 的实现有很多种形式，其中最风行的两种形式是：

  • 基于事件的形式。这种形式没有协调核心，整个模式的工作形式就像舞蹈一样，各个舞蹈演员依照事后编排的动作和走位各自表演，最终造成一只舞蹈。处于以后 Saga 下的各个服务，会产生某类事件，或者监听其它服务产生的事件并决定是否须要针对监听到的事件做出响应。
  • 基于命令的形式。这种形式的工作模式就像一只乐队，由一个指挥家（协调核心）来协调大家的工作。协调核心来通知 Saga 的参与方应该执行哪一个本地事务。

最大致力告诉计划

最大致力告诉也称为定期校对，是对 MQ 事务计划的进一步优化。它在事务被动方减少了音讯校对的接口，如果事务被动方没有接管到音讯，此时能够调用事务被动方提供的音讯校对的接口被动获取。

最大致力告诉的整体流程如下图：

在可靠消息事务中，事务被动方须要将音讯发送进来，并且音讯接管方胜利接管，这种可靠性发送是由事务被动方保障的；

然而最大致力告诉，事务被动方尽最大致力（重试，轮询 ….）将事务发送给事务接管方，然而依然存在音讯接管不到，此时须要事务被动方被动调用事务被动方的音讯校对接口查问业务音讯并生产，这种告诉的可靠性是由事务被动方保障的。

最大致力告诉实用于业务告诉类型，例如微信交易的后果，就是通过最大致力告诉形式告诉各个商户，既有回调告诉，也有交易查问接口。

最初给大家分享一个 Github 仓库，下面有大彬整顿的 300 多本经典的计算机书籍 PDF，包含 C 语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构和算法、机器学习、编程人生 等，能够 star 一下，下次找书间接在下面搜寻，仓库继续更新中~

Github 地址：https://github.com/Tyson0314/java-books

退出移动版