精华内容
下载资源
问答
  • 两段提交协议
    千次阅读
    更多相关内容
  • 1.11阶段提交协议

    千次阅读 2022-01-24 16:01:20
    阶段提交协议

    分布式事务是指会涉及到操作多个数据库的事务,在分布式系统中,各个节点之间在物理上相互独 立,通过网络进行沟通和协调。

    XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范(即接口函数),交易中间件 用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。 二阶段提交(Two-phaseCommit)是指,在计算机网络以及数据库领域内,为了使基于分布式系统 架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常,二阶段提 交也被称为是一种协议(Protocol))。在分布式系统中,每个节点虽然可以知晓自己的操作时成功 或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事 务的 ACID 特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并 最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此, 二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者,再由协调者根据所有参与者 的反馈情报决定各参与者是否要提交操作还是中止操作。

    准备阶段

    事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息,每个参与者要么直接返回 失败(如权限验证失败),要么在本地执行事务,写本地的 redo 和 undo 日志,但不提交,到达一 种“万事俱备,只欠东风”的状态。

    提交阶段

    如果协调者收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息;否则, 发送提交(Commit)消息;参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过 程中使用的锁资源。(注意:必须在最后阶段释放锁资源)。

    缺点

    同步阻塞问题

    1、执行过程中,所有参与节点都是事务阻塞型的。

    单点故障

    2、由于协调者的重要性,一旦协调者发生故障。参与者会一直阻塞下去。

    数据不一致(脑裂问题)

    3、在二阶段提交的阶段二中,当协调者向参与者发送 commit 请求之后,发生了局部网络异 常或者在发送 commit 请求过程中协调者发生了故障,导致只有一部分参与者接受到了 commit 请求。于是整个分布式系统便出现了数据部一致性的现象(脑裂现象)。

    二阶段无法解决的问题(数据状态不确定)

    4、协调者再发出 commit 消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。那 么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道 事务是否被已经提交。

    展开全文
  • 文章目录 阶段提交协议 1. 阶段提交的前提条件 2. 阶段提交的基本算法 a. 第一阶段(提交请求阶段) b. 第二阶段(提交执行阶段) 3. 阶段提交的缺点 Flink-阶段提交协议 1. Flink-Kafka构建端到端Exactly...

    在Flink 1.4.0之前,Flink只能做到应用程序内的精确一次处理(exactly-once semantic),而无法做到端到端的精确一次(end-to-end exactly-once semantics)处理。 要提供端到端的精确一次语义,还需要sink端的外部存储系统提供提交和回滚的功能,然后与Flink Checkpoint机制结合使用才能实现端到端的精确一次语义。

    在分布式系统中,协调提交和回滚的一种常见方法就是两阶段提交协议。在Flink 1.4.0版本中,Flink实现了一个新功能:TwoPhaseCommitSinkFunction。这是一个抽象类,它提取了两阶段提交协议中的通用逻辑,并提供了一个抽象层,对用户来说,我们只需实现少量的几个方法便可以实现端到端精确一次的Flink应用程序。

    我们首先来了解一下什么是两阶段提交协议,以及其内部的工作原理。

    两阶段提交协议

    两阶段提交(Two-phase Commit)是为了使基于分布式系统架构的所有节点在进行事务提交时保持一致性而设计的一种算法,通常也被称为两阶段提交协议。

    在分布式系统中,虽然每个节点可以知道自己的操作是否成功,但是却无法知道其他节点的操作结果。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调者(Coordinator)的组件来统一掌控所有节点(通常被称为参与者)的操作结果并最终指示这些参与者节点是否要把操作结果进行真正的提交(比如,将更新后的数据写入外部存储系统等等)。

    总的来说,两阶段提交协议的算法思路可以概括为:参与者将操作结果通知协调者,协调者根据所有参与者的反馈结果决定各参与者是要执行提交操作还是终止操作。

    1. 两阶段提交的前提条件

    两阶段提交的成立要基于以下假设:

    • 该分布式系统中,存在一个节点作为协调者,其他节点作为参与者,且节点之间可以进行网络通信。
    • 所有节点都采用预写式日志,且日志被写入后即被保存在可靠的存储设备上,即使节点损坏也不会导致日志数据的丢失。
    • 所有节点不会永久性损坏,即使损坏后也可以恢复。

    2. 两阶段提交的基本算法

    下面通过分阶段来对两阶段提交进行说明。

    a. 第一阶段(提交请求阶段)

    1. 协调者节点向所有参与者节点询问是否可以执行提交操作,并开始等待各参与者节点的响应。
    2. 参与者节点执行协调者节点询问发起为止的所有事务操作,并将undo信息和redo信息写入日志。
    3. 各参与者节点响应协调者节点发起的询问,如果参与者节点的事务操作执行成功,则它返回一个"ack"同意消息;如果参与者节点的事务操作执行失败,则它返回一个"abort"中止消息。

    b. 第二阶段(提交执行阶段)

    第二阶段要执行怎样的操作是由第一阶段各参与者返回的消息来决定的。

    当所有参与者节点都返回"ack"同意消息时:

    1. 协调者节点向所有参与者节点发出"正式提交"的请求。
    2. 参与者节点正式完成操作,并释放在整个事务期间占用的资源。
    3. 参与者节点向协调者节点发送"完成"消息。
    4. 协调者节点收到所有参与者节点反馈的"完成"消息后,事务完成。

    如果任意一个参与者节点返回了"abort"中止消息,或者协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时:

    1. 协调者节点向所有参与者节点发出"回滚操作(callback)"的请求。
    2. 参与者节点利用之前写入的Undo信息执行回滚,并释放在整个事务期间占用的资源。
    3. 参与者节点向协调者节点发送"回滚完成"消息。
    4. 协调者节点收到所有参与者节点反馈的"回滚完成"消息后,取消事务。

    3. 两阶段提交的缺点

    两阶段提交算法的最大缺点就在于它在执行过程中,节点会因为在等待对方的响应消息而处于阻塞状态。

    另外,协调者节点通知参与者节点进行提交操作时,如有参与者节点出现了崩溃等情况而导致协调者始终无法获取所有参与者的响应消息,这时协调者将只能依赖其自身的超时机制来生效。

    Flink-两阶段提交协议

    1. Flink-Kafka构建端到端Exactly-once应用

    假设,我们有一个Flink应用程序,source端为Kafka,中间做一些聚合操作,最后写回Kafka。Kafka在0.11版本开始支持事务,这就可以使用Flink和Kafka构建端到端Exactly-once的应用程序。
    在这里插入图片描述

    我们在介绍两阶段提交的时候了解到,在分布式系统中,事务的提交或回滚是需要多个所有参与者都同意才能确保数据的一致性。那么,Flink就是用两阶段提交来保证数据的一致性的。

    Checkpoint的开始表示两阶段提交协议的"pre-commit"阶段,当触发Checkpoint时,Flink JobManager会向数据流注入一个barrier(它将数据流中的记录划分为进入当前Checkpoint的部分和进入下一个Checkpoint的部分)。Barrier会随着数据流在operator之间传递,对于每一个operator,都会触发它的状态后端来保存其状态数据。
    在这里插入图片描述
    Flink应用程序的source端会保存Kafka的offsets,之后会将barrier传递给下一个operator。如果operator只有内部状态,这是没有问题的,因为内部状态是由Flink的状态后端来管理和存储的;如果operator有外部状态,比如sink端要写入外部存储系统(比如Kafka),那么为了确保exactly-once的语义,外部存储系统必须提供整合两阶段提交协议的事务机制。
    在这里插入图片描述
    预提交阶段在Checkpoint成功完成之后结束。下一步是通知所有operatorCheckpoint已经成功,这是两阶段提价协议的提交阶段,JobManager会为应用程序中的每个operator发出Checkpoint完成的回调通知。
    在这里插入图片描述

    2. Flink实现两阶段提交

    Flink将两阶段提交协议中的通用逻辑抽象为了一个类——TwoPhaseCommitSinkFunction。

    我们在实现端到端exactly-once的应用程序时,只需实现这个类的4个方法即可:

    • beginTransaction:开始事务时,会在目标文件系统上的临时目录中创建一个临时文件,之后将处理数据写入该文件。
    • preCommit:在预提交时,我们会刷新文件,关闭它并不再写入数据。我们还将为下一个Checkpoint的写操作启动一个新事务。
    • commit:在提交事务时,我们自动将预提交的文件移动到实际的目标目录。
    • abort:中止时,将临时文件删除。

    如果出现任何故障,Flink将应用程序的状态恢复到最近一次成功的Checkpoint。如果故障发生在预提交成功之后,但还没来得及通知JobManager之前,在这种情况下,Flink会将operator恢复到已经预提交但尚未提交的状态。

    参考

    展开全文
  • 三阶段提交协议在协调者和参与者中都引入超时机制,并且把阶段提交协议的第一个阶段拆分成了步:询问,然后再锁资源,最后真正提交。 (1)三个阶段的执行 1.CanCommit阶段 3PC的CanCommit阶段其实和2PC的准备...

    一、分布式数据一致性

    在分布式系统中,为了保证数据的高可用,通常会将数据保留多个副本(replica),这些副本会放置在不同的物理的机器上。

    1.什么是数据一致性

    在数据有多份副本的情况下,如果网络、服务器或者软件出现故障,会导致部分副本写入成功,部分副本写入失败。这就造成各个副本之间的数据不一致,数据内容冲突。

    造成事实上的数据不一致。

    2.CAP定理

    CAP理论认为在分布式的环境下设计和部署系统时,有3个核心的需求:

    Consistency,Availability和Partition Tolerance,即CAP。

    Consistency:一致性,这个和数据库ACID的一致性类似,但这里关注的所有数据节点上的数据一致性和正确性,而数据库的ACID关注的是在在一个事务内,对数据的一些约束。系统在执行过某项操作后仍然处于一致的状态。在分布式系统中,更新操作执行成功后所有的用户都应该读取到最新值。

    Availability:可用性,每一个操作总是能够在一定时间内返回结果。需要注意“一定时间”和“返回结果”。“一定时间”是指,系统结果必须在给定时间内返回。“返回结果”是指系统返回操作成功或失败的结果。

    Partition Tolerance:分区容忍性,是否可以对数据进行分区。这是考虑到性能和可伸缩性。

    3.数据一致性模型

    一些分布式系统通过复制数据来提高系统的可靠性和容错性,并且将数据的不同的副本存放在不同的机器。

    强一致性:
    当更新操作完成之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的,就是用户上一次写什么,下一次就保证能读到什么。根据 CAP 理论,这种实现需要牺牲可用性。

    弱一致性:
    系统并不保证续进程或者线程的访问都会返回最新的更新过的值。用户读到某一操作对系统特定数据的更新需要一段时间,我们称这段时间为“不一致性窗口”。系统在数据写入成功之后,不承诺立即可以读到最新写入的值,也不会具体的承诺多久之后可以读到。

    最终一致性:
    是弱一致性的一种特例。系统保证在没有后续更新的前提下,系统最终返回上一次更新操作的值。在没有故障发生的前提下,不一致窗口的时间主要受通信延迟,系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。

     

    二、典型的分布式事务实例

    跨行转账问题是一个典型的分布式事务,用户A向B的一个转账1000,要进行A的余额-1000,B的余额+1000,显然必须保证这两个操作的事务性。
    类似的还有,电商系统中,当有用户下单后,除了在订单表插入记,还要在商品表更新库存等,特别是随着微服务架构的流行,分布式事务的场景更变得更普遍。

     

    三、两阶段提交协议

    两阶段提交协议是协调所有分布式原子事务参与者,并决定提交或取消(回滚)的分布式算法。

    1.协议参与者

    在两阶段提交协议中,系统一般包含两类机器(或节点):一类为协调者(coordinator),通常一个系统中只有一个;另一类为事务参与者(participants,cohorts或workers),一般包含多个,在数据存储系统中可以理解为数据副本的个数。协议中假设每个节点都会记录写前日志(write-ahead log)并持久性存储,即使节点发生故障日志也不会丢失。协议中同时假设节点不会发生永久性故障而且任意两个节点都可以互相通信。


    2.两个阶段的执行

    1.请求阶段(commit-request phase,或称表决阶段,voting phase)
    在请求阶段,协调者将通知事务参与者准备提交或取消事务,然后进入表决过程。
    在表决过程中,参与者将告知协调者自己的决策:同意(事务参与者本地作业执行成功)或取消(本地作业执行故障)。

    2.提交阶段(commit phase)
    在该阶段,协调者将基于第一个阶段的投票结果进行决策:提交或取消。
    当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务,否则协调者将通知所有的参与者取消事务。
    参与者在接收到协调者发来的消息后将执行响应的操作。

    (3)两阶段提交的缺点

    1.同步阻塞问题。执行过程中,所有参与节点都是事务阻塞型的。
    当参与者占有公共资源时,其他第三方节点访问公共资源不得不处于阻塞状态。

    2.单点故障。由于协调者的重要性,一旦协调者发生故障。
    参与者会一直阻塞下去。尤其在第二阶段,协调者发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。(如果是协调者挂掉,可以重新选举一个协调者,但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题)

    3.数据不一致。在二阶段提交的阶段二中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这回导致只有一部分参与者接受到了commit请求。
    而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

    (4)两阶段提交无法解决的问题

    当协调者出错,同时参与者也出错时,两阶段无法保证事务执行的完整性。
    考虑协调者再发出commit消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。
    那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。

     

    四、三阶段提交协议

    三阶段提交协议在协调者和参与者中都引入超时机制,并且把两阶段提交协议的第一个阶段拆分成了两步:询问,然后再锁资源,最后真正提交。

    (1)三个阶段的执行
    1.CanCommit阶段
    3PC的CanCommit阶段其实和2PC的准备阶段很像。
    协调者向参与者发送commit请求,参与者如果可以提交就返回Yes响应,否则返回No响应。

    2.PreCommit阶段
    Coordinator根据Cohort的反应情况来决定是否可以继续事务的PreCommit操作。
    根据响应情况,有以下两种可能。
    A.假如Coordinator从所有的Cohort获得的反馈都是Yes响应,那么就会进行事务的预执行:
    发送预提交请求。Coordinator向Cohort发送PreCommit请求,并进入Prepared阶段。
    事务预提交。Cohort接收到PreCommit请求后,会执行事务操作,并将undo和redo信息记录到事务日志中。
    响应反馈。如果Cohort成功的执行了事务操作,则返回ACK响应,同时开始等待最终指令。

    B.假如有任何一个Cohort向Coordinator发送了No响应,或者等待超时之后,Coordinator都没有接到Cohort的响应,那么就中断事务:
    发送中断请求。Coordinator向所有Cohort发送abort请求。
    中断事务。Cohort收到来自Coordinator的abort请求之后(或超时之后,仍未收到Cohort的请求),执行事务的中断。

    3.DoCommit阶段

    该阶段进行真正的事务提交,也可以分为以下两种情况:

    执行提交

    A.发送提交请求。Coordinator接收到Cohort发送的ACK响应,那么他将从预提交状态进入到提交状态。并向所有Cohort发送doCommit请求。
    B.事务提交。Cohort接收到doCommit请求之后,执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
    C.响应反馈。事务提交完之后,向Coordinator发送ACK响应。
    D.完成事务。Coordinator接收到所有Cohort的ACK响应之后,完成事务。

    中断事务

    Coordinator没有接收到Cohort发送的ACK响应(可能是接受者发送的不是ACK响应,也可能响应超时),那么就会执行中断事务。

    (2)三阶段提交协议和两阶段提交协议的不同

    对于协调者(Coordinator)和参与者(Cohort)都设置了超时机制(在2PC中,只有协调者拥有超时机制,即如果在一定时间内没有收到cohort的消息则默认失败)。
    在2PC的准备阶段和提交阶段之间,插入预提交阶段,使3PC拥有CanCommit、PreCommit、DoCommit三个阶段。
    PreCommit是一个缓冲,保证了在最后提交阶段之前各参与节点的状态是一致的。

    (2)三阶段提交协议的缺点

    如果进入PreCommit后,Coordinator发出的是abort请求,假设只有一个Cohort收到并进行了abort操作,
    而其他对于系统状态未知的Cohort会根据3PC选择继续Commit,此时系统状态发生不一致性。

     

    参考资料:

    维基百科:两阶段提交协议

    分布式协议之两阶段提交协议(2PC)和改进三阶段提交协议(3PC)

    关于分布式事务、两阶段提交协议、三阶提交协议

    Introduction to 3PC 三阶段提交协议简介

    展开全文
  • 分布式系统理论之阶段提交协议

    千次阅读 2019-06-20 19:46:32
    一,阶段提交协议介绍 阶段提交协议是用来保证分布式系统事务的协议。在分布式系统中,一个事务需要由多台机器协调完成,机器之间通过网络来通信,如何保证一组操作在多台机器上要么都做,要么都不做呢?(事务...
  • 阶段提交协议(two phase commit protocol,2PC)可以保证数据的强一致性,许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者,并决定提交或取消(回滚)的分布式算法。...
  • 分布式系统中的阶段提交协议

    千次阅读 2020-04-20 22:35:28
    分布式系统中的阶段提交协议 在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调...
  • 来源:  ...分布式协议之阶段提交协议(2PC)和改进三阶段提交协议(3PC) 关于分布式事务、阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究 阶段提交协议与三阶段提交协议
  • 阶段提交协议(two phase commit protocol,2PC)可以保证数据的强一致性,许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者,并决定提交或取消(回滚)的分布式算法。...
  • 阶段提交协议的异常处理

    千次阅读 2014-07-07 12:54:08
    阶段提交协议大家都比较熟悉了,解释一下每个阶段的异常处理。
  • 阶段提交协议(two phase commit protocol,2PC) 阶段提交协议(two phase commit protocol,2PC)可以保证数据的强一致性,许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式...
  • 分布式事务阶段提交

    千次阅读 2022-02-20 15:18:20
    分布式阶段提交
  • 分布式协议之阶段提交协议(2PC)和改进三阶段提交协议(3PC) 关于分布式事务、阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究 阶段提交协议与三阶段提交协议
  • XA协议阶段提交(原理)

    千次阅读 2021-06-15 14:46:14
    基于XA协议阶段提交 XA是由X/Open组织提出的分布式事务的规范 由一个事务管理器(TM)和多个资源管理器(RM)组成 提交分为个阶段:prepare和commit 第一阶段 第二阶段 保证数据的强一致性 commit阶段...
  • 阶段提交协议其实是将集中式的提交协议(常用单机数据库的事务提交方法)的工程拆开成个阶段,从commit这个步骤将其拆开,在commit之前,(阶段提交协议)发送消息给协调者,等待协调者确认收集到所有的可提交消息...
  • Mysql的阶段锁协议

    千次阅读 2022-01-30 21:58:46
    mysql的事务为什么需要阶段锁协议阶段锁协议是什么?在mysql优化中如何利用阶段锁的特性提交mysql并发量?
  • 阶段提交协议

    千次阅读 2015-08-30 18:46:50
    阶段提交协议是最简单最流行的ACP。在没有故障发生的情况下,它的执行过程如下: 1. 协调者发送一个VOTE-REQ消息给所有的参与者 2.当参与者接收到VOTE-REQ消息后,它会发送一个包含参与者投票结果的消息(YES或NO...
  • 阶段提交协议: 第一阶段,准备阶段:协调者向参与者发起指令,参与者评估自己的状态,如果参与者评估指令可以完成,则会写redo或者undo日志,然后锁定资源,执行操作,但并不提交; 第二阶段:如果每个参与者...
  • 对分布式事务及阶段提交、三阶段提交的理解 一、分布式数据一致性 在分布式系统中,为了保证数据的高可用,通常会将数据保留多个副本(replica),这些副本会放置在不同的物理的机器上。 1.什么是数据一致性 ...
  • 什么是阶段提交协议

    千次阅读 2009-04-07 15:33:00
    阶段提交协议实现分布式事务的关键就是阶段提交协议。在此协议中,一个或多个资源管理器的活动均由一个称为事务协调器的单独软件组件来控制。此协议中的五个步骤如下:• 应用程序调用事务协调器中的提交方法。...
  • 2PC:实现分布式事务的关键就是阶段提交协议。在此协议中,一个或多个资源管理器的活动均由一个称为事务协调器部件来控制。step如下: 1、 应用程序调用事务协调器中的提交方法 事务协调器(transaction ...
  • XA阶段提交协议

    万次阅读 2015-09-29 22:15:28
     XA:XA协议,规定事务管理器和资源管理器接口,采用二阶段提交协议。 一阶段提交协议  一阶段提交协议相对简单,如下图:    当然,前提是开启了事务,然后在应用程序发出提交/回滚请求后,数据库执行操作...
  • 分布式事务提交协议2PC/3PC详解

    千次阅读 2022-03-06 13:02:21
    分布式提交技术1 分布式提交技术1.1 阶段提交新的改变功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左...
  • ...分布式协议之阶段提交协议(2PC)和改进三阶段提交协议(3PC) 关于分布式事务、阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究 阶段提交协议与三阶段提交协议
  • 2PC 阶段提交协议

    千次阅读 2016-08-08 10:48:55
    通常,二阶段提交也被称为是一种协议(Protocol))。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的A
  • 分布式事务-阶段提交协议

    千次阅读 2012-02-03 16:25:17
    实现分布式事务的关键就是阶段提交协议。在此协议中,一个或多个资源管理器的活动均由一个称为事务协调器的单独软件组件来控制。此协议中的五个步骤如下: • 应用程序调用事务协调器中的提交...
  • 分布式协议:2PC、3PC 与 Paxos 协议

    千次阅读 2020-09-21 17:58:19
    阶段提交协议 Paxos 协议 简介 分布式系统涉及的协议很多,例如租约,复制协议,一致性协议,其中以阶段提交协议(2PC)和Paxos协议最具有代表性。阶段提交协议用于保证跨多个节点操作的原子性,也就是说,...
  • 分布式事务之阶段提交

    千次阅读 2021-10-31 17:00:40
    阶段提交协议 阶段提交协议把分布式事务分为个阶段,一个是准备阶段,另一个是提交阶段; 准备阶段和提交阶段都是由事务管理器发起的; 我们可以将事务管理器称为协调者,将资源管理器称为参与者。 流程 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 166,288
精华内容 66,515
关键字:

两段提交协议