精华内容
下载资源
问答
  • 两阶段封锁协议

    千次阅读 2019-07-23 23:55:02
    段锁协议是指每个事务的执行分为阶段:生长阶段(加锁阶段)和衰退阶段(解锁阶段)。 加锁阶段:在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁,在进行写操作之前要申请并获得X锁。...

    参考 https://segmentfault.com/a/1190000012513286

    定义

    两段锁协议是指每个事务的执行分为两个阶段:生长阶段(加锁阶段)和衰退阶段(解锁阶段)。
    加锁阶段:在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁,在进行写操作之前要申请并获得X锁。加锁不成功,则事务进入等待状态,直到加锁成功才继续执行。
    解锁阶段:当事务释放了一个封锁以后,事务进入解锁阶段,在该阶段只能进行解锁操作不能再进行加锁操作。
    两段封锁法可以这样来实现:事务开始后就处于加锁阶段,一直到执行ROLLBACK和COMMIT之前都是加锁阶段。ROLLBACK和COMMIT使事务进入解锁阶段,即在ROLLBACK和COMMIT模块中DBMS释放所有封锁 。

    简单来说就是解锁之后不能再加锁 。
    在这里插入图片描述
    加锁时机
    当对记录进行更新操作或者select for update(X锁)、lock in share mode(S锁)时,会对记录进行加锁。
    解锁时机
    commit或者rollback时。

    一个例子

    这道题来自牛客网,根据上面的解释,很显然T1是遵守两阶段封锁协议。在这里插入图片描述

    二段锁对性能的影响实例

    下面举个具体的例子,来讲述二段锁对应用性能的影响,我们举个库存扣减的例子:

    方案一:
    start transaction;
    // 锁定用户账户表
    select * from t_accout where acount_id=234 for update
    //生成订单
    insert into t_trans;
    // 减库存
    update t_inventory set num=num-3 where id=${id} and num>=3;
    commit;
    
    方案二:
    start transaction;
    // 减库存
    update t_inventory set num=num-3 where id=${id} and num>=3;
    // 锁定用户账户表
    select * from t_accout where acount_id=234 for update
    //生成订单
    insert into t_trans;
    commit;
    

    我们的应用通过JDBC操作数据库时,底层本质上还是走TCP进行通信,MySQL协议是一种停-等式协议(和http协议类似,每发送完一个分组就停止发送,等待对方的确认,在收到确认后再发送下一个分组),既然通过网络进行通信,就必然会有延迟,两种方案的网络通信时序图如下:

    在这里插入图片描述
    由于商品库存往往是最致命的热点,是整个服务的热点。如果采用第一种方案的话,TPS理论上可以提升3rt/rt=3倍。而这是在一个事务中只有3条SQL的情况,理论上多一条SQL就多一个rt时间。

    另外,当更新操作到达数据库的那个点,才算加锁成功。commit到达数据库的时候才算解锁成功。所以,更新操作的前半个rt和commit操作的后半个rt都不计算在整个锁库存的时间内。

    从上面的例子可以看出,在一个事务操作中,将对最热点记录的操作放到事务的最后面,这样可以显著地提高服务的吞吐量。

    select for update 和 update where的最优选择

    我们可以将一些简单的判断逻辑写到update操作的谓词里面,这样可以减少加锁的时间,如下:

    方案一:
    start transaction
    num = select count from t_inventory where id=234 for update
    if count >= 3:
        update t_inventory set num=num-3 where id=234
        commit 
    else:
        rollback
    
    方案二:
    start transaction:
        int affectedRows = update t_inventory set num=num-3 where id=234 and num>=3
        if affectedRows > 0:
            commit
        else:
            rollback
    

    延时图如下:
    在这里插入图片描述
    从上图可以看出,加了update谓词以后,一个事务少了1rt的锁记录时间(update谓词和select for update对记录加的都是X锁,所以效果是一样的)。

    展开全文
  • 两阶段提交协议

    千次阅读 2015-08-30 18:46:50
    两阶段提交协议是最简单最流行的ACP。在没有故障发生的情况下,它的执行过程如下: 1. 协调者发送一个VOTE-REQ消息给所有的参与者 2.当参与者接收到VOTE-REQ消息后,它会发送一个包含参与者投票结果的消息(YES或NO...

    两阶段提交协议是最简单最流行的ACP。在没有故障发生的情况下,它的执行过程如下:

    1. 协调者发送一个VOTE-REQ消息给所有的参与者

    2.当参与者接收到VOTE-REQ消息后,它会发送一个包含参与者投票结果的消息(YES或NO)给协调者作为响应。如果参与者投的是No,它会决定Abort事务并停止运行

    3.协调者收集来自所有参与者的投票信息。如果所有的消息都是YES,同时协调者投的也是Yes,那么协调者就会决定进行Commit,并向所有参与者发送COMMIT消息。否则协调者就会决定进行Abort,并向所有投Yes的参与者发送ABORT消息(那些投No的参与者已经在第2步中决定Abort了)。之后,对于这两种情况协调者都会停止运行

    4. 每个投Yes的参与者等待来自协调者的COMMIT或ABORT消息。收到消息后执行相应动作然后停止运行。

    2PC的两个阶段是指投票阶段(步骤1和2)和决定阶段(步骤3和4)。参与者的不确定区间始于向协调者发送YES(步骤2),终于接收到COMMIT或ABORT消息(步骤4)。协调者没有不确定区间,因为只要它投了票结果就确定了,当然它投票时需要知道参与者的投票结果(步骤3)。

    很容易可以看出2PC满足条件AC1-AC4。不幸的是,目前为止的描述并不满足AC5。有两个原因,首先在协议的很多点上,进程在继续处理之前必须要等待消息。但是消息可能会由于故障而无法到达。因此,进程可能会无限等待下去。为避免这个问题,需要使用超时机制。当进程的等待因为超时而打断时,进程必须采取特定的动作,称之为超时动作。因此,为满足AC5,必须为协议中进程需要等待消息的地方引入合理的超时动作。

    其次,当进程从故障中恢复时,AC5要求进程能够达成与其他进程可能已经达成的决定相一致的决定(可能还必须要等待某些其他故障修复之后才能达成这样的决定)。因此,进程还必须要将某些信息存入可靠性存储中,比如DTlog中。为满足AC5,我们还必须要说明需要将哪些信息存入DT log以及如何在恢复时使用它们。下面我们分别来考虑这两个问题。

    展开全文
  • 文章目录问题协调者统一调度二阶段提交协议 问题 在分布式系统中,各个节点之间在物理上相互独立,通过网络进行沟通和协调。 在关系型数据库中,由于存在事务机制,可以保证每个独立节点上的数据操作满足 ACID。 ...

    在这里插入图片描述

    问题

    在分布式系统中,各个节点之间在物理上相互独立,通过网络进行沟通和协调。

    在关系型数据库中,由于存在事务机制,可以保证每个独立节点上的数据操作满足 ACID。

    但是,相互独立的节点之间无法准确的知道其他节点中的事务执行情况,所以在分布式的场景下,如果不添加额外的机制,多个节点之间理论上无法达到一致的状态。

    在分布式事务中,两阶段和三阶段提交是经典的一致性算法,那么两阶段和三阶段提交的具体流程是怎样的,三阶段提交又是如何改进的呢?


    协调者统一调度

    在分布式事务中,如果想让分布式部署的多台机器中的数据保持一致性,就要保证在所有节点的数据写操作,要么全部都执行,要么全部都不执行。

    但是,一台机器在执行本地事务的时候无法知道其他机器中本地事务的执行结果,节点并不知道本次事务到底应该 Commit 还是 Rollback。

    上篇介绍的几种一致性算法 ,都是通过一个 Leader 进程进行协调,在 2PC(两阶段)和 3PC(三阶段)中也是一样的解决办法。

    二阶段和三阶段提交协议都是引入了一个协调者的组件来统一调度所有分布式节点的执行,让当前节点知道其他节点的任务执行状态,通过通知和表决的方式,决定执行 Commit 还是 Rollback 操作。


    二阶段提交协议

    假设条件

    二阶段提交算法的成立是基于以下假设的:

    • 在该分布式系统中,存在一个节点作为协调者(Coordinator),其他节点作为参与者(Participants),且节点之间可以进行网络通信;

    • 所有节点都采用预写式日志,日志被写入后被保存在可靠的存储设备上,即使节点损坏也不会导致日志数据的丢失;

    • 所有节点不会永久性损坏,即使损坏后仍然可以恢复。

    流程

    两阶段提交中的两个阶段,指的是 Commit-request 阶段和 Commit 阶段,两阶段提交的流程如下:

    在这里插入图片描述


    Commit-request 阶段

    在提交请求阶段,协调者将通知事务参与者准备提交事务,然后进入表决过程。

    在表决过程中,参与者将告知协调者自己的决策:同意(事务参与者本地事务执行成功)或取消(本地事务执行故障),在第一阶段,参与节点并没有进行Commit操作。


    Commit 阶段

    在提交阶段,协调者将基于第一个阶段的投票结果进行决策:提交或取消这个事务。

    这个结果的处理和前面基于半数以上投票的一致性算法不同,必须当且仅当所有的参与者同意提交,协调者才会通知各个参与者提交事务,否则协调者将通知各个参与者取消事务。

    参与者在接收到协调者发来的消息后将执行对应的操作,也就是本地 Commit 或者 Rollback。


    存在的问题

    在这里插入图片描述
    两阶段提交协议有几个明显的问题:

    • 资源被同步阻塞

    在执行过程中,所有参与节点都是事务独占状态,当参与者占有公共资源时,那么第三方节点访问公共资源会被阻塞。

    • 协调者可能出现单点故障

    一旦协调者发生故障,参与者会一直阻塞下去。

    • 在 Commit 阶段出现数据不一致

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


    三阶段提交协议

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

    三阶段中的 Three Phase 分别为 CanCommit、PreCommit、DoCommit 阶段。

    在这里插入图片描述


    CanCommit 阶段

    3PC 的 CanCommit 阶段和 2PC 的准备阶段很像。协调者向参与者发送 Can-Commit 请求,参与者如果可以提交就返回 Yes 响应,否则返回 No 响应。


    PreCommit 阶段

    协调者根据参与者的反应情况来决定是否可以继续事务的 PreCommit 操作。

    根据响应情况,有以下两种可能。

    Case 1 都是 Yes 响应

    ** 假如协调者从所有的参与者获得的反馈都是 Yes 响应,那么就会进行事务的预执行:**

    1. 发送预提交请求,协调者向参与者发送 PreCommit 请求,并进入 Prepared 阶段;

    2. 事务预提交,参与者接收到 PreCommit 请求后,会执行事务操作;

    3. 响应反馈,如果参与者成功执行了事务操作,则返回 ACK 响应,同时开始等待最终指令。


    Case 2 有一个no响应

    假如有任何一个参与者向协调者发送了 No 响应,或者等待超时之后,协调者都没有接到参与者的响应,那么就中断事务:

    1. 发送中断请求,协调者向所有参与者发送 abort 请求;

    2. 中断事务,参与者收到来自协调者的 abort 请求之后,执行事务的中断。


    DoCommit 阶段

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

    Case 1 执行提交

    • 发送提交请求。协调者接收到参与者发送的 ACK 响应后,那么它将从预提交状态进入到提交状态,并向所有参与者发送 doCommit 请求。

    • 事务提交。参与者接收到 doCommit 请求之后,执行正式的事务提交,并在完成事务提交之后释放所有事务资源。

    • 响应反馈。事务提交完之后,向协调者发送 ACK 响应。

    • 完成事务。协调者接收到所有参与者的 ACK 响应之后,完成事务。


    Case 2 中断事务

    协调者没有接收到参与者发送的 ACK 响应,可能是因为接受者发送的不是 ACK 响应,也有可能响应超时了,那么就会执行中断事务。


    Case 3 超时提交

    参与者如果没有收到协调者的通知,超时之后会执行 Commit 操作

    进入第三阶段时,说明参与者在第二阶段已经收到了PreCommit请求,意味它知道大家其实都同意修改了。当进入第三阶段时,由于网络超时等原因,虽然参与者没有收到commit或者abort响应,但是此时成功提交的几率很大,所以会执行commit。


    存在的问题

    三阶段提交协议同样存在问题,具体表现为,在阶段三中,如果参与者接收到了 PreCommit 消息后,出现了不能与协调者正常通信的问题,在这种情况下,参与者依然会进行事务的提交,这就出现了数据的不一致性。


    三阶段的演进

    引入超时机制

    在 2PC 中,只有协调者拥有超时机制,如果在一定时间内没有收到参与者的消息则默认失败,3PC 同时在协调者和参与者中都引入超时机制。


    添加预提交阶段

    在 2PC 的准备阶段和提交阶段之间,插入一个准备阶段,使 3PC 拥有 CanCommit、PreCommit、DoCommit 三个阶段,PreCommit 是一个缓冲,保证了在最后提交阶段之前各参与节点的状态是一致的。


    应用

    两阶段提交是一种比较精简的一致性算法/协议,很多关系型数据库都是采用两阶段提交协议来完成分布式事务处理的,典型的比如 MySQL 的 XA 规范。

    在事务处理、数据库和计算机网络中,两阶段提交协议提供了分布式设计中的数据一致性的保障,整个事务的参与者要么一致性全部提交成功,要么全部回滚。MySQL Cluster 内部数据的同步就是用的 2PC 协议。


    两阶段的应用 - MySQL 的 XA 规范

    在 MySQL 中,二进制日志是 server 层,主要用来做主从复制和即时点恢复时使用的;而事务日志(Redo Log)是 InnoDB 存储引擎层,用来保证事务安全的。

    在数据库运行中,需要保证 Binlog 和 Redo Log 的一致性,如果顺序不一致, 则意味着 Master-Slave 可能不一致。

    在开启 Binlog 后,如何保证 Binlog 和 InnoDB redo 日志的一致性呢?MySQL 使用的就是二阶段提交,内部会自动将普通事务当做一个 XA 事务(内部分布式事务)来处理:

    • Commit 会被自动的分成 Prepare 和 Commit 两个阶段;

    • Binlog 会被当做事务协调者(Transaction Coordinator),Binlog Event 会被当做协调者日志。


    小结

    XA 规范的具体实现,后面继续聊

    不说了 ,累了

    在这里插入图片描述

    展开全文
  • MySql-两阶段加锁协议

    千次阅读 2017-08-07 18:13:05
    此篇博客主要是讲述MySql(仅限innodb)的两阶段加锁(2PL)协议,而非两阶段提交(2PC)协议,区别如下: 2PL,两阶段加锁协议:主要用于单机事务中的一致性与隔离性。 2PC,两阶段提交协议:主要用于分布式事务。 MySql...

    此篇博客主要是讲述MySql(仅限innodb)的两阶段加锁(2PL)协议,而非两阶段提交(2PC)协议,区别如下:

    2PL,两阶段加锁协议:主要用于单机事务中的一致性与隔离性。
    
    2PC,两阶段提交协议:主要用于分布式事务。
    

    MySql本身针对性能,还有一个MVCC(多版本控制)控制,本文不考虑此种技术,仅仅考虑MySql本身的加锁协议。

    什么时候会加锁

    在对记录更新操作或者(select for update、lock in share model)时,会对记录加锁(有共享锁、排它锁、意向锁、gap锁、nextkey锁等等),本文为了简单考虑,不考虑锁的种类。

    什么是两阶段加锁

    在一个事务里面,分为加锁(lock)阶段和解锁(unlock)阶段,也即所有的lock操作都在unlock操作之前,如下图所示:
    输入图片说明

    为什么需要两阶段加锁

    引入2PL是为了保证事务的隔离性,即多个事务在并发的情况下等同于串行的执行。 在数学上证明了如下的封锁定理:

    如果事务是良构的且是两阶段的,那么任何一个合法的调度都是隔离的。
    

    具体的数学推到过程可以参照<<事务处理:概念与技术>>这本书的7.5.8.2节.
    此书乃是关于数据库事务的圣经,无需解释(中文翻译虽然晦涩,也能坚持读下去,强烈推荐)

    工程实践中的两阶段加锁-S2PL

    在实际情况下,SQL是千变万化、条数不定的,数据库很难在事务中判定什么是加锁阶段,什么是解锁阶段。于是引入了S2PL(Strict-2PL),即:

    在事务中只有提交(commit)或者回滚(rollback)时才是解锁阶段,
    其余时间为加锁阶段。
    

    如下图所示:
    输入图片说明
    这样的话,在实际的数据库中就很容易实现了。

    两阶段加锁对性能的影响

    上面很好的解释了两阶段加锁,现在我们分析下其对性能的影响。考虑下面两种不同的扣减库存的方案:

    方案1:
    begin;
    // 扣减库存
    update t_inventory set count=count-5 where id=${id} and count >= 5;
    // 锁住用户账户表
    select * from t_user_account where user_id=123 for update;
    // 插入订单记录
    insert into t_trans;
    commit;
    
    方案2:
    begin;
    // 锁住用户账户表
    select * from t_user_account where user_id=123 for update;
    // 插入订单记录
    insert into t_trans;
    // 扣减库存
    update t_inventory set count=count-5 where id=${id} and count >= 5;
    commit;
    

    由于在同一个事务之内,这几条对数据库的操作应该是等价的。但在两阶段加锁下的性能确是有比较大的差距。两者方案的时序如下图所示:
    输入图片说明

    由于库存往往是最重要的热点,是整个系统的瓶颈。那么如果采用第二种方案的话,
    tps应该理论上能够提升3rt/rt=3倍。这还仅仅是业务就只有三条SQL的情况下,
    多一条sql就多一次rt,就多一倍的时间。
    

    值得注意的是:

    在更新到数据库的那个时间点才算锁成功
    提交到数据库的时候才算解锁成功
    这两个round_trip的前半段是不会计算在内的
    

    如下图所示:
    输入图片说明
    当前只考虑网络时延,不考虑数据库和应用本身的时间消耗。

    依据S2PL的性能优化

    从上面的例子中,可以看出,需要把最热点的记录,
    放到事务最后,这样可以显著的提高吞吐量。更进一步:
    越热点记录离事务的终点越近(无论是commit还是rollback)
    笔者认为,先后顺序如下图:
    

    输入图片说明

    避免死锁

    这也是任何SQL加锁不可避免的。上文提到了按照记录Key的热度在事务中倒序排列。 那么写代码的时候任何可能并发的SQL都必须按照这种顺序来处理,不然会造成死锁。如下图所示: 输入图片说明

    select for update和update where 谓词计算

    我们可以直接将一些简单的判断逻辑写到update的谓词里面,以减少加锁时间,考虑下面两种方案:
    方案1:

     begin:
     int count = select count from t_inventory for update;
     if count >= 5:
         update t_inventory set count=count-5 where id =123
         commit 
     else
         rollback
    

    方案2:

     begin:
         int rows = update t_inventory set count=count-5 where id =123 and count >=5
        if rows > 0:
            commit;
        ele 
            rollback;
    

    时延如下图所示: 输入图片说明
    可以看到,通过在update中加谓词计算,少了1rt的时间。

    由于update在执行过程中对符合谓词条件的记录加的是和select for update一致的排它锁
    (具体的锁类型较为复杂,不在这里描述),所以两者效果一样。
    

    总结

    MySql采用两阶段加锁协议实现隔离性和一致性,我们只有深入的去理解这种协议,才能更好的对我们的SQL进行优化,增加系统的吞吐量。

    展开全文
  • 分布式系统中的两阶段提交协议

    千次阅读 2020-04-20 22:35:28
    分布式系统中的两阶段提交协议 在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调...
  • 两阶段提交协议与三阶段提交协议

    千次阅读 2016-06-07 10:17:29
    在分布式系统中通常存在着多个机器节点,每个节点只能控制自己事务的成功与失败而无法获知... 在分布式系统中通常存在个问题,可用性、数据一致性,通常我们会在可用性与数据一致性之间做一个衡量,在这需求中就产
  • 两阶段提交协议的异常处理

    千次阅读 2014-07-07 12:54:08
    两阶段提交的协议大家都比较熟悉了,解释一下每个阶段的异常处理。
  • 阶段提交协议在协调者和参与者中都引入超时机制,并且把两阶段提交协议的第一个阶段拆分成了步:询问,然后再锁资源,最后真正提交。 (1)三个阶段的执行 1.CanCommit阶段 3PC的CanCommit阶段其实和2PC的准备...
  • XA两阶段提交协议

    万次阅读 2015-09-29 22:15:28
     XA:XA协议,规定事务管理器和资源管理器接口,采用二阶段提交协议。 一阶段提交协议  一阶段提交协议相对简单,如下图:    当然,前提是开启了事务,然后在应用程序发出提交/回滚请求后,数据库执行操作...
  • 实现分布式事务的关键就是两阶段提交协议。在此协议中,一个或多个资源管理器的活动均由一个称为事务协调器的单独软件组件来控制。此协议中的五个步骤如下: • 应用程序调用事务协调器中的提交方法。 • 事务...
  • 分布式系统理论之两阶段提交协议

    千次阅读 2019-06-20 19:46:32
    一,两阶段提交协议介绍 两阶段提交协议是用来保证分布式系统事务的协议。在分布式系统中,一个事务需要由多台机器协调完成,机器之间通过网络来通信,如何保证一组操作在多台机器上要么都做,要么都不做呢?(事务...
  • 2PC 两阶段提交协议

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

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

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

    千次阅读 2021-06-15 14:46:14
    基于XA协议两阶段提交 XA是由X/Open组织提出的分布式事务的规范 由一个事务管理器(TM)和多个资源管理器(RM)组成 提交分为阶段:prepare和commit 第一阶段 第二阶段 保证数据的强一致性 commit阶段...
  •  因为事务需要实现ACID,即原子性、一致性、隔离性、持久性,所以需要采用一定的机制来... XA:XA协议,规定事务管理器和资源管理器接口,采用二阶段提交协议。 一阶段提交协议  一阶段提交协议相对简单,如
  • 问题3的错则显然正是两阶段提交协议的解决目标,所以也没有问题。有问题的只有协调者出错,参与者也出错的问题1。 这种情况可以被进一步分为参与者有没有收到提交的消息。如果参与者没有收到提交的消息,那么...
  • 详解PPPOE协议阶段:发现阶段会话阶段 http://network.51cto.com 2009-12-29 10:43 佚名 chinaunix 我要评论(0) PPPOE协议提供了在广播式的网络(如以太网)中多台主机连接到远端的访问集中器(我们...
  • 随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何实现网站的高可用、易伸缩、可...本文将简单介绍如何有效的解决分布式的一致性问题,其中包括什么是分布式事务,二阶段提交和三阶段提交。 分布式
  • 分布式系统,这早已不是什么新鲜的东西了,在分布式系统的架构设计过程中,往往会存在分布式一致性的问题,经过前人的辛苦探究,提出了二阶段提交协议,三阶段提交协议,Paxos算法等等,用来解决分布式一致性的问题...
  • 分布式存储的三阶段提交协议

    千次阅读 2020-04-20 22:37:10
    阶段提交是为解决两阶段提交协议的缺点而设计的。与两阶段提交不同的是,三阶段提交是“非阻塞”协议。三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段,使得原先在两阶段提交中,参与者在投票...
  • 两阶段提交协议(two phase commit protocol,2PC) 两阶段提交协议(two phase commit protocol,2PC)可以保证数据的强一致性,许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式...
  • 两阶段提交协议(two phase commit protocol,2PC)可以保证数据的强一致性,许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者,并决定提交或取消(回滚)的分布式算法。...
  • 事务和两阶段提交,三阶段提交协议(有限状态自动机) •1 事务的ACID   事务是保证数据库从一个一致性的状态永久地变成另外一个一致性状态的根本,其中,ACID是事务的基本特性。   A是Atomicity,原子性。一...
  • 阶段提交协议

    千次阅读 2018-05-23 23:15:12
    阶段提交协议是2PC的改进版,将二阶段提交协议阶段一,即“提交事务请求”一分为二,形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议协议说明 阶段一:CanCommit 事务询问 执行...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 271,255
精华内容 108,502
关键字:

两阶段协议