关于java:面试官亿级流量架构分布式事务如何实现我懵了

面试官：亿级流量架构分布式事务如何实现？我懵了。。

作者：等不到的口琴 \
起源：https://www.cnblogs.com/Coura…

分布式事务以及分布式锁是分布式中难点, 分布式事务一篇文章可能写不完, 我的习惯时从基本概念登程, 一步一步开始介绍, 后面会先梳理事务中一些基本概念, 对基本概念非常分明的话能够间接看 ” 一致性探讨 ” 以及前面的局部。予己方便总结回顾、与他交换分享。

什么是分布式事务

在日常生活中, 很多事要么全副做, 要么全副不做, 不能只做一部分, 不然就会产生其余简单的问题, 很多人喜爱举转账的例子, 对于同一个账号,A 在湖北往出转 500,B 在广东取钱 500, 那么 A 转出去之后要将 A 账号的钱数目扣除,B 账号数目减少: 事务 = (A 账号扣除 500,B 账号减少 500)

看到没, 像这样多个步骤放在一起, 就是事务, 要么都执行, 要么都不执行, 如果咱们的数据存储在多个数据库中, 也就是存在跨库调用, 因为网络具备不安全性以及延时性, 如何保障事务分布式执行呢? 如果执行到一半断电又该如何解决? 在解说分布式事务之前先简略回顾事务的一些特点, 俗称 ACID , 上面逐个解说:

原子性(Atomic)

在化学中, 分子形成的物质, 分子是放弃化学个性的最小单位, 如 H2O,CO2H2O,CO2 等, 由原子形成的物质, 原子放弃物质个性, 像 FeFe 啥的, 意思就是不可分割, 再分成质子中子啥的就不是咱们认为的物质了, 这儿的原子性也是这个情理, 就是事务不能够再拆分, 例如下面的事务, 看着能够是由两个过程组成的事务, 然而你拆开就不是咱们认为该有的过程, 所以, 事务不可再分, 具备原子性。

一致性（Consistency）

一致性也很好了解, 对于下面的两个账户, 如果银行想晓得本人这儿被存了多少钱, 那么这个事务执行前,A 账号有 500 块,B 账号没有钱, 银行账户总共 500 块, 事务执行后 A 账号没有钱,B 账号有 500 块, 也就是这个 500 块是肯定的, 不可能呈现 A 账号有 500 块,B 账号也有 500 块, 那就数据不统一了, 这样的话, 阐明事务中某些步骤执行呈现了问题, 产生两头数据, 那么就不统一。

在分布式中, 对于一个后果, 多处同时查问, 得出的后果应该是统一的。

隔离性（Isolation）

一个事务在未实现时，另一个事务不会影响到它, 也就是如果 B 还给 C 转账 1000, 记为事务 2:

事务 1 = (A 账号扣除 500,B 账号减少 500)

事务 2 = (B 账号扣除 1000,C 账号减少 1000)

这两个事务之间不会产生影响, 也就是不会产生 A 转出的 500 块达到 C 账号这种状况。

持久性（Durability）

长久化, 个别是意味着将数据写入磁盘, 不会轻易扭转的意思, 这儿是事务提交之后, 会影响到数据库, 不会失落。这也就意味着, 随着零碎越来越宏大，咱们为了进步可用性、维护性、吞吐量等等技术指标，就算改善原有架构，业务计算的问题解决后，数据库还是会成为整个零碎中的瓶颈。

一致性的探讨

ACID 实质而言都是为了爱护数据的一致性, 而数据数据长久化时会触发数据库操作, 造成效率低小, 所以围绕一致性 (效率) 产生了一些探讨, 别离是强一致性、弱一致性、最终一致性。

强一致性

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

弱一致性

数据更新后，不要求及时写会数据库以及同步到所有节点, 也就是这时候数据与实在数据可能有一些出入, 对于架构而言, 如果能容忍后续的拜访只能拜访到局部或者全副拜访不到，则是弱一致性。

最终一致性

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

三种一致性中, 强一致性数据更加牢靠, 然而因为时时刻刻要求所有数据库保持数据统一, 所以效率低下, 数据没有对立完, 申请就没法失去响应, 高并发场景下, 体验不太好, 所以在理论应用中, 依据不同的业务抉择是一致性也不同, 购物时账号付钱必定是强一致性, 然而商品库存数据就不肯定非要强一致性, 至于商品上面的评论啥的, 甚至能够抉择弱一致性。

分库分表

后面讲过集群的 AKF 拆分准则(Redis 集群拆分准则之 AKF), 大略意思是硬件性能是由下限的, 当硬件没法撑持申请流量时, 能够将流量散发到不同的服务器上,AKF 拆分之 Y 轴、Z 轴拆分是业务拆分与数据拆分, 那也就会波及到将数据库中的数据拆分存储在不同的中央, 这就叫分库分表, 不同类型数据存储在不同数据库中做多机存储和负载, 这样一来, 传统的事务机制 ACID 便无奈失常运行。

分库分表内容是数据切分（Sharding），以及切分后对数据的定位、整合。具体来说, 数据切分就是将数据扩散存储到多个数据库中，使得繁多数据库中的数据质变小，通过裁减主机的数量缓解繁多数据库性能问题，从而达到晋升数据库操作性能的目标。

数据切分依据其切分类型，能够分为两种形式：垂直（纵向）切分和程度（横向）切分。

垂直拆分

垂直切分常见有垂直分库和垂直分表两种, 两种含意相似。

垂直分库就是依据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大零碎拆分为多个小零碎相似，按业务分类进行独立划分。与 ” 微服务治理 ” 的做法类似，每个微服务应用独自的一个数据库。如图：

垂直分表相似, 例如将一张表蕴含一个人所有信息, 例如姓名、身份证、性别、身高、体重、省、市、区、村、业余、G 点等等, 那么能够拆分成三个表:

第一个表只蕴含根本信息(姓名、身份证、性别、身高、体重);

第二个表蕴含籍贯信息(省、市、区、村);

第三个表蕴含学习信息(业余、G 点)。

垂直拆分优缺点

垂直切分的长处：

• 解决业务零碎层面的耦合，业务清晰
• 与微服务的治理相似，也能对不同业务的数据进行分级管理、保护、监控、扩大等
• 高并发场景下，垂直切分肯定水平的晋升 IO、数据库连接数、单机硬件资源的瓶颈

垂直切分的毛病：

• 局部表无奈 join，只能通过接口聚合形式解决，晋升了开发的复杂度
• 分布式事务处理简单
• 仍然存在单表数据量过大的问题（须要程度切分）

程度拆分

上面对数据库垂直拆分之后, 如果某个库还是好大, 比方存储的数据极其宏大, 那么能够再对数据库进行程度的拆分:

下面的程度拆分时依照 ID 区间来切分。例如：将 userId 为 1~10000 的记录分到第一个库，10001~20000 的分到第二个库，以此类推。某种意义上，某些零碎中应用的 ” 冷热数据拆散 ”，将一些应用较少的历史数据迁徙到其余库中，业务性能上只提供热点数据的查问，也是相似的实际。

除了下面依照用户 ID 区间拆分, 也能够做 Hash 运算拆分, 这儿就不具体开展了。

程度拆分优缺点

程度拆分长处在于：

• 单表大小可控
• 人造便于程度扩大，前期如果想对整个分片集群扩容时，只须要增加节点即可，无需对其余分片的数据进行迁徙
• 应用分片字段进行范畴查找时，间断分片可疾速定位分片进行疾速查问，无效防止跨分片查问的问题。

程度拆分毛病：

• 热点数据成为性能瓶颈。间断分片可能存在数据热点，例如按工夫字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查问

分库分表带来的问题

分库分表能无效的缓解单机和单库带来的性能瓶颈和压力，冲破网络 IO、硬件资源、连接数的瓶颈，同时也带来了一些问题, 后面说过, 事务蕴含一组子操作, 这些造作要么全副执行, 要么全副不执行, 然而分库之后, 一个事务可能波及多个数据库或者多个表扩库执行, 而网络具备不稳定性, 也就是事务执行难度加大, 分表分库后事务为了与传统事务做出区别, 叫做分布式事务(跨分片事务)。

跨分片事务也是分布式事务，没有简略的计划，个别可应用 ”XA 协定 ” 和 ” 两阶段提交 ” 解决。

分布式事务能最大限度保障了数据库操作的原子性。但在提交事务时须要协调多个节点，推后了提交事务的工夫点，缩短了事务的执行工夫。导致事务在访问共享资源时发生冲突或死锁的概率增高。随着数据库节点的增多，这种趋势会越来越重大，从而成为零碎在数据库层面上程度扩大的桎梏。

最终一致性

对于那些性能要求很高，但对一致性要求不高的零碎，往往不奢求零碎的实时一致性，只有在容许的时间段内达到最终一致性即可，可采纳事务弥补的形式。与事务在执行中产生谬误后立刻回滚的形式不同，事务弥补是一种预先查看补救的措施，一些常见的实现办法有：对数据进行对账查看，基于日志进行比照，定期同规范数据起源进行同步等等。事务弥补还要联合业务零碎来思考。

分布式事务解决思路

讲这个之前须要先简略回顾 CAP 准则和 Base 实践, 因为分布式事务不同于 ACID 的刚性事务，在分布式场景下基于 BASE 实践，提出了柔性事务的概念。要想通过柔性事务来达到最终的一致性，就须要依赖于一些个性，这些个性在具体的计划中不肯定都要满足，因为不同的计划要求不一样；然而都不满足的话，是不可能做柔性事务的。

CAP 准则

CAP 个别人可能听了不下一百遍了, 很多人都说 CAP 是 ” 三选二 ” 的关系, 让人误以为有 AC 这种状况, 然而理论 CAP 是二选一的关系, 这个在 2012 年曾经有一篇论文进行解释: CAP Twelve Years Later: How the “Rules” Have Changed

相当于是对之前三选二说法进行修改,CAP 中 P(分区容错性)是必须具备的, 在满足 P 的前提下, 很难同时满足 A(可用性)和 C(一致性), 然而在之后, 又有一篇文章: Harvest, yield, and scalable tolerant systems , 这篇论文是基于下面那篇“CAP 12 年后”的论文写的，它次要提出了 Harvest 和 Yield 概念，并把下面那篇论文中所探讨的货色讲得更为认真了一些。简略来说就是满足 P 之后,C 和 A 在放宽束缚后能够失去兼顾, 并不是非此即彼的关系, 说远了。

为什么 P 是必须的?

为什么 CAP 准则中分区容错性是必须的呢, 首先要了解什么是分区容错性, 分区, 这儿说的是网络, 网络集群设计到很多的服务器, 某一瞬间网络不稳固, 那么相当于将网络分成了不同的区, 假如分成了两个区, 这时候如果有一笔交易:

对分区一收回音讯:A 给 B 转账 100 元, 对分区二收回音讯:A 给 B 转账 200 元

那么对于两个分区而言, 有两种状况:

a）无可用性，即这两笔交易至多会有一笔交易不会被承受；

b）无一致性，一半看到的是 A 给 B 转账 100 元而另一半则看到 A 给 B 转账 200 元。

所以, 分区容忍性必须要满足, 解决策略是一个数据项复制到多个节点上，那么呈现分区之后，这一数据项就可能散布到各个区里。容忍性就进步了。

Base 实践

在很多时候，咱们并不需要强一致性的零碎，所以起初，人们争执对于数据一致性和可用性时，次要是集中在强一致性的 ACID 或最终一致性的 BASE 中, BASE 是对 CAP 中一致性和可用性衡量的后果，其来源于对大规模互联网分布式系统实际的总结，是基于 CAP 定律逐渐演变而来。其核心思想是即便无奈做到强一致性，但每个利用都能够依据本身业务特点，才用适当的形式来使零碎打到最终一致性。

BASE 实践是 Basically Available(根本可用)，Soft State（软状态）和 Eventually Consistent（最终一致性）三个短语的缩写。

根本可用

假如零碎，呈现了不可预知的故障，但还是能用，相比拟失常的零碎而言：

1. 响应工夫上的损失：失常状况下的搜索引擎 0.5 秒即返回给用户后果，而根本可用的搜索引擎能够在 2 秒作用返回后果。
2. 性能上的损失：在一个电商网站上，失常状况下，用户能够顺利完成每一笔订单。然而到了大促期间，为了爱护购物零碎的稳定性，局部消费者可能会被疏导到一个降级页面。

这就叫根本可用

软状态

绝对于原子性而言，要求多个节点的数据正本都是统一的，这是一种“硬状态”。软状态指的是：容许零碎中的数据存在中间状态，并认为该状态不影响零碎的整体可用性，即容许零碎在多个不同节点的数据正本存在数据延时。

最终一致性

下面说软状态，而后不可能始终是软状态，必须有个工夫期限。在期限过后，该当保障所有正本保持数据一致性，从而达到数据的最终一致性。这个工夫期限取决于网络延时、零碎负载、数据复制方案设计等等因素。

Base 其核心思想是：

既然无奈做到强一致性（Strong consistency），但每个利用都能够依据本身的业务特点，采纳适当的形式来使零碎达到最终一致性（Eventual consistency）。有了 Base 实践就能够开始讲述分布式事务的解决思路了。

二阶段提交协定

二阶段提交 (2PC：Two-Phase Commit), 顾名思义，该协定将一个分布式的事务过程拆分成两个阶段： 投票 和 事务提交 。为了让整个数据库集群可能失常的运行，该协定指定了一个 协调者 单点，用于协调整个数据库集群各节点的运行。为了简化形容，咱们将数据库集群中的各个节点称为 参与者，三阶段提交协定中同样蕴含协调者和参与者这两个角色定义, 前面再说。

第一阶段：投票

该阶段的次要目标在于打探数据库集群中的各个参与者是否可能失常的执行事务，具体步骤如下：

1. 协调者向所有的参与者发送事务执行申请，并期待参与者反馈事务执行后果；
2. 事务参与者收到申请之后，执行事务但不提交，并记录事务日志；
3. 参与者将本人事务执行状况反馈给协调者，同时阻塞期待协调者的后续指令。

第二阶段：事务提交

在通过第一阶段协调者的询盘之后，各个参与者会回复本人事务的执行状况，这时候存在 3 种可能性：

1. 所有的参与者都回复可能失常执行事务。
2. 一个或多个参与者回复事务执行失败。
3. 协调者期待超时。

对于第 1 种状况，协调者将向所有的参与者收回提交事务的告诉，具体步骤如下：

1. 协调者向各个参与者发送 commit 告诉，申请提交事务；
2. 参与者收到事务提交告诉之后执行 commit 操作，而后开释占有的资源；
3. 参与者向协调者返回事务 commit 后果信息。

对于第 2 和第 3 种状况，协调者均认为参与者无奈胜利执行事务，为了整个集群数据的一致性，所以要向各个参与者发送事务回滚告诉，具体步骤如下：

1. 协调者向各个参与者发送事务 rollback 告诉，申请回滚事务；
2. 参与者收到事务回滚告诉之后执行 rollback 操作，而后开释占有的资源；
3. 参与者向协调者返回事务 rollback 后果信息。

两阶段提交协定解决的是分布式数据库数据强一致性问题，理论利用中更多的是用来解决事务操作的原子性，下图描述了协调者与参与者的状态转换。

站在协调者的角度，在发动投票之后就进入了 WAIT 期待状态，期待所有参与者回复各自事务执行状态，并在收到所有参与者的回复后决策下一步是发送 commit 提交 或 rollback 回滚信息。

站在参与者的角度，当回复完协调者的投票申请之后便进入 READY 状态（可能失常执行事务），接下去就是期待协调者最终的决策告诉，一旦收到告诉便可根据决策执行 commit 或 rollback 操作。

两阶段提交协定原理简略、易于实现，然而毛病也是不言而喻的，蕴含如下：

• 单点问题

协调者在整个两阶段提交过程中扮演着无足轻重的作用，一旦协调者所在服务器宕机，就会影响整个数据库集群的失常运行。比方在第二阶段中，如果协调者因为故障不能失常发送事务提交或回滚告诉，那么参与者们将始终处于阻塞状态，整个数据库集群将无奈提供服务。

• 同步阻塞

两阶段提交执行过程中，所有的参与者都须要服从协调者的对立调度，期间处于阻塞状态而不能从事其余操作，这样效率极其低下。

• 数据不一致性

两阶段提交协定尽管是分布式数据强一致性所设计，但依然存在数据不一致性的可能性。比方在第二阶段中，假如协调者收回了事务 commit 告诉，然而因为网络问题该告诉仅被一部分参与者所收到并执行了 commit 操作，其余的参与者则因为没有收到告诉始终处于阻塞状态，这时候就产生了数据的不一致性。

针对上述问题能够引入 超时机制 和 互询机制在很大水平上予以解决。

超时机制

对于协调者来说如果在指定工夫内没有收到所有参与者的应答，则能够主动退出 WAIT 状态，并向所有参与者发送 rollback 告诉。对于参与者来说如果位于 READY 状态，然而在指定工夫内没有收到协调者的第二阶段告诉，则不能果断地执行 rollback 操作，因为协调者可能发送的是 commit 告诉，这个时候执行 rollback 就会导致数据不统一。

互询机制

此时，咱们能够染指互询机制，让参与者 A 去询问其余参与者 B 的执行状况。如果 B 执行了 rollback 或 commit 操作，则 A 能够大胆的与 B 执行雷同的操作；如果 B 此时还没有达到 READY 状态，则能够推断出协调者收回的必定是 rollback 告诉；如果 B 同样位于 READY 状态，则 A 能够持续询问另外的参与者。只有当所有的参与者都位于 READY 状态时，此时两阶段提交协定无奈解决，将陷入长时间的阻塞状态。

三阶段提交协定

三阶段提交协定（3PC：Three-Phase Commit）, 针对两阶段提交存在的问题，三阶段提交协定通过引入一个 预询盘 阶段，以及超时策略来缩小整个集群的阻塞工夫，晋升零碎性能。三阶段提交的三个阶段别离为：预询盘（can_commit）、预提交（pre_commit），以及事务提交（do_commit）。

第一阶段：预询盘

该阶段协调者会去询问各个参与者是否可能失常执行事务，参与者依据本身状况回复一个预估值，绝对于真正的执行事务，这个过程是轻量的，具体步骤如下：

1. 协调者向各个参与者发送事务询问告诉，询问是否能够执行事务操作，并期待回复；
2. 各个参与者根据本身情况回复一个预估值，如果预估本人可能失常执行事务就返回确定信息，并进入准备状态，否则返回否定信息。

第二阶段：预提交

本阶段协调者会依据第一阶段的询盘后果采取相应操作，询盘后果次要有 3 种：

1. 所有的参与者都返回确定信息。
2. 一个或多个参与者返回否定信息。
3. 协调者期待超时。

针对第 1 种状况，协调者会向所有参与者发送事务执行申请，具体步骤如下：

1. 协调者向所有的事务参与者发送事务执行告诉；
2. 参与者收到告诉后执行事务但不提交；
3. 参与者将事务执行状况返回给客户端。

在上述步骤中，如果参与者期待超时，则会中断事务。针对第 2 和第 3 种状况，协调者认为事务无奈失常执行，于是向各个参与者收回 abort 告诉，申请退出准备状态，具体步骤如下：

1. 协调者向所有事务参与者发送 abort 告诉；
2. 参与者收到告诉后中断事务。

第三阶段：事务提交

如果第二阶段事务未中断，那么本阶段协调者将会根据事务执行返回的后果来决定提交或回滚事务，分为 3 种状况：

1. 所有的参与者都能失常执行事务。
2. 一个或多个参与者执行事务失败。
3. 协调者期待超时。

针对第 1 种状况，协调者向各个参与者发动事务提交申请，具体步骤如下：

1. 协调者向所有参与者发送事务 commit 告诉；
2. 所有参与者在收到告诉之后执行 commit 操作，并开释占有的资源；
3. 参与者向协调者反馈事务提交后果。

针对第 2 和第 3 种状况，协调者认为事务无奈胜利执行，于是向各个参与者发送事务回滚申请，具体步骤如下：

1. 协调者向所有参与者发送事务 rollback 告诉；
2. 所有参与者在收到告诉之后执行 rollback 操作，并开释占有的资源；
3. 参与者向协调者反馈事务回滚后果。

在本阶段如果因为协调者或网络问题，导致参与者迟迟不能收到来自协调者的 commit 或 rollback 申请，那么参与者将不会如两阶段提交中那样陷入阻塞，而是期待超时后持续 commit，绝对于两阶段提交尽管升高了同步阻塞，但依然无奈完全避免数据的不统一。两阶段提交协定中所存在的长时间阻塞状态产生的几率还是非常低的，所以尽管三阶段提交协定绝对于两阶段提交协定对于数据强一致性更有保障，然而因为效率问题，两阶段提交协定在理论零碎中反而更加受宠。

TCC 模式

TCC 是 Try、Confirm 和 Cancel 三个单词首字母缩写, 它们别离的职责是：

Try：负责预留资源（比方新建一条状态 =PENDING 的订单）;

做业务查看，简略来说就是不能预留曾经被占用的资源;

隔离预留资源。

Confirm：负责落地所预留的资源

真正的执行业务应用 try 阶段预留的资源, 幂等。

Cancel：负责撤销所预留的资源

须要用户依据本人的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 形式，在二阶段提交执行 Confirm 办法，二阶段回滚执行 Cancel 办法。

对于预留资源要多说两句，资源都是无限的，因而预留资源都是有时效的，如果当预留资源迟迟得不到 Confirm——咱们将这种状况称为 timeout——参与方会自行将其 Cancel。也就是说参与方对于资源具备自我管理能力，这样能够防止因发起方的问题导致资源被长期占用。

TCC 减少了业务检查和撤销事务的性能。同时，TCC 将 2PC 数据库层面的动作晋升到了服务层面，不同的是 TCC 的所有动作都是一个本地事务，每个本地事务都在动作实现后 commit 到数据库：

• Try 相当于 2PC 的 Commit request phase，外加了业务查看逻辑
• Confirm 相当于 2PC 的 Commit phase 的 commit 动作
• Cancel 相当于 2PC 的 Commit phase 的 rollback 动作

流程步骤：

1. 发起方 发送 Try 到所有 参与方
2. 每个 参与方 执行 Try，预留资源
3. 发起方 收到所有 参与方 的 Try 后果
4. 发起方 发送 Confirm/Cancel 到所有 参加房
5. 每个 参与方 执行 Confirm/Cancel
6. 发起方 收到所有 参与方 的 Confirm/Cancel 后果

流程和两阶段提交十分相似。

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿(2021 最新版)

2. 别在再满屏的 if/ else 了，试试策略模式，真香！！

3. 卧槽！Java 中的 xx ≠ null 是什么新语法？

4.Spring Boot 2.5 重磅公布，光明模式太炸了！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！