亿级流量架构之分布式事务思路及方法

推荐关注

顶级架构师后台回复 1024 有特别礼包

来源：网络

上一篇：高逼格的 SQL 写法：行行比较

大家好，我是顶级架构师。

分布式事务以及分布式锁是分布式中难点,分布式事务一篇文章可能写不完,我的习惯时从基本概念出发,一步一步开始介绍,前面会先梳理事务中一些基本概念,对基本概念十分清楚的话可以直接看"一致性讨论"以及后面的部分。予己方便总结回顾、与他交流分享。

什么是分布式事务

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

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

原子性(Atomic)

H₂O，C在化学中,分子构成的物质,分子是保持化学特性的最小单位,如𝐻2𝑂,𝐶𝑂2等,由原子构成的物质,原子保持物质特性,像𝐹𝑒啥的,意思就是不可分割,再分成质子中子啥的就不是我们认为的物质了,这儿的原子性也是这个道理,就是事务不可以再拆分,例如上面的事务,看着可以是由两个过程组成的事务,但是你拆开就不是我们认为该有的过程,所以,事务不可再分,具有原子性。

一致性（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. 参与者向协调者反馈事务回滚结果。另外，搜索公众号Linux就该这样学后台回复“猴子”，获取一份惊喜礼包。

在本阶段如果因为协调者或网络问题，导致参与者迟迟不能收到来自协调者的 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结果

流程和两阶段提交非常类似。

最后给读者整理了一份BAT大厂面试真题，需要的可扫码回复“面试题”即可获取。

公众号后台回复 架构 或者 架构整洁 有惊喜礼包！顶级架构师交流群

 「顶级架构师」建立了读者架构师交流群，大家可以添加小编微信进行加群。欢迎有想法、乐于分享的朋友们一起交流学习。

扫描添加好友邀你进架构师群，加我时注明【姓名+公司+职位】

版权申明：内容来源网络，版权归原作者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

猜你还想看