精华内容
下载资源
问答
  • 二阶段提交实现
    千次阅读
    2022-04-13 16:59:17

    二阶段提交(2 Phase Commitment Protocol)
    为了使分布式系统架构下的各个节点在进行事务提交时保持一致性的一种协议。二阶段提交通过协调者和各个参与者的配合,实现分布式一致性。

    角色

    1. 协调者:调度事务
    2. 参与者:参与事务的执行和投票

    第一阶段:投票阶段。
    协调者向所有的参与者节点询问是否可以执行提交操作,并开始等待各参与节点的响应;
    参与者执行询问发起为止的所有事务操作,并将Undo信息和Redo信息写入事务日志(但是不提交事务)。如果参与者节点的事务操作实际执行成功,则它返回一个"同意"消息,如果参与者节点的事务实际执行失败,则它返回一个"中止"消息;

    第二阶段:提交阶段
    当协调者从所有的参与者节点获得的相应消息都是"同意"时:
    1).协调者节点向所有参与者节点发出"正式提交(commit)"的请求
    2).参与者正式完成操作,并释放在整个事务期间占用的资源
    3).参与者节点向协调者节点发送"ack完成"消息
    4).协调者收到所有参与者节点反馈的"ack完成"消息后,完成事务

    如果任一参与者节点在第一阶段返回的信息是"中止",或者协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应信息时,那么这个事务就会被回滚:
    1).协调者节点向所有参与者节点发出"回滚操作(rollback)"的请求
    2).参与者节点利用之前的Undo信息执行回滚,并释放在整个事务期间占用的资源
    3).参与者节点向协调者节点发送"ack回滚完成"信息
    4).协调者节点收到所有参与者节点反馈的"ack回滚完成"信息后,取消事务

    不管最后结果如何,第二阶段都会结束当前事务。

    2 PC存在的问题

    1. 性能问题:执行过程中,所有参与节点都是事务阻塞型的。当参与者占有公共资源时,其他第三方节点访问公共资源不得不处于阻塞状态。
    2. 可靠性问题:参与者发生故障。协调者需要给每个参与者额外指定超时机制,超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去。
    3. 数据一致性问题:二阶段无法解决的问题:协调者在发出
      commit消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。

    2PC的优点
    尽量保证了数据的强一致,适合对数据强一致要求很高的关键领域。(其实也不能100%保证强一致)

    更多相关内容
  • 正确理解二阶段提交(Two-Phase Commit)

    万次阅读 多人点赞 2019-03-07 15:42:56
    二阶段提交出现的背景是, 当我们使用分布式系统时, 如果分布式系统中的机器发生故障之后, 如何保证事务数据的一致性。 从一个场景入手, 假设一个人要从 A 银行向 B 银行进行跨行转账 100 元。 此时我们需要对 A ...

    明确问题

    从一个场景入手, 假设一个人要从 A 银行向 B 银行进行跨行转账 100 元。

    此时我们需要对 A 银行数据库中该用户的账户,做金额扣减操作( - 100), 同时对 B 银行数据库中该用户的账户做金额增加操作 ( +100)

    这两个操作( -100 和 + 100) 我们希望它们是一个事务, 要么同时成功, 要么同时失败 。

    此时我们的目标是希望有一个

    • 原子性的提交协议 (Atomic Commit Protocol)

    草稿方案

    • 场景难点一:
      • A --> B : 你提交我就提交
      • B 不理 A
      • 然后 ?
      • A 和 B 都没有办法继续
        在这里插入图片描述

    先提出一种拍脑门方案, 设置一个事务协调者( Transaction Coordinator)。

    由该协调者分别向 A 银行 , B银行发送指令, 发送完毕后直接予以返回成功

    在这里插入图片描述

    显然, 上述方案会出现很多问题:

    • 问题一: A 银行余额不足
      • A 未提交事务, B 却成功提交
    • 问题二: B 银行账户不存在
      • A 提交事务, B 未提交
    • 问题三: TC 到 B 中间的网络发生中断
      • A 提交, B 没提交
    • 问题四: TC 在给 B 发送指令前宕机
      • A 提交, B 没提交

    原子提交协议希望实现的2个特性

    由上面的场景, 我们可以总结出所有原子提交协议希望实现的2个特性

    • 安全性(Safety)
      • 如果任意一方 commit, 所有人必须都 commit
      • 如果任意一方中断,则没有任何一个人进行 commit
    • 存活性(Liveness)
      • 没有宕机或失败发生时, A 和 B 都能提交, 则提交
      • 如果发生失败时,最终能达成一个一致性结果(成功/失败), 予以响应, 不能一直等待

    正确的二段提交协议(Two-Phase Commit)

    在这里插入图片描述

    TC 发送 “prepare” 给 A 和 B
    等待响应结果
    A 和 B 均返回 Yes
    A 和 B 任意一个返回 No
    TC 向 A 和B 发送 commit 指令, 向 client 发送 ok 响应
    TC 向 A 和B 发送 aboort 指令
    A 和 B 在收到 TC 发送的 commit 指令后, 执行 commit 操作

    上面的流程看似简单, 但是有一个点容易被忽略:

    • 当 TC 收到 A 和 B 响应 “Yes” 后, 做出了 “commit” 的决定, 向 A /B 发送指令或, 并不需要再等待 A/B 的响应, 可以直接向 client 返回成功
    • 之所以可以这样做的原因是, 当 A/B 返回 Yes 后, 就代表 A 和 B 都做好了提交准备, 只要 TC 决定要提交,即使 A/B 宕机, 没有收到 TC 的 Commit 指令, 只要 A/B 被修复重启, A 和 B 都必须有能力成功完成提交操作。

    二阶段提交协议如何满足安全性(Safety)

    • 事务协调者 TC,作为一个中心, 统一收集了 A 和 B 是否有意愿(有能力)进行 commit
    • 事务协调者 TC 强制保证了, A, B 双方必须都有意愿提交时, 才进行 commit

    二阶段提交协议如何满足存活性( Liveness)

    遗憾的是: 上面描述的协议无法满足存活性。

    下面分析一下这个协议在执行过程中可能面临哪些问题

    • 问题1: 响应超时
      • 结点正常运行, 但是没有正常收到它所期待的响应, 可能原因如下
        • 其他的结点故障了
        • 网络情况不好, 数据包丢失了或网络干脆中断了
    • 问题2: 重启
      • 结点宕机, 重启以后, 如何恢复被中断的操作

    如何应对超时

    首先分析整个协议里面有哪些等待操作?

    1. 事务协调者 TC 需要等待 A 和 B 返回 “yes”/“no” 才能进行下一步操作
      在这里插入图片描述
    2. A 和 B 需要等待 TC 发送 “commit”/ “abort” 指令, 才能进行下一步操作
      在这里插入图片描述

    然后分析等待状态超时的时候, 是否有办法继续协议

    • 事务协调者 TC 需要等待 A 和 B 返回 “yes”/“no” 超时:

      • 此时 , TC 还没有发送过任何 “commit” 指令
      • TC 此时可以安全地发起终止 “abort” 指令, 放弃 commit
        • 上面这种做法, 保证了安全性, 放弃了存活性
        • 因为 A, B 可能都做好了准备进行提交, 只是 “yes” 信息没有成功被 TC 收到, 就导致了整个事务无法提交
        • 这种情况属于本可以提交而未提交, 也就是说 TC 采取了非常保守的方案
    • A 和 B 需要等待 TC 发送 “commit”/ “abort” 指令 超时:

      • 以 B 为例进行考虑( A 的情形完全对称)
      • 如果 B 之前回复的是 “no” , 那此时, B 可以无需等待 TC 回复就放弃 commit 操作, 因为 TC 即使收到了响应, 也会回复 “abort”, 这个行为是统一的
      • 如果 B 之前回复了 “Yes”,那此时 B 能单方面地直接进行 aboort 操作吗?
        • 不行! 因为, TC 此时可能已经成功收到了 A, B 返回的 “Yes”, 并且已经向 A 发送了 “Commit”, 然后再向 B 发送 “commit” 前宕机了
        • 如果 B 放弃了 commit 操作, 就会出现 A 执行了 commit, B 未执行 Commit 的情形, 显然违背了安全性(Safety)
      • 那 B 能单方面地直接进行 commit 操作吗?
        • “不行” ! 因为 A 可能返回给TC 的响应是 “No”
      • 那此时应该怎么办?:
        • 方案一: B 一直等待 TC 的 “commit”/ “abort” 指令
        • 方案二(更好): B 针对这种情形发起一轮终止协议操作(Termination Protocol)

    超时终止协议

    • B 向 A 发送状态查询请求, 询问 A 是否知道事务已经提交
    • 如果 B没有收到 A 的响应, B 无法进行后续操作, 只能继续等待
    • 如果 B 收到了 A 的响应, 则分如下几种情况:
      • A 回复说 , 它已经收到了来自 TC 的 “commit”/ “abort” 指令
        • 此时 B 可以执行 “commit”/ “abort”, 应为 TC 发给 B 的指令肯定和 A 一样
      • A 回复说, 它还没有向 TC 回复 “yes”/“no”,
        • 此时 B 和 A 都直接执行 abort 操作
        • 不必担心 TC, 因为 TC 尚未收到 A 的回复, 最终会根据 A 和B 的状态回复 client
      • A 回复说, 它向 TC 回复了 “no”
        • 此时 B 和 A 都直接执行 abort 操作
      • A 回复说, 它向 TC 回复了 “yes”
        • 此时 B 不能进行后续操作
        • 因为 TC 可能已经收到了 A 和 B 的 “Yes” 响应, 并且决定执行 “commit”, 向 A 和 B 发送了“commit” 指令, 只是没被 A 和 B 收到, 但是 TC 发送 “commit” 之后就会直接向客户端返回了 “ok”
        • TC 也有可能在等待 A 和 B 的响应过程中超时了, 直接进行了 “abort” 决定, 向 A 和 B 发送了 “abort” 指令, 只是没被 A 和 B 收到, 但是 TC 发送 “abort” 之后就会直接向客户端返回了 “fail”

    如何应对宕机重启

    基本原则: 一旦 TC 决定了 commit , 那么任意一个结点都不允许发生回滚

    有如下几种情形需要考虑:

    • TC 在做出决定后, 立即宕机了, 没有吧 commit 指令成功发送给 A 和 B , 然后被重新启动
    • A 和/或 B 在发送 Yes 的过程中, 宕机了, 没有把 " Yes" 成功发送给 TC , 然后被重新启动

    如果所有的结点, 都能知道他们在宕机前的状态是什么, 那就有如下几种解决方案:

    • A 或 B 相互发起之前描述的终止协议 Termination Protocol, 即相互询问是否知道事务已经交
    • A 和 B 也可以向 TC 发起状态查询操作, TC 可能知道事务是否已经提交

    如何保证在宕机重启后, 依旧能够记得宕机前的状态:

    • 在发送任何信息给其他结点前, 一定要先行将自己要回复的内容写入磁盘, 这样可以保证一旦宕机, 可以知道宕机前的状态。
      • 对于 TC 而言, 在向 A 和 B 发送 “commit” 指令前, 一定要先行将 “commit” 成功记录到磁盘
      • 对于 A/B 而言, 在向 TC 发送 “yes” 之前, 一定要先行将 “yes” 记录成功记录到磁盘

    这样重启之后就可以进行如下的操作:

    • 对于TC, 重启以后, 如果发现磁盘中没有记录 “commit” , 那就可以直接进行 “abort” 操作
      • 磁盘中没有 “commit” , 就说明根本没向 A/B 发送过 “commit”, 此时是安全的
    • 对于 A 或者 B , 重启以后, 如果发现磁盘中没有记录 “yes” , 那就可以直接进行 “abort” 操作
      • 磁盘中没有 “yes” , 说明根本没有向 TC 发送过 “yes”, TC 不可能做出 “commit” 操作, 执行abort 是安全的
    • 对于 A或者 B, 重启以后, 如果发现磁盘中有 “yes” 记录, 那就可以发起终止协议 “termination protocol”
      • 终止协议有可能陷入继续的等待中
    • 如果TC, A, B 都发生了重启操作, 只要当 3 个结点都恢复以后, 就可以向 TC 发起查询, 查看TC 的磁盘中是否存在 “commit” 记录, 如果存在, 则均可进行 “commit” 操作

    二阶段提交实现的工程化难点

    准备阶段到底干了什么

    回顾之前的内容,可以发现, 二阶段提交协议(Two-Phase Commit)的核心是

    • 引入了一个事务协调者(TC)
    • 在真正的提交操作前, 增加了一个准备阶段, 收集业务结点是否有能力进行提交

    部分程序员可能会对其工程实现的一个关键点产生误解:

    • 准备阶段就是开启一个事务, 执行所有的业务代码, 都不报错, 不执行事务的 commit 操作, 然后向 TC 回复 “Yes”, 表示我已准备好提交

    这种做法并不满足二阶段提交协议对于准备操作的要求:

    • 二阶段提交协议中, 业务结点回复 “Yes” , 代表它做好了提交操作的所有准备, 只要结点回复了 “Yes”, 即使突然发生宕机, 只要结点重新启动, 收到了 TC 发送的 commit 指令, 必须依旧能正确提交
    • 普通数据库如果在在一个事务中间发生了宕机(比如数据库所在机器直接停电), 重启以后, 数据库的默认行为是对处于中间状态的事务进行回滚操作, 并不具备继续等待并接受 commit 指令的能力

    以之前提到的转账操作为例, 如果 A 银行需要对转账客户的账户执行 -100 元操作, 当它向 TC 回复了 “Yes” 前, 应该完成以下操作:

    • 确定账户上有 100 待扣减, 将这100 元冻结, 其他的操作无法解冻, 转移这100元。
    • 留下必要的持久化记录, 确保即使宕机重启, 收到 “abort” 指令也有能力回滚到100 元被冻结前的状态
    • 留下必要的持久化记录, 确保即使宕机重启, 收到 “commit” 指令也有能力正确提交, 完成 -100 元操作
    • 留下必要的持久化记录, 标识自己已经完成了准备阶段的所有操作, 要向 TC 回复 “Yes” 指令

    只有以上这些操作都成功完成以后, 银行 A 才能尝试向 TC 发送 “Yes” 指令,否则就有违二阶段提交协议

    事务协调者是第三方吗

    二阶段提交中, 除了准备阶段, 另一个显眼的角色就是事务协调者( Transaction Coordinator)。

    此时就会有部分同学产生困惑, 事务协调者是否一定得是一个独立的机器,处于独立的结点。

    答案: 并不是!

    从准备阶段的要求就可以看出。 二阶段提交协议的核心, 是描述了在每一步操作前, 每一种角色应该达到什么状态, 具备什么能力。 具体在工程实现中, 这几种角色分布在几个结点, 以什么方式去实现, 都是可以的。

    以前文所举的银行转账操作为例。

    客户端 client 发起一个转账操作请求给 TC, 这个 TC 完全可以就属于银行 A。 只要银行 A 实现的 TC 在银行 A 数据库发起 -100 元的操作前,依旧先按照协议要求;

    • 模拟 prepare 阶段, 进行持久化记录
    • 做好 -100 元随时提交或回退的准备

    即可以根据银行 B 的准备阶段应答结果, 进行后续的操作。

    二阶段提交协议(Two-Phase Commit)的总结

    二阶段提交所说的二阶段分别指: Prepare , Commit 两个阶段

    二阶段提交满足如下性质:

    • 安全性: 所有的结点最终会达成一致的决定
    • 安全性: 只有当所有人都说了 “yes”, 才会执行提交
    • 存活性: 如果没有宕机和信息丢失, 提交肯定可以完成
    • 存活性: 如果发生宕机和信息丢失, 只要最终修复, 并且重启, 等待足够长的时间, 最终一定可以达成某项一致的结果(abort 或者 commit)

    可能有同学会有疑问, 那如果宕机不能被修复, 那些处于中间状态的记录怎么办:

    1985 年 Fischer, Lynch, Paterson 提出了定理:

    no distributed asynchronous protocol can correctly agree in presence of crash-failures

    翻译一下就是

    在出现宕机时(最终没有修复并重启), 不存在一种分布式的异步协议可以正确地达成一致结果(同时提供安全性和存活性)。

    所以有故障发生, 不修复还想保证记录达成一致? 洗洗睡吧

    展开全文
  • 图片来源:pexels网站java4all原创,欢迎关注摘要:本文主要讲解分布式事务中二阶段提交协议(2pc)相关基础概念,原理及详细的执行过程。1.理论基础二阶段提交(...

    640?wx_fmt=jpeg

    图片来源:pexels网站


    640?wx_fmt=png

    java4all原创,欢迎关注
    640?wx_fmt=gif

    摘要:本文主要讲解分布式事务中二阶段提交协议(2pc)相关基础概念,原理及详细的执行过程。

    640?wx_fmt=gif

    1.理论基础

    二阶段提交(Two-phaseCommit)是在计算机网络以及数据库领域内,为了使分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。

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

    因此,二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情况决定各参与者是要提交操作还是中止操作。

    两个阶段是指:

    • 第一阶段:准备阶段(投票阶段voting phase)

    • 第二阶段:提交阶段(执行阶段commit phase)


    2.pc实现

    2.1准备阶段

    事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息,每个参与者要么直接返回失败(如权限验证失败),要么在本地执行事务,写本地的redo和undo日志,但不提交。 

    这个准备阶段又可以细分为三个步骤:

    1.协调者节点向所有参与者节点询问是否可以执行提交操作(vote),并开始等待各参与者节点的响应。 

    2.参与者节点执行询问发起为止的所有事务操作,并将Undo信息和Redo信息写入日志。(注意理解这个点:若成功这里其实每个参与者已经执行了事务操作,只是执行完事务操作,并没有进行commit或者roolback )。

    3.各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功,则它返回一个"同意"消息;如果参与者节点的事务操作实际执行失败,则它返回一个"中止"消息。 

    准备阶段如下:

    640?wx_fmt=png


    640?wx_fmt=png


    2.2提交阶段

    如果协调者收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;

    参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源) 


    在提交阶段,又分为2种情况:

    1.当协调者节点从所有参与者节点获取的都是“同意”时:

    1)协调者节点向所有参与者节点发出"正式提交(commit)"的请求。

    2)参与者节点正式完成commit操作,并释放在整个事务期间内占用的资源。

    3)参与者节点向协调者节点发送"完成"消息。

    4)协调者节点收到所有参与者节点反馈的"完成"消息后,完成事务。


    640?wx_fmt=png


    640?wx_fmt=png


    2.当协调者节点在第一阶段中收到的反馈有“终止”,或者协调者节点在询问超时之前没有获取到所有参与者节点的“同意”时:

    1)协调者节点向所有参与者节点发出"回滚操作(rollback)"的请求。

    2)参与者节点利用之前写入的Undo信息执行回滚,并释放在整个事务期间内占用的资源。

    3)参与者节点向协调者节点发送"回滚完成"消息。

    4)协调者节点受到所有参与者节点反馈的"回滚完成"消息后,取消事务。

    不管最后结果如何,第二阶段都会结束当前事务。 

    当第一阶段的反馈结果不全是“同意”,执行流程如下:


    640?wx_fmt=png


    640?wx_fmt=png


    640?wx_fmt=png


    640?wx_fmt=png


    3.2pc优缺点

    3.1同步阻塞问题

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

    3.2单点故障

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

    3.3数据不一致

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

    3.4不确定性

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

     

    由于二阶段提交存在着上述同步阻塞、单点问题、脑裂等缺陷,所以,研究者们在二阶段提交的基础上做了改进,提出了三阶段提交。 


    上一篇:分布式事务-01:分布式事务产生原因及相关概念

    下一篇:分布式事务-03:3PC 三阶段提交协议实现过程及原理


    对文章内容有疑问或者不同的见解,欢迎关注公众号java4all,或添加我的微信w1186355422一起交流讨论。

    640?wx_fmt=png

    640?wx_fmt=jpeg

    IT云清

    640?wx_fmt=jpeg

    展开全文
  • TwoPhaseCommitSinkFunction二阶段提交

    千次阅读 2020-11-23 16:36:32
    1,什么是二阶段提交? TwoPhaseCommitSinkFunction Flink 已经为我们提供了实现 Exactly-Once 的 FlinkKafkaProducer 类。如下图所示:它实现了TwoPhaseCommitSinkFunction类,并重写了其中的方法,通过 2PC (Two...

    1,什么是二阶段提交?

    TwoPhaseCommitSinkFunction

    Flink 已经为我们提供了实现 Exactly-Once 的 FlinkKafkaProducer 类。如下图所示:它实现了 TwoPhaseCommitSinkFunction类,并重写了其中的方法,通过 2PC (Two Phase Comit) 二阶提交的方式,实现了 Exactly-Once。
    在这里插入图片描述
           使用关系型数据库 MySQL,开启 CheckPoint 机制的前提下,为了保证前一次 CheckPoint 成功后到这次 CheckPoint 成功之前这段时间内的数据不丢失,如果执行到一半过程任务失败了,从而导致前一次CheckPoint成功后到任务失败前的数据已经存储到了MySQL,然而这部分数据并没有写入到 CheckPoint。如果任务重启后,前一次CheckPoint成功后到任务失败前的数据便会再次写入MySQL,从而导致数据重复的问题。这种情况,便使用到了 TwoPhaseCommitSinkFunction类,以此来实现 MySQL 关系型数据库的二阶提交。

     

    2,需要什么条件?

    sink对象需要支持事务,很可惜大部分都不支持,那怎么办呢?

    目前解决方案就是不停重复的写,或者写入缓存,或者写入外部。

    JBDC案例:

     

    public class MySqlTwoPhaseCommitSink extends TwoPhaseCommitSinkFunction<String>,Connection,Void> {

    主要实现TwoPhaseCommitSinkFunction 函数。

     

     

    3,Flink写入doris实现二阶段提交。

    目前不支持,doris stream load是原子性的,它是自动提交事务的。

    参考文章:

    https://blog.bcmeng.com/post/meituan-doris.html#%E5%8F%98%E5%8C%96%E7%BB%B4%E8%A1%A8-join

    https://blog.bcmeng.com/post/kafka-to-doris.html#doris-stream-load-%E5%8E%9F%E7%90%86

    https://blog.csdn.net/lzb348110175/article/details/104534095

    https://blog.51cto.com/simplelife/2401521

    展开全文
  • 最近在看分布式事务,于是网上搜索相关资料,霎时间,对方给我扔来了一大堆概念,什么二阶段提交、三阶段提交、TCC补偿机制、CAP理论、ACID、BASE等等等,它们被零散地分散到各种各样的文章里。这里我根据自己所学习...
  • Mysql两阶段提交

    千次阅读 2021-01-17 16:04:43
    在看Mysql相关内容的时候经常听到两阶段提交,那以前都是云里雾里的,通过学习丁奇老师的这篇文章彻底明白了其流程和含义。提到两阶段提交,必须先说一下两个日志:redo log和binlog重要的日志模块:redo log数据在...
  • 分布式事务两阶段提交

    千次阅读 2022-02-20 15:18:20
    分布式两阶段提交
  • 分布式事务之两阶段提交

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

    千次阅读 2022-03-29 12:02:26
    什么是两阶段提交1.1 binlog 与 redologbinlogredo log1.2 两阶段提交2. 为什么需要两阶段提交3. 小结 为什么要两阶段提交?一阶段提交不行吗? 小伙伴们知道,MySQL 中的事务是两阶段提交,我们见到的很多分布式...
  • 简单谈谈MySQL的两阶段提交

    千次阅读 多人点赞 2021-12-19 21:16:59
    在讲解两阶段提交之前,需要对MySQL中的三种日志即binlog、redo log与undo log有一定的了解。 在这三种日志中,很多同学会把binlog与redo log混淆,下面使用一张表格来简单对比下两者的区别。 ...
  • MySQL的两阶段提交(数据一致性)

    千次阅读 2022-05-23 21:19:44
    在两阶段提交的情况下,是怎么实现崩溃恢复的呢? 在讲解两阶段提交之前,需要对MySQL中的binlog、redo log和undo log有一定的了解。两者的适用场景不同,binlog适用于维护集群内数据的一致性,redo log用于崩溃恢复...
  • rocketMq事务消息原理与二阶段提交

    千次阅读 2019-04-12 14:45:16
    两个方法的返回值都是消息状态,就是告诉broker应该提交或者回滚半消息 从上面的流程中,我们不难看到,rocketMq通过二阶段提交的思想实现了事务消息,那我们就顺便说说二阶段提交: 我们将使用二阶段提交保证数据...
  • 在分布式系统中,每一个机器...二阶段提交 二阶段提交将一个事务的处理过程分为投票和执行两个阶段,核心是对每个事务都采用先尝试后提交的处理方式 阶段一:提交事务请求 (1)事务询问 协调者向所有的参与者发送.
  • 浅谈两阶段提交和三阶段提交

    千次阅读 2020-03-07 20:30:23
    部分阐述三阶段提交的原理和优缺点。 第三部分阐述如何解决业务中最终一致性的问题。 一.两阶段提交阶段提交方法是用于分布式事务中用来完成事务操作的。 两阶段提交是一种思想,XA协议,TCC,Paxos...
  • 二阶段提交,三阶段提交,Paxos

    千次阅读 2017-02-08 10:17:50
    随着大型网站的各种高并发访问、海量数据处理等场景越来越多,...本文主要介绍关于分布式事务,二阶段提交和三阶段提交。  在分布式系统中,为了保证数据的高可用,通常,我们会将数据保留多个副本(replica),这些
  • 什么是2PC两阶段提交 2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase)、提交阶段(commit phase). 2是指两个阶段,P是指准备阶段,C是指提交阶段。 举例:张三和李四好久不见,...
  • 2PC即两阶段提交,是将整个事务流程分为两个阶段,准备阶段(Prepare phase)、提交阶段(commit phase)。2是指两个阶段,P是指准备阶段,C是指提交阶段。 举例:张三和李四好久不见,一起吃饭。饭店老板要求先...
  • 在分布式系统中,事务往往包含有多个参与者的活动,单个参与者上的活动是能够保证原子性的,而多个参与者之间原子性的保证则需要通过两阶段提交实现,两阶段提交是分布式事务实现的关键。
  • 所有关于分布式事务的介绍中都必然会讲到两阶段提交,因为它是实现XA分布式事务的关键(确切地说:两阶段提交主要保证了分布式事务的原子性:即所有结点要么全做要么全不做)。所谓的两个阶段是指:第一阶段:准备阶段...
  • 面试解析mysql()二阶段提交

    千次阅读 2021-01-06 19:23:54
    面试解析mysql 二阶段提交 熊大 1、假如dba对你说它可以恢复任意半个月的数据他是怎么做到的呢? 2、一个sql的更新语句执行流程是什么? 3、二阶段提交本质是什么?为什么必须这样做?
  • 分布式两阶段提交和三阶段提交

    万次阅读 多人点赞 2016-07-31 23:59:26
    随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何...本文主要介绍关于分布式事务,二阶段提交和三阶段提交。 在分布式系统中,为了保证数据的高可用,通常,我们会将数据保留多个副本(replica),这些
  • PostgreSQL中的两阶段提交

    千次阅读 2018-10-17 18:29:35
    多台数据库之间的原子性,需要通过两阶段提交协议来实现。  两阶段提交协议的步骤: (1)应用程序调用事务协调器中的提交方法。 (2)事务协调器将联络事务中涉及的所有数据库,通知它们准备提交事务(PREPARE ...
  • 二阶段提交的阶段二中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后...
  • Flink实现阶段提交 Flink将两阶段提交协议中的通用逻辑抽象为了一个类——TwoPhaseCommitSinkFunction。 我们在实现端到端exactly-once的应用程序时,只需实现这个类的4个方法即可: beginTransaction:开始事务...
  • Flink两阶段提交

    万次阅读 多人点赞 2019-05-17 10:22:47
    文章目录两阶段提交阶段提交 何为EXACTLY_ONCE? EXACTLY_ONCE简称EOS,每条输入消息只会影响最终结果一次,注意这里是影响一次,而非处理一次,Flink一直宣称自己支持EOS,实际上主要是对于Flink应用内部来说的...
  • 阶段提交(Two-Phase Commit)

    千次阅读 2019-10-22 18:40:14
    阶段提交阶段提交是一种同步协议,是计算机网络尤其是在数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务处理过程中保持原子性和一致性而设计的一种算法。 两阶段提交的执行过程 在两阶段提交...
  • mysql之两阶段提交

    千次阅读 2020-08-17 17:38:27
    什么是两阶段提交 当有数据修改时,会先将修改redo log cache和binlog cache然后在刷入到磁盘形成redo log file,当redo log file全都刷入到磁盘时(prepare 状态)和提交成功后才能将binlog cache刷入磁盘,当...
  • TCC和两阶段提交

    千次阅读 2019-09-15 20:00:10
    经常在网络上看见有人介绍TCC时,都提一句,”TCC是两阶段提交的一种”。其理由是TCC将业务逻辑分成try、confirm/cancel在两个不同的阶段中执行。其实这个说法,是不正确的。可能是因为既不太了解两阶段提交机制、也...
  • sink —— kafka producer 作为sink,采用两阶段提交 sink,需要实现一个 TwoPhaseCommitSinkFunction 步骤: 第一条数据来了之后,开启一个 kafka 的事务(transaction),正常写入 kafka 分区日志但标记为未提交...
  • 阶段提交实现精确一次性语义的核心原理。其核心原理就是在Barrier对齐的情况下所有的算子都成功的完成了Checkpoint,就完成了真正的两阶段提交。 JobManager向Source发送Barrier,开始进入pre-Commit阶段,当...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 233,675
精华内容 93,470
关键字:

二阶段提交实现