分布式事务内幕(2)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 分布式事务内幕(2)

2.1 2PC中的参与者故障让我们考虑几种故障的场景。例如,如图13-2所示,如果其中一个参与者在提议阶段故障,则协调者无法继续进行提交,因为它要求所有投票都是赞成票。如果其中一个参与者不可用,则协调者将中止事务。该要求会影响到可用性:单个节点的故障就会阻止事务提交。一些系统,例如Spanner(参见13.5节),在Paxos组而不是单个节点上执行2PC,从而改进可用性。


image.png


2PC的核心思想在于参与者的承诺:一旦对提案做出了肯定的回应,它不能再反悔,因此只有协调者才能中止事务。  如果其中一个参与者在接受提案后发生故障,它必须先了解投票的实际结果,然后才能知道正确的值,因为协调者可能由于其他参与者的投票而中止了提交。当参与者节点恢复时,它必须跟上协调者的最终决定。为此,我们通常将决策日志保留在协调者端,并将决定的值复制到故障的参与者。在此之前,参与者不能处理请求,因为它还处于不一致状态。由于协议中存在多个阻塞操作,此时进程要等待其他参与者(当协调者收集投票时,或参与者正在等待提交/中止阶段时),因此,链路故障可能导致消息丢失,进程会无限地等待下去。如果提议阶段中协调者未收到来自某个副本的响应,它不会因此阻塞,因为它可以触发超时并中止事务。


2.2 2PC中的协调者故障


第二阶段中,如图13-3所示,如果某个参与者没有收到协调者的提交或中止指令,则应当尝试找出协调者做出的决定。协调者可能已经决定了该值,但未能传达给某个副本。在这种情况下,可以从其他参与者的事务日志或是备份协调者的日志中找到决策信息。从复制日志中确定提交决定是安全的,因为这个决定一定是已经达成一致的:2PC的最终目的就是在所有节点上提交或中止,在一个参与者中提交即意味着其他所有参与者都必须提交。第一阶段中,协调者收集投票,继而也就获得了参与者的承诺:它们将等待其明确的提交或中止指令。如果协调者在收集投票后、广播投票结果之前发生故障,则参与者最终将处于不确定状态。如图13-4所示,参与者不知道协调者的决定,也不知道它是否已向某些参与者(可能也不可达)通知了事务结果[BERNSTEIN87]。


image.png


协调者无法继续进行提交或中止操作,这使得集群处于未决状态。这意味着在发生协调者永久性故障的情况下,参与者将无法得知最终决定。因为这个特性,我们说2PC是一种阻塞原子提交算法。如果协调者始终无法恢复,它的替代者只能再次为给定事务收集投票,并做出最终决定。许多数据库使用2PC:MySQL、PostgreSQL、MongoDB注2等。因为其简单性(易于论证、实现和调试)和低开销(消息复杂度和协议往返次数低),两阶段提交经常用于实现分布式事务。实现正确的恢复机制并拥有备份协调者节点,以减少发生上述故障的可能性,这一点非常重要。


3 三阶段提交


为了让原子提交协议在协调者故障下保持健壮并避免进入未决状态,三阶段提交(3PC)协议增加了一个额外的步骤,并且双方都具有超时机制,使得参与者在协调者发生故障时仍能继续提交或中止(取决于系统状态)。3PC假定同步网络模型,且不存在通信故障[BABAOGLU93]。3PC在提交/中止步骤之前添加了一个准备阶段,该阶段中协调者告知参与者在提议阶段收集的投票信息,即使协调者发生故障,协议也可以继续执行。3PC的所有其他性质都和2PC类似,包括要求有一个协调者。3PC的另一个有用的补充是参与者侧的超时,参与者根据进程当前正在执行的步骤,超时之时将强制进行提交或中止。如图13-5所示,三阶段提交包含以下三个步骤:


提议(propose)阶段        协调者发出提议值并收集投票。


准备(prepare)阶段        协调者将投票结果通知参与者。如果投票通过并且所有参与者都决定要提交,则协调者会发送一条Prepare消息,指示它们准备提交。否则,将发送Abort消息并退出流程。


提交(commit)阶段        协调者通知参与者提交事务。


image.png


在提议这一步中,类似于2PC,协调者分发提议值并收集参与者的投票,如图13-5 所示。如果协调者在此阶段崩溃导致操作超时,或者其中一个参与者投反对票,则事务中止。


收集投票后,协调者做出决定。如果协调者决定继续进行事务,则发出Prepare指令。协调者可能无法将Prepare消息发送给所有参与者,或是可能没有收到参与者的确认。这种情况下,参与者可能会在超时后中止事务,因为算法尚未完全进入到已准备状态。

一旦所有参与者成功进入已准备状态并且协调者收到了它们的准备确认,无论其中任何一方发生故障,事务都将被提交。之所以可以这样做是因为此阶段中所有参与者看到的状态是相同的。


在提交阶段,协调者将准备阶段的结果传达给所有参与者,重置它们的超时计数器并完成事务。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
7月前
|
SQL Java 中间件
详谈分布式事务
详谈分布式事务
108 0
|
存储 消息中间件 关系型数据库
聊一聊分布式事务的解决方案
分布式事务是分布式系统中非常重要的一部分,最典型的例子是银行转账和扣款,A 和 B 的账户信息在不同的服务器上,A 给 B 转账 100 元,要完成这个操作,需要两个步骤,从 A 的账户上扣款,以及在 B 的账户上增加金额,两个步骤必须全部执行成功;否则如果有一个失败,那么另一个操作也不能执行。 那么像这种转账扣款的例子,在业务中如何保证一致性,有哪些解决方案呢?
272 0
|
8月前
|
存储 Java 应用服务中间件
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
204 0
|
数据库 开发者 数据库管理
ACID原则-大道至简,你不觉得很秒嘛?
ACID原则-大道至简,你不觉得很秒嘛?
331 0
|
消息中间件 自然语言处理 Oracle
年前福利,我愿称之为分布式事务最全面的总结
首先还是先说一下事务的定义吧,事务的英语是 transaction ,我们查找词典可以发现这个单词的中文解释是交易,买卖等含义,所以我们可以知道事务一定和交易密不可分他们才能共享一个英文单词,而交易的定义是什么呢?有句俗话说得好,一手交钱,一手交货,那这个就是交易的规则,而这个同时也是事务的定义。那么事务的官方定义是什么呢?
|
设计模式 消息中间件 NoSQL
查漏补缺第三期(分布式事务相关)
前言 目前正在出一个查漏补缺专题系列教程, 篇幅会较多, 喜欢的话,给个关注❤️ ~ 本专题主要以Java语言为主, 好了, 废话不多说直接开整吧~ Q1 & 分布式事务有了解过吗?你是如何解决的呢? 如果简历中出现过分布式相关项目经验,提到过分布式事务的字眼,并且对方要求面试者有相关开发经验,基本上这个问题是必问的。
分布式事务,阿里为什么钟爱TCC
分布式事务,阿里为什么钟爱TCC
552 1
分布式事务,阿里为什么钟爱TCC
|
消息中间件 SQL 缓存
分布式事务知多少?
事务(Transaction)指的是一组操作,该操作具有原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability),也就是常说的ACID 原则。原子性(Atomicity):事务只能全部发生或者全部不发生。一致性(Consistency):事务需要得到逻辑上正确的结果,这由...
132 0
分布式事务知多少?
|
数据库
17.【学习心得】学习心得-柔性事务
【学习心得】学习心得-柔性事务
17.【学习心得】学习心得-柔性事务
|
SQL 前端开发 分布式数据库
18.【学习心得】学习心得-柔性事务落地
【学习心得】学习心得-柔性事务落地
18.【学习心得】学习心得-柔性事务落地