当前位置:首页 > 架构 > 正文内容

如何实现分布式事务

phpmianshi2年前 (2019-04-03)架构316

事务定义

简单地说,事务提供一种“要么什么都不做,要么做全套(All or Nothing)”机制。

数据库本地事务

数据库事务中的四大特性 ACID

A:原子性(Atomicity),一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。

事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。

就像你买东西要么交钱收货一起都执行,要么发不出货,就退钱。

C:一致性(Consistency),事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。

如果事务成功地完成,那么系统中所有变化将正确地应用,系统处于有效状态。

如果在事务中出现错误,那么系统中的所有变化将自动地回滚,系统返回到原始状态。

I:隔离性(Isolation),指的是在并发环境中,当不同的事务同时操纵相同的数据时,每个事务都有各自的完整数据空间。

由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时,数据所处的状态要么是另一事务修改它之前的状态,要么是另一事务修改它之后的状态,事务不会查看到中间状态的数据。

打个比方,你买东西这个事情,是不影响其他人的。

D:持久性(Durability),指的是只要事务成功结束,它对数据库所做的更新就必须***保存下来。

即使发生系统崩溃,重新启动数据库系统后,数据库还能恢复到事务成功结束时的状态。

打个比方,你买东西的时候需要记录在账本上,即使老板忘记了那也有据可查。

InnoDB 实现原理

事务的 ACID 是通过 InnoDB 日志和锁来保证。事务的隔离性是通过数据库锁的机制实现的,持久性通过 Redo Log(重做日志)来实现,原子性和一致性通过 Undo Log 来实现。

Undo Log 的原理很简单,为了满足事务的原子性,在操作任何数据之前,首先将数据备份到一个地方(这个存储数据备份的地方称为 Undo Log)。然后进行数据的修改。

如果出现了错误或者用户执行了 Rollback 语句,系统可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。

和 Undo Log 相反,Redo Log 记录的是新数据的备份。在事务提交前,只要将 Redo Log 持久化即可,不需要将数据持久化。

当系统崩溃时,虽然数据没有持久化,但是 Redo Log 已经持久化。系统可以根据 Redo Log 的内容,将所有数据恢复最新得状态。

分布式事务

分布式事务定义

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

本质上来说,分布式事务就是为了保证不同数据库的数据一致性。

分布式事务产生的原因

  • 1.Service 分布在不同节点

  • 2.Resource 分布在不同节点

分布式事务的基础

我们之前说过数据库的 ACID 四大特性,已经无法满足我们分布式事务,这个时候提出一些新的理论。

CAP原理

又被叫作布鲁尔定理。对于设计分布式系统(不仅仅是分布式事务)的架构师来说,CAP 就是你的入门理论。

CAP 原理是说,对于一个分布式系统,它不能够同时满足一致性(C)、可用性(A)以及分区耐受性(P)这三个特点。

C (一致性 Consistency ):对某个指定的客户端来说,读操作能返回任何其他节点的写操作。

A (可用性 Availability ):非故障的节点在合理的时间内返回合理的响应。可用性的两个关键一个是合理的时间,一个是合理的响应。

P (分区容错性 Partition Tolerance):当出现网络分区后,系统能够继续工作。打个比方,这里集群有多台机器,有台机器网络出现了问题,但是这个集群仍然可以正常工作。

熟悉 CAP 的人都知道,三者不能共有,在分布式系统中,网络无法 100% 可靠,分区其实是一个必然现象。

如果我们选择了 CA 而放弃了 P,那么当发生分区现象时,为了保证一致性,这个时候必须拒绝请求,但是 A 又不允许,所以分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP 架构

对于 CP 来说,放弃可用性,追求一致性和分区容错性,我们的 ZooKeeper 其实就是追求的强一致。

对于 AP 来说,放弃一致性(这里说的一致性是强一致性),追求分区容错性和可用性,这是很多分布式系统设计时的选择,后面的 BASE 也是根据 AP 来扩展。

顺便一提,CAP 理论中是忽略网络延迟,也就是当事务提交时,从节点 A 复制到节点 B 没有延迟,但是在现实中这个是明显不可能的,所以总会有一定的时间是不一致。

同时 CAP 中选择两个,比如你选择了 CP,并不是叫你放弃 A。因为 P 出现的概率实在是太小了,大部分的时间你仍然需要保证 CA。

就算分区出现了你也要为后来的 A 做准备,比如通过一些日志的手段,是其他机器回复至可用。


一致性冲突解决方案

解决一致性冲突的方案就是实现最终一致性。当数据在写的过程中多个数据备份有冲突的时候,如何解决呢?

1.一种方法是根据时间戳进行判断。最后写入的,也就是时间戳在后面的,覆盖时间戳在前面的。

2. 另一种解决冲突的机制是通过客户端进行冲突解决。客户端 1 保存用户购物车编号,用户 123 的购物车编号是 55,客户端 2 保存用户 123 购车编号是 70。当客户端 3 去获取用户 123 的购物车编号时,它就得到了两个编号的购物车。解决办法就是将这两个购物车进行合并,合并成一个购物车,并且把它重新写入到分步式存储集群中。

3. 还有一种冲突的解决方案是通过投票进行解决。典型的就是 Cassandra 中的冲突解决机制。如下图所示,一个客户端向一个分布式集群中写入数据的时候,它会同时向 3 个节点写入数据,并且至少等待两个节点响应写入成功。而另一个客户端想要读取这个数据的时候,至少要从 3 个节点中去读取数据,并且至少有 2 个节点有返回,然后根据返回的节点数进行投票,获取最新版本的数据。


BASE

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

基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。

软状态:允许系统中存在中间状态,这个状态不影响系统可用性,这里指的是 CAP 中的不一致。

最终一致:最终一致是指经过一段时间后,所有节点数据都将会达到一致。

BASE 解决了 CAP 中理论没有网络延迟,在 BASE 中用软状态和最终一致,保证了延迟后的一致性。

BASE 和 ACID 是相反的,它完全不同于 ACID 的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。

解决方案

有了上面的理论基础后,这里开始介绍几种常见的分布式事务的解决方案。

2PC

说到 2PC 就不得不聊数据库分布式事务中的 XA Transactions。

在 XA 协议中分为两阶段:

  • 事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是否可以提交。

  • 事务协调器要求每个数据库提交数据,或者回滚数据。

优点:

  • 尽量保证了数据的强一致,实现成本较低,在各大主流数据库都有自己实现,对于 MySQL 是从 5.5 开始支持。

缺点:

  • 单点问题:事务管理器在整个流程中扮演的角色很关键,如果其宕机,比如在预提交阶段已经完成,在第二阶段正准备提交的时候事务管理器宕机,资源管理器就会一直阻塞,导致数据库无法使用。

  • 同步阻塞:在准备就绪之后,资源管理器中的资源一直处于阻塞,直到提交完成,释放资源。

  • 数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计,但仍然存在数据不一致性的可能。

比如在第二阶段中,假设协调者发出了事务 Commit 的通知,但是因为网络问题该通知仅被一部分参与者所收到并执行了 Commit 操作,其余的参与者则因为没有收到通知一直处于阻塞状态,这时候就产生了数据的不一致性。

总的来说,XA 协议比较简单,成本较低,缺点是:单点问题,以及不能支持高并发(由于同步阻塞)。

TCC

关于 TCC(Try-Confirm-Cancel)的概念,最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

TCC 事务机制相比于上面介绍的 XA,解决了如下几个缺点:

  • 解决了协调者单点,由主业务方发起并完成这个业务活动。业务活动管理器也变成多点,引入集群。

  • 同步阻塞:引入超时,超时后进行补偿,并且不会锁定整个资源,将资源转换为业务逻辑形式,粒度变小。

  • 数据一致性,有了补偿机制之后,由业务活动管理器控制一致性。

对于 TCC 的解释:

  • Try 阶段:尝试执行,完成所有业务检查(一致性),预留必需业务资源(准隔离性)。

  • Confirm 阶段:确认真正执行业务,不作任何业务检查,只使用 Try 阶段预留的业务资源,Confirm 操作满足幂等性。要求具备幂等设计,Confirm 失败后需要进行重试。

  • Cancel 阶段:取消执行,释放 Try 阶段预留的业务资源,Cancel 操作满足幂等性。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致。

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

如果有一个失败,则进行 Cancel(释放这 100 元和这一瓶水),如果 Cancel 失败不论什么失败都进行重试 Cancel,所以需要保持幂等。

如果都成功,则进行 Confirm,确认这 100 元被扣,和这一瓶水被卖,如果 Confirm 失败无论什么失败则重试(会依靠活动日志进行重试)。

对于 TCC 来说适合一些:

  • 强隔离性,严格一致性要求的活动业务。

  • 执行时间较短的业务。

实现参考:https://github.com/liuyangming/ByteTCC/。

本地消息表

本地消息表这个方案最初是 eBay 提出的,eBay 的完整方案 https://queue.acm.org/detail.cfm?id=1394128。

此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列,再通过业务规则自动或人工发起重试。

人工重试更多的是应用于支付场景,通过对账系统对事后问题的处理。

对于本地消息队列来说核心是把大事务转变为小事务。还是举上面用 100 元去买一瓶水的例子。

1. 当你扣钱的时候,你需要在你扣钱的服务器上新增加一个本地消息表,你需要把你扣钱和减去水的库存写入到本地消息表,放入同一个事务(依靠数据库本地事务保证一致性)。

2. 这个时候有个定时任务去轮询这个本地事务表,把没有发送的消息,扔给商品库存服务器,叫它减去水的库存,到达商品服务器之后,这时得先写入这个服务器的事务表,然后进行扣减,扣减成功后,更新事务表中的状态。

3. 商品服务器通过定时任务扫描消息表或者直接通知扣钱服务器,扣钱服务器在本地消息表进行状态更新。

4. 针对一些异常情况,定时扫描未成功处理的消息,进行重新发送,在商品服务器接到消息之后,首先判断是否是重复的。

如果已经接收,再判断是否执行,如果执行在马上又进行通知事务;如果未执行,需要重新执行由业务保证幂等,也就是不会多扣一瓶水。

本地消息队列是 BASE 理论,是最终一致模型,适用于对一致性要求不高的情况。实现这个模型时需要注意重试的幂等。

MQ 事务

在 RocketMQ 中实现了分布式事务,实际上是对本地消息表的一个封装,将本地消息表移动到了 MQ 内部。

下面简单介绍一下MQ事务,如果想对其详细了解可以参考:https://www.jianshu.com/p/453c6e7ff81c。

基本流程如下:

  • 第一阶段 Prepared 消息,会拿到消息的地址。

  • 第二阶段执行本地事务。

  • 第三阶段通过第一阶段拿到的地址去访问消息,并修改状态。消息接受者就能使用这个消息。

如果确认消息失败,在 RocketMQ Broker 中提供了定时扫描没有更新状态的消息。

如果有消息没有得到确认,会向消息发送者发送消息,来判断是否提交,在 RocketMQ 中是以 Listener 的形式给发送者,用来处理。

如果消费超时,则需要一直重试,消息接收端需要保证幂等。如果消息消费失败,这时就需要人工进行处理,因为这个概率较低,如果为了这种小概率时间而设计这个复杂的流程反而得不偿失。

Saga 事务

Saga 是 30 年前一篇数据库伦理提到的一个概念。其核心思想是将长事务拆分为多个本地短事务,由 Saga 事务协调器协调,如果正常结束那就正常完成,如果某个步骤失败,则根据相反顺序一次调用补偿操作。

Saga 的组成:每个 Saga 由一系列 sub-transaction Ti 组成,每个 Ti 都有对应的补偿动作 Ci,补偿动作用于撤销 Ti 造成的结果。这里的每个 T,都是一个本地事务。

可以看到,和 TCC 相比,Saga 没有“预留 try”动作,它的 Ti 就是直接提交到库。

Saga 的执行顺序有两种:

  • T1,T2,T3,...,Tn。

  • T1,T2,...,Tj,Cj,...,C2,C1,其中 0 < j < n 。

Saga 定义了两种恢复策略:

  • 向后恢复,即上面提到的第二种执行顺序,其中 j 是发生错误的 sub-transaction,这种做法的效果是撤销掉之前所有成功的 sub-transation,使得整个 Saga 的执行结果撤销。

  • 向前恢复,适用于必须要成功的场景,执行顺序是类似于这样的:T1,T2,...,Tj(失败),Tj(重试),...,Tn,其中 j 是发生错误的 sub-transaction。该情况下不需要 Ci。

这里要注意的是,在 Saga 模式中不能保证隔离性,因为没有锁住资源,其他事务依然可以覆盖或者影响当前事务。

还是拿 100 元买一瓶水的例子来说,这里定义:

  • T1 = 扣 100 元,T2 = 给用户加一瓶水,T3 = 减库存一瓶水。

  • C1 = 加100元,C2 = 给用户减一瓶水,C3 = 给库存加一瓶水。

我们一次进行 T1,T2,T3 如果发生问题,就执行发生问题的 C 操作的反向。

上面说到的隔离性的问题会出现在,如果执行到 T3 这个时候需要执行回滚,但是这个用户已经把水喝了(另外一个事务),回滚的时候就会发现,无法给用户减一瓶水了。

这就是事务之间没有隔离性的问题。可以看见 Saga 模式没有隔离性的影响还是较大,可以参照华为的解决方案:从业务层面入手加入一 Session 以及锁的机制来保证能够串行化操作资源。

也可以在业务层面通过预先冻结资金的方式隔离这部分资源。

版权声明:本文由PHP面试资料网发布,如需转载请注明出处。
分享给朋友:

相关文章

大型系统高可用的一般策略

负载均衡首先是应用服务器的负载均衡。负载均衡核心要解决的就是通过一个负载均衡服务器,将用户的请求分发给多个应用服务器,将多个应用服务器构建成一个集群,共同对外提供服务。这样的架构可以提高系统的处理能力...

互联网应用可用性的度量

概念业界通常用多少个 9 来说明互联网应用的可用性。示例比如说 QQ 的可用性是 4 个 9,就是说 QQ 的服务 99.99% 可用,这句话的意思是 QQ 的服务要保证在其所有的运行时间里只有 0....

系统架构的演进之路-单体到SOA到微服务

单体系统的困难在微服务出现之前,互联网应用系统主要是单体系统,也就是说一个网站的整个系统由一个应用构成。如果是 Java,就打包成一个 war 包,一个 war 包包含整个应用系统,系统更新的时候,即...

如何应对网站流量暴增

如何应对网站流量暴增

按照经验大概出问题地方是DB,磁盘io、CPU、带宽、连接数、内存其中的一个或几个。不同的业务,不同的系统设计,出问题的地方会有所不同。如果流量增大数倍,势必某个资源会在瞬间被榨干,然后所有的服务都会...

秒杀如何设计

秒杀难点:1、突发流量、数据热点2、数据一致性、短暂混沌态如果采用传统的数据库进行数据存储,对同一资源的争抢,就会面临严重的锁冲突问题。一般是通过一个前置的,速度更快的存储顶在前面,这就涉及到源库和目...

基于rebase的Git工作流

使用Git在多人协作的过程中,我们也会面临如何运用好Git的问题。这种情况下,就出现了各种各样的Git Workflow,而本文将介绍一种基于rebase的工作流,这种工作流也是目前开源社区所比较推崇...

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。