精华内容
下载资源
问答
  • 两阶段提交
    千次阅读
    2022-05-23 21:19:44


    在讲解两阶段提交之前,需要对MySQL中的binlog、redo log和undo log有一定的了解。两者的适用场景不同,binlog适用于维护集群内数据的一致性,redo log用于崩溃恢复,undo log相对于前面两种日志更好理解些,就是为了回滚事务用的。

    两阶段提交过程

    InnoDB引擎更新一条指定数据的过程如下:
    在这里插入图片描述

    可以看到,InnoDB在写redo log时,并不是一次性写完的,而有两个阶段,Prepare与Commit阶段,这就是"两阶段提交"的含义。

    为什么要写redo log,不写redo log的话,根本就不会出现“两阶段提交”的麻烦事啊?

    先说结论:在于崩溃恢复

    MySQL为了提升性能,引入了BufferPool缓冲池。查询数据时,先从BufferPool中查询,查询不到则从磁盘加载在BufferPool。

    每次对数据的更新,也不总是实时刷新到磁盘,而是先同步到BufferPool中,涉及到的数据页就会变成脏页。同时会启动后台线程,异步地将脏页刷新到磁盘中,来完成BufferPool与磁盘的数据同步。如果在某个时间,MySQL突然崩溃,则内存中的BufferPool就会丢失,剩余未同步的数据就会直接消失。

    虽然在更新BufferPool后,也写入了binlog中,但binlog并不具备crash-safe的能力。因为崩溃可能发生在写binlog后,刷脏前。在主从同步的情况下,从节点会拿到多出来的一条binlog。所以server层的binlog是不支持崩溃恢复的,只是支持误删数据恢复。InnoDB考虑到这一点,自己实现了redo log。

    为什么要写两次redo log,写一次不行吗?

    redo log与binlog都写一次的话,也就是存在以下两种情况:

    1. 先写binlog,再写redo log:当前事务提交后,写入binlog成功,之后主节点崩溃。在主节点重启后,由于没有写入redo log,因此不会恢复该条数据。而从节点依据binlog在本地回放后,会相对于主节点多出来一条数据,从而产生主从不一致。
    2. 先写redo log,再写binlog:当前事务提交后,写入redo log成功,之后主节点崩溃。在主节点重启后,主节点利用redo log进行恢复,就会相对于从节点多出来一条数据,造成主从数据不一致。

    因此,只写一次redo log与binlog,无法保证主节点崩溃恢复与从节点本地回放数据的一致性

    在两阶段提交的情况下,是怎么实现崩溃恢复的呢?

    首先比较重要的一点是,在写入redo log时,会顺便记录XID,即当前事务id。在写入binlog时,也会写入XID。因此存在以下三种情况:

    1. 如果在写入redo log之前崩溃,那么此时redo log与binlog中都没有,是一致的情况,崩溃也无所谓。
    2. 如果在写入redo log prepare阶段后立马崩溃,之后会在崩恢复时,由于redo log没有被标记为commit。于是拿着redo log中的XID去bin log中查找,此时肯定是找不到的,那么执行回滚操作。
    3. 如果在写入bin log后立马崩溃,在恢复时,由redo log中的XID可以找到对应的bin log,这个时候直接提交即可。

    总的来说,在崩溃恢复后,只要redo log不是处于commit阶段,那么就拿着redo log中的XID去binlog中寻找,找得到就提交,否则就回滚。在这样的机制下,两阶段提交能在崩溃恢复时,能够对提交中断的事务进行补偿,来确保redo log与binlog的数据一致性。

    更多相关内容
  • 两阶段提交

    2018-11-01 19:47:05
    2PC在执行过程中,所有节点都处于阻塞状态,所有节点所持有的资源(例如数据库数据,本地文件等)都处于封锁状态。
  • 简单谈谈MySQL的两阶段提交

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

    一、简单回顾三种日志

    在讲解两阶段提交之前,需要对MySQL中的三种日志即binlog、redo log与undo log有一定的了解。

    在这三种日志中,很多同学会把binlog与redo log混淆,下面使用一张表格来简单对比下两者的区别。

    当然,如果对binlog与redo log有更深的兴趣,可以参考我的另外一篇文章数据库日志——binlog、redo log、undo log扫盲

    这边只要记住两者的归属于适用场景即可,binlog适用于维护集群内数据的一致性,而redo log用于崩溃恢复。

    undo log相对于前面两种日志更好理解些,就是为了回滚事务用的。

    MVCC原理其实就是undo log版本链与ReadView的结合,想要弄清楚如何在快照读的情况下实现事务之间的隔离性,可以移步我的这篇文章通俗易懂的MySQL事务及MVCC原理,我先收藏了!


    二、一条语句的执行过程

    先从整体的角度来观测某件事物,可以避免一上来就陷入局部的泥潭当中。

    MySQL分为Server层与存储引擎层,Server层包括连接器、分析器、优化器于执行器等。

    而存储引擎层被设计为支持可插拔式,可以支持InnoDB、MyISAM等存储引擎。

    一般来说,一条语句,不论是查询还更新,都会走以下的流程。

    这部分不是本文的重点,就简单说下各个组件的作用,大家有个印象就行。

    连接器

    用于和客户端建立连接,管理连接。检查连接中的用户名密码是否正确吗,以及是否对表有操作权限。

    分析器

    只要是进行词法、语法分析,区分sql关键词与非关键词,生成一颗语法树。如果生成语法树失败,则证明你的sql有语法错误。

    之后对语法树进行一些剪枝操作,去除一些无用的条件等。

    优化器

    生成sql的执行计划,你可以使用explain来查看执行计划。

    会基于某些规则来选择走的索引项,在取样的时候可能会存在误差,可是使用force index来强制走某条索引。

    执行器

    依据执行计划,调用存储引擎的接口,来实现对数据的读写操作。

    我们会在下一小节中,简单讲述执行器和存储引擎在两阶段提交中的交互流程。


    三、两阶段提交

    先看执行器与InnoDB引擎是如何更新一条指定的数据的:

    可以看到,InnoDB在写redo log时,并不是一次性写完的,而有两个阶段,Prepare与Commit阶段,这就是"两阶段提交"的含义。

    为什么要写redo log,不写redo log的话,根本就不会出现“两阶段提交”的麻烦事啊?

    先说结论:在于崩溃恢复。

    MySQL为了提升性能,引入了BufferPool缓冲池。查询数据时,先从BufferPool中查询,查询不到则从磁盘加载在BufferPool。

    每次对数据的更新,也不总是实时刷新到磁盘,而是先同步到BufferPool中,涉及到的数据页就会变成脏页。

    同时会启动后台线程,异步地将脏页刷新到磁盘中,来完成BufferPool与磁盘的数据同步。

    如果在某个时间,MySQL突然崩溃,则内存中的BufferPool就会丢失,剩余未同步的数据就会直接消失。

    虽然在更新BufferPool后,也写入了binlog中,但binlog并不具备crash-safe的能力。

    因为崩溃可能发生在写binlog后,刷脏前。在主从同步的情况下,从节点会拿到多出来的一条binlog。

    所以server层的binlog是不支持崩溃恢复的,只是支持误删数据恢复。InnoDB考虑到这一点,自己实现了redo log。

    为什么要写两次redo log,写一次不行吗?

    先不谈到底写几次redo log合适,如果只写一次redo log会有什么样的问题呢?

    redo log与binlog都写一次的话,也就是存在以下两种情况:

    先写binlog,再写redo log

    当前事务提交后,写入binlog成功,之后主节点崩溃。在主节点重启后,由于没有写入redo log,因此不会恢复该条数据。

    而从节点依据binlog在本地回放后,会相对于主节点多出来一条数据,从而产生主从不一致。

    先写redo log,再写binlog

    当前事务提交后,写入redo log成功,之后主节点崩溃。在主节点重启后,主节点利用redo log进行恢复,就会相对于从节点多出来一条数据,造成主从数据不一致。

    因此,只写一次redo log与binlog,无法保证这两种日志在事务提交后的一致性。

    也就是无法保证主节点崩溃恢复与从节点本地回放数据的一致性。

    在两阶段提交的情况下,是怎么实现崩溃恢复的呢?

    首先比较重要的一点是,在写入redo log时,会顺便记录XID,即当前事务id。在写入binlog时,也会写入XID。

    如果在写入redo log之前崩溃,那么此时redo log与binlog中都没有,是一致的情况,崩溃也无所谓。

    如果在写入redo log prepare阶段后立马崩溃,之后会在崩恢复时,由于redo log没有被标记为commit。于是拿着redo log中的XID去binlog中查找,此时肯定是找不到的,那么执行回滚操作。

    如果在写入binlog后立马崩溃,在恢复时,由redo log中的XID可以找到对应的binlog,这个时候直接提交即可。

    总的来说,在崩溃恢复后,只要redo log不是处于commit阶段,那么就拿着redo log中的XID去binlog中寻找,找得到就提交,否则就回滚。

    在这样的机制下,两阶段提交能在崩溃恢复时,能够对提交中断的事务进行补偿,来确保redo log与binlog的数据一致性。

    展开全文
  • 分布式事务两阶段提交

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

    分布式事务两阶段提交。

    一、分布式数据库的一致性

    分布式数据库有所谓CAP理论,即一致性( Consistency)、可用性( Availability)、分区容错性(分区耐受性, Partition Tolerance)不可得兼,只能同时满足其中2个。

    一致性: 在分布式系统中数据往往存在多个副本,一致性描述的是这些副本中的数据在内容和组织上的一致。

    可用性: 描述系统对用户的服务能力,所谓可用是指在用户能够容忍的时间范围内返回用户期望的结果。

    分区容错性:
    分布式系统通常由多个节点构成,由于网络是不可靠的,所以存在分布式集群中的节点因为网络通信故障导致被孤立成一个个小集群的可能性,即网络分区,分区容错性要求在出现网络分区时系统仍然能够对外提供一致性的可用服务。

    由于分布式数据库通过网络连接,要始终假设网络是不可靠的,所以分区容错性是硬性规定;可用性既是一个系统基本的要求,也是分布式数据库的卖点,不可或缺;因此,只有牺牲一致性了。所谓一致性,就是分布式数据库的各个节点数据可能不能同步。

    但是,凡事无绝对。由于网络技术进步,网络环境越来越好,因此,未出现分区故障时,应当考虑满足一致性和可用性。二阶段提交就是一种保持一致性的算法。

    二、两阶段提交协议

    两阶段提交协议(2PC:Two-Phase Commit)

    该协议将一个分布式的事务过程拆分成两个阶段: 投票事务提交 。为了让整个数据库集群能够正常的运行,该协议指定了一个 协调者 单点,用于协调整个数据库集群各节点的运行。为了简化描述,我们将数据库集群中的各个节点称为 参与者

    1、第一阶段:投票
    打探数据库集群中的各个参与者是否能够正常的执行事务,具体步骤如下:

    1)协调者向所有的参与者发送事务执行请求,并等待参与者反馈事务执行结果;
    2)参与者收到请求之后,执行事务但不提交,并记录事务日志;
    3)参与者将自己事务执行情况反馈给协调者,同时阻塞等待协调者的后续指令。

    2、第二阶段:事务提交
    在经过第一阶段协调者的询盘之后,各个参与者会回复自己事务的执行情况,这时候存在 3 种可能性:

    1)所有的参与者都回复能够正常执行事务。
    2)一个或多个参与者回复事务执行失败。
    3)协调者等待超时。

    第1种情况,所有的参与者都回复能够正常执行事务,于是协调者让它们都提交事务,具体如下:
    .在这里插入图片描述
    对于后面2种情况,则做回滚处理
    在这里插入图片描述
    3、两阶段提交协议的缺点
    两阶段提交协议原理简单、易于实现,但是缺点也是显而易见的,包含如下:

    1)单点故障
    协调者

    2)同步阻塞
    参与者都需要听从协调者的统一调度,期间处于阻塞状态而不能从事其他操作,效率极其低下

    3)数据不一致性
    协调者发出的事务 commit 通知有可能因为网络原因无法传递到部分参与者,造成它们一直处于阻塞状态,导致数据不一致。

    针对上述问题可以引入 超时机制互询机制 在很大程度上予以解决。简单来说就是:

    协调者如果超时未收到参与者的回复,可以发出回滚指令;但参与者如果超时未收到协调者commit指令,则不能擅自回滚,它可以转而咨询其他参与者。如果有参与者表示收到了commit指令或rollback指令,则它可以大胆跟随;如果有参与者尚未到达就绪状态,则说明协调者肯定因为超时发出了回滚指令;否则继续咨询另一个参与者。最坏的情况是,所有参与者都处于就绪状态,这样将陷入长时间的阻塞状态。

    三、三阶段提交协议

    三阶段提交协议(3PC:Three-Phase Commit)

    针对两阶段提交存在的问题,三阶段提交协议通过引入一个 预询盘 阶段,以及超时策略来减少整个集群的阻塞时间,提升系统性能。三阶段提交的三个阶段分别为:预询盘(can_commit)、预提交(pre_commit),以及事务提交(do_commit)。

    与两阶段提交相比,主要差别是多了一个预询盘阶段。协调者会首先咨询参与者是否能参与事务处理,参与者只需回答一个预估值即可,并不做什么处理,过程是轻量的。

    四、两阶段提交协议 VS 三阶段提交协议

    两阶段提交协议中长时间阻塞状态发生的几率还是非常低的,所以尽管三阶段提交协议对于数据强一致性更有保障,但因为效率问题,两阶段提交协议实际更受欢迎。

    参考资料:
    分布式事务:两阶段提交与三阶段提交

    展开全文
  • MySQL 为什么需要两阶段提交

    千次阅读 2022-03-29 12:02:26
    小伙伴们知道,MySQL 中的事务是两阶段提交,我们见到的很多分布式事务也都是两阶段提交的,例如 Seata,那么为什么要两阶段提交呢?一次直接提交了不行吗?今天我们来聊聊这个话题。 关于分布式事务 seata,不懂的...


    为什么要两阶段提交?一阶段提交不行吗?

    小伙伴们知道,MySQL 中的事务是两阶段提交,我们见到的很多分布式事务也都是两阶段提交的,例如 Seata,那么为什么要两阶段提交呢?一次直接提交了不行吗?今天我们来聊聊这个话题。

    关于分布式事务 seata,不懂的小伙伴可以参考松哥之前的文章,传送门:

    1. 什么是两阶段提交

    1.1 binlog 与 redolog

    binlog

    binlog 我们中文一般称作归档日志,如果大家看过松哥之前发的 MySQL 主从搭建,应该对这个日志有印象,当我们搭建 MySQL 主从的时候就离不开 binlog(传送门:MySQL8 主从复制踩坑指南)。

    binlog 是 MySQL Server 层的日志,而不是存储引擎自带的日志,它记录了所有的 DDL 和 DML(不包含数据查询语句)语句,而且是以事件形式记录,还包含语句所执行的消耗的时间等,需要注意的是:

    • binlog 是一种逻辑日志,他里边所记录的是一条 SQL 语句的原始逻辑,例如给某一个字段 +1,注意这个区别于 redo log 的物理日志(在某个数据页上做了什么修改)。
    • binlog 文件写满后,会自动切换到下一个日志文件继续写,而不会覆盖以前的日志,这个也区别于 redo log,redo log 是循环写入的,即后面写入的可能会覆盖前面写入的。
    • 一般来说,我们在配置 binlog 的时候,可以指定 binlog 文件的有效期,这样在到期后,日志文件会自动删除,这样避免占用较多存储空间。

    根据 MySQL 官方文档的介绍,开启 binlog 之后,大概会有 1% 的性能损耗,不过这还是可以接受的,一般来说,binlog 有两个重要的使用场景:

    • MySQL 主从复制时:在主机上开启 binlog,主机将 binlog 同步给从机,从机通过 binlog 来同步数据,进而实现主机和从机的数据同步。
    • MySQL 数据恢复,通过使用 mysqlbinlog 工具再结合 binlog 文件,可以将数据恢复到过去的某一时刻。

    redo log

    前面我们说的 binlog 是 MySQL 自己提供的,在 MySQL 的 server 层,而 redo log 则不是 MySQL 提供的,是存储引擎 InnoDB 自己提供的。所以在 MySQL 中就存在两类日志 binlog 和 redo log,存在两类日志既有历史原因(InnoDB 最早不是 MySQL 官方存储引擎)也有技术原因,这个咱们以后再细聊。

    我们都知道,事务的四大特性里面有一个是持久性,即只要事务提交成功,那么对数据库做的修改就被永久保存下来了,写到磁盘中了,怎么做到的呢?其实我们很容易想到是在每次事务提交的时候,将该事务涉及修改的数据页全部刷新到磁盘中,一旦写到磁盘中,就不怕数据丢失了。

    但是要是每次都这么搞,数据库就不知道慢到哪里去了!因为 Innodb 是以页为单位进行磁盘交互的,而一个事务很可能只修改一个数据页里面的几个字节,这个时候将完整的数据页刷到磁盘的话,不仅效率低,也浪费资源。效率低是因为这些数据页在物理上并不连续,将数据页刷到磁盘会涉及到随机 IO。

    有鉴于此,MySQL 设计了 redo log,在 redo log 中只记录事务对数据页做了哪些修改。那有人说,写 redo log 不就是磁盘 IO 吗?而写数据到磁盘也是磁盘 IO,既然都是磁盘 IO,那干嘛不把直接把数据写到磁盘呢?还费这事!

    此言差矣。

    写 redo log 跟写数据有一个很大的差异,那就是 redo log 是顺序 IO,而写数据涉及到随机 IO,写数据需要寻址,找到对应的位置,然后更新/添加/删除,而写 redo log 则是在一个固定的位置循环写入,是顺序 IO,所以速度要高于写数据。

    redo log 本身又分为:

    • 日志缓冲(redo log buffer),该部分日志是易失性的。
    • 重做日志(redo log file),这是磁盘上的日志文件,该部分日志是持久的。

    MySQL 每执行一条 DML 语句,先将记录写入 redo log buffer,后续在某个时间点再一次性将多个操作记录写到 redo log file,这种先写日志再写磁盘的技术就是 MySQL 里经常说到的 WAL(Write-Ahead Logging) 技术(预写日志)。

    1.2 两阶段提交

    在 MySQL 中,两阶段提交的主角就是 binlog 和 redolog,我们来看一个两阶段提交的流程图:

    从上图中可以看出,在最后提交事务的时候,有 3 个步骤:

    1. 写入 redo log,处于 prepare 状态。
    2. 写 binlog。
    3. 修改 redo log 状态变为 commit。

    由于 redo log 的提交分为 preparecommit 两个阶段,所以称之为两阶段提交。

    2. 为什么需要两阶段提交

    如果没有两阶段提交,那么 binlog 和 redolog 的提交,无非就是两种形式:

    1. 先写 binlog 再写 redolog。
    2. 先写 redolog 再写 binlog。

    这两种情况我们分别来看。

    假设我们要向表中插入一条记录 R,如果是先写 binlog 再写 redolog,那么假设 binlog 写完后崩溃了,此时 redolog 还没写。那么重启恢复的时候就会出问题:binlog 中已经有 R 的记录了,当从机从主机同步数据的时候或者我们使用 binlog 恢复数据的时候,就会同步到 R 这条记录;但是 redolog 中没有关于 R 的记录,所以崩溃恢复之后,插入 R 记录的这个事务是无效的,即数据库中没有该行记录,这就造成了数据不一致。

    相反,假设我们要向表中插入一条记录 R,如果是先写 redolog 再写 binlog,那么假设 redolog 写完后崩溃了,此时 binlog 还没写。那么重启恢复的时候也会出问题:redolog 中已经有 R 的记录了,所以崩溃恢复之后,插入 R 记录的这个事务是有效的,通过该记录将数据恢复到数据库中;但是 binlog 中还没有关于 R 的记录,所以当从机从主机同步数据的时候或者我们使用 binlog 恢复数据的时候,就不会同步到 R 这条记录,这就造成了数据不一致。

    那么按照前面说的两阶段提交就能解决问题吗?

    我们来看如下三种情况:

    **情况一:**一阶段提交之后崩溃了,即写入 redo log,处于 prepare 状态 的时候崩溃了,此时:

    由于 binlog 还没写,redo log 处于 prepare 状态还没提交,所以崩溃恢复的时候,这个事务会回滚,此时 binlog 还没写,所以也不会传到备库。

    **情况二:**假设写完 binlog 之后崩溃了,此时:

    redolog 中的日志是不完整的,处于 prepare 状态,还没有提交,那么恢复的时候,首先检查 binlog 中的事务是否存在并且完整,如果存在且完整,则直接提交事务,如果不存在或者不完整,则回滚事务。

    **情况三:**假设 redolog 处于 commit 状态的时候崩溃了,那么重启后的处理方案同情况二。

    由此可见,两阶段提交能够确保数据的一致性。

    3. 小结

    好啦,今天和小伙伴们简单聊了一下 MySQL 中的两阶段提交,有问题欢迎留言讨论。

    展开全文
  • 分布式事务之两阶段提交

    千次阅读 2021-10-31 17:00:40
    两阶段提交协议 两阶段提交协议把分布式事务分为个阶段,一个是准备阶段,另一个是提交阶段; 准备阶段和提交阶段都是由事务管理器发起的; 我们可以将事务管理器称为协调者,将资源管理器称为参与者。 流程 ...
  • 3PC的优点和缺点: 优点: 1.相比2PC,最大的优点就是降低了第一阶段的阻塞范围(第一阶段是不阻塞的...2.能够在单点故障后继续达成一致(2PC在提交阶段会出现此问题),而3PC会根据协调者的状态进行回滚或者提交 ...
  • 介绍了对于CAP定理,以及两阶段提交与三阶段提交优缺点的理解。
  • 两阶段提交和三阶段提交

    千次阅读 2020-11-03 23:47:32
    分布式提交的问题 在分布式系统中,为了保证数据的高可用,通常会将数据保留多个副本(replica),这些副本会放置在不同的物理的...下面介绍的两阶段提交和三阶段提交都是通过引入一个协调者来进行协调。 两阶段提交 概述
  • 文章目录 两阶段提交协议 1. 两阶段提交的前提条件 2. 两阶段提交的基本算法 a. 第一阶段(提交请求阶段) b. 第二阶段(提交执行阶段) 3. 两阶段提交的缺点 Flink-两阶段提交协议 1. Flink-Kafka构建端到端Exactly...
  • 3.在Flink KafkaProducer中继承了TwoPhaseCommitSinkFunction来实现两阶段提交的功能(要弄清楚阶段分别干了什么事) 该类下 有四个子类 protected abstract TXN beginTransaction() throws Exceptio...
  • mysql之两阶段提交

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

    2022-08-08 21:04:26
    两阶段提交1
  • 两阶段提交(Two-Phase Commit)

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

    千次阅读 2021-01-17 16:04:43
    在看Mysql相关内容的时候经常听到两阶段提交,那以前都是云里雾里的,通过学习丁奇老师的这篇文章彻底明白了其流程和含义。提到两阶段提交,必须先说一下个日志:redo log和binlog重要的日志模块:redo log数据在...
  • 详细介绍了MySQL中一条更新sql的执行流程,以及日志的两阶段提交分布式事务,以及崩溃恢复流程,以及多事务组提交策略。
  • 两阶段提交协议中所存在的长时间阻塞状态发生的几率还是非常低的,所以虽然三阶段提交协议相对于两阶段提交协议对于数据强一致性更有保障,但是因为效率问题,两阶段提交协议在实际系统中反而更加受宠。 ...
  • 浅谈两阶段提交和三阶段提交

    千次阅读 2020-03-07 20:30:23
    第一部分阐述两阶段提交的原理和优缺点。 第二部分阐述三阶段提交的原理和优缺点。 第三部分阐述如何解决业务中最终一致性的问题。 一.两阶段提交 两阶段提交方法是用于分布式事务中用来完成事务操作的。 ...
  • 对分布式事务及两阶段提交、三阶段提交的理解 一、分布式数据一致性 在分布式系统中,为了保证数据的高可用,通常会将数据保留多个副本(replica),这些副本会放置在不同的物理的机器上。 1.什么是数据一致性 ...
  • 事务和两阶段提交法1

    2022-08-08 21:12:19
    2 两阶段提交在分布式系统中,事务往往包含有多个参与者的活动,单个参与者上的活动是能够保证原子性的,而多个参与者之间原子性的保证则需要通过两阶段提交来实现,
  • Flink两阶段提交

    万次阅读 多人点赞 2019-05-17 10:22:47
    文章目录两阶段提交 两阶段提交 何为EXACTLY_ONCE? EXACTLY_ONCE简称EOS,每条输入消息只会影响最终结果一次,注意这里是影响一次,而非处理一次,Flink一直宣称自己支持EOS,实际上主要是对于Flink应用内部来说的...
  • 它是一种强一致性设计,引入一个事务协调者的角色来协调管理各参与者的提交和回滚,二阶段分别指的是准备(投票)和提交两阶段。 第一阶段(准备阶段) 为事务协调者的节点会首先向所有的参与者节点发送Prepare...
  • MySQL为什么需要两阶段提交 两阶段提交图解 为什么需要两阶段提交? 保证binlog与redolog的数据一致性。 如果没有两阶段提交: 先写redolog,再写binlog: redolog写完,还没来得及写binlog,MySQL宕机。重启以后...
  • 1.11两阶段提交协议

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

    千次阅读 2019-09-15 20:00:10
    经常在网络上看见有人介绍TCC时,都提一句,”TCC是两阶段提交的一种”。其理由是TCC将业务逻辑分成try、confirm/cancel在个不同的阶段中执行。其实这个说法,是不正确的。可能是因为既不太了解两阶段提交机制、也...
  • 阶段提交协议在协调者和参与者中都引入超时机制,并且把两阶段提交协议的第一个阶段拆分成了步:询问,然后再锁资源,最后真正提交。 (1)三个阶段的执行 1.CanCommit阶段 3PC的CanCommit阶段其实和2PC的准备...
  • Flink整合kafka的两阶段提交结论

    千次阅读 2020-12-05 14:13:54
    提交: 预提交 确认提交 Flink通过checkpoint来保存数据是否处理完成的状态 由JobManager协调各个TaskManager进行checkpoint存储,checkpoint保存在 StateBackend中,默认StateBackend是内存级的,也可以改为文件...
  • PostgreSQL中的两阶段提交

    千次阅读 2018-10-17 18:29:35
    多台数据库之间的原子性,需要通过两阶段提交协议来实现。  两阶段提交协议的步骤: (1)应用程序调用事务协调器中的提交方法。 (2)事务协调器将联络事务中涉及的所有数据库,通知它们准备提交事务(PREPARE ...
  • 为什么需要两阶段提交 所谓的两阶段提交就是指先写入了redo log后变为就绪状态,然后写入bin log后再提交事务变为commit状态。原因是因为如果修改数据id为2的变为3,如果先写入了redo log后此时异常重启,由于crash-...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 312,632
精华内容 125,052
关键字:

两阶段提交