精华内容
下载资源
问答
  • 浅谈二阶段提交

    2021-01-26 22:25:09
    阶段提交在分布式系统中,每个节点都可以知道自己事务的提交是否成功,但是却不知道其他节点的事务情况,于是就有了多种分布式实现方式来解决分布式事务的问题。二阶段提交(Two-phase Commit),可以说是一致性协议...

    二阶段提交

    在分布式系统中,每个节点都可以知道自己事务的提交是否成功,但是却不知道其他节点的事务情况,于是就有了多种分布式实现方式来解决分布式事务的问题。

    二阶段提交(Two-phase Commit),可以说是一致性协议或者原子协议,保证分布式系统数据的一致性。

    主要的角色有协调者和参与者。协调者先通知参与者操作是否成败,得到反馈后,再通知参与者提交或者中止操作。

    二阶段提交顾名思义就是有两个阶段,一个是提交请求阶段,也叫投票阶段,另一个是提交阶段。

    提交请求阶段

    307bc765e7a737a5fcbe25ffa562a3fb.png事务发起方发起请求调用给协调者

    协调者向所有参与者节点发起是否可以执行提交操作请求,然后等到所有节点的响应

    参与者执行所有的事务准备,并将Undo信息和Redo信息写入日志

    如果参与者所有的事务都执行成功,返回同意,否则,返回中止

    简单的说,就是协调者对所有参与者说,你们行不行,参与者检查一下自身条件对协调者回复,行或不行。

    提交阶段

    提交阶段,根据参与者反馈的结果,协调者会有两种处理方式。如果所有参与者都返回同意,则到提交阶段,如果有部分参与者返回中止,或者在超时时间内协调组没收到参与者的反馈,则到中断阶段。

    提交

    d5a4d7a2ea7347729083ab2b2aaae130.png协调者向所有参与者发送提交请求

    参与者提交事务,并释放事务期间占的资源

    参与者向协调者发送ack消息

    协调者收到所有ack消息后,协调者向事务方反馈完成事务信息

    中断

    eaffc9f540d95fbe04676784c7dd0aef.png协调者向所有参与者发送回滚请求

    参与者通过Undo回滚,并释放事务期间占的资源

    参与者向协调者发送ack消息

    协调者向事务方反馈事务失败信息

    缺点阻塞:执行过程中间,节点都处于阻塞状态,等待这其他节点操作成功或失败,数据库资源得不到释放

    单点问题:如果协调者挂掉,那直接影响整个事务的提交。特别是在过程中挂掉,其他参与者就陷入了阻塞

    数据一致性:在第二个阶段中,如果某些参与者因为网络抖动,没收到提交请求,而其他参与者已经提交了事务,则数据会不一致

    mysql对XA的支持# 开启事务

    mysql> XA START 'xatest';

    Query OK, 0 rows affected (0.00 sec)

    mysql> INSERT INTO mytable (i) VALUES(10);

    Query OK, 1 row affected (0.04 sec)

    # 结束事务

    mysql> XA END 'xatest';

    Query OK, 0 rows affected (0.00 sec)

    # 提交请求

    mysql> XA PREPARE 'xatest';

    Query OK, 0 rows affected (0.00 sec)

    # 提交

    mysql> XA COMMIT 'xatest';

    Query OK, 0 rows affected (0.00 sec)

    展开全文
  • 2PC(two phase commit protocol,2PC)即两阶段提交协议,是将整个事务流程分为个阶段,准备阶段(Prepare phase)、提交阶段(Commit phase),2指个阶段,P指准备阶段,C指提交阶段。整个事务过程由事务管理...

    一、概述


    2PC(two phase commit protocol,2PC)即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase)、提交阶段(Commit phase),2指两个阶段,P指准备阶段,C指提交阶段。整个事务过程由事务管理器参与者组成,事务管理器负责决策整个分布式事务的提交和回滚,事务参与者负责自己本地事务的提交和回滚。在计算机中部分关系数据库如 Oracle、MySQL 都支持两阶段提交协议。下面是计算机数据库进行两阶段提交的说明:
    【1】准备阶段(Prepare phase)事务管理器给每个参与者 Prepare 消息,每个数据库参与者在本地执行事务,并写本地的 Undo/Redo 日志,此时事务没有提交。(Undo 日志是记录修改的数据,用于数据回滚,Redo 日志是记录修改后的数据,用于提交事务后写入数据文件)
    【2】提交阶段(Commit phase)
    如果事务管理器收到了参与者的执行失败或者超时消息,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;参与者根据事务管理器的执行提交或者回滚操作,并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放资源

    成功情况
    img
    失败情况
    img

    二、解决方案【XA】


    2PC 的传统方案是在数据库层面实现的,如 Oracle、MySQL都支持 2PC协议,为了统一标准减少行业内不必要的对接成本,需要制定标准化的处理模型及接口标准,国际开放标准组织Open Group 定义了分布式事务处理模型 DTP(Distributed Transaction Processing Reference Model)。
    举个例子】:新用户注册送积分
    img
    执行流程【1】应用程序(AP)持有用户库和积分库两个数据源;
    【2】应用程序(AP)通过事务管理器(TM)通知用户库 RM 新增用户,同时通知积分库 RM 位该用户新增积分,RM此时并未提交事务,此时用户和积分资源锁定;
    【3】TM 收到执行回复,只要有一方失败则分别向其他 RM 发起回滚事务,回滚完毕,资源锁释放;
    【4】TM 收到执行回复,全部成功,此时向所有 RM发起提交事务,提交完毕,资源锁释放;
    DTP 模型定义如下角色【1】AP(Application Program)即应用程序,可以理解为使用 DTP分布式事务的程序;
    【2】RM(Resource Manager)
    资源管理器
    ,可以理解为事务的参与者,一般情况下是指一个数据库实例,通过资源管理器对该数据库进行控制,资源管理器控制着分支事务;
    【3】TM(Transaction Manager):事务管理器,负责协调和管理事务,事务管理器控制着全局事务,管理事务生命周期,并协调各个 RM。全局事务是指分布式事务处理环境中,需要操作多个数据库共同完成一个工作,这个工作既是一个全局事务;
    【4】DTP模型定义 TM和 RM之间通讯的接口规范叫 XA,简单理解为数据库提供的 2PC接口协议,基于数据库的XA协议来实现2PC又称为XA方案;
    以上三个角色之间的交互方式如下
    【1】TM 向 AP 提供应用程序编程接口,AP通过 TM提交及回滚事务;
    【2】TM交易中间键通过 XA 接口来通知 RM数据库事务的开始、结束以及提交、回滚等操作;
    总结:整个 2PC的事务流程涉及到三个角色 AP、RM、TM。AP 指的是使用 2PC分布式事务的应用程序。RM指的是资源管理器,它控制着分支事务。TM 指的是事务管理器,它控制整个事务。
    【1】在准备阶段 RM执行实际业务操作,但不提交事务,资源锁定;
    【2】在提交阶段 TM会接收 RM在准备阶段的执行回复,只要有一个执行失败,TM会通知所有 RM执行回滚操作,否则,TM会通知所有 RM提交事务。提交阶段结束资源锁释放。
    【XA方案的问题】:【1】需要本地数据库支持 XA协议
    【2】资源锁需要等到两个阶段结束才释放,性能较差

    三、解决方案【Seata】


    Seata 是由阿里中间件团队发起的开源项目 Fescar,后更名为 Seata,它是一个是开源的分布式事务框架。传统 2PC的问题在 Seata中得到了解决,它通过对本地关系数据库的分支事务的协调来驱动完成全局事务,无须数据库支持 XA协议,是工作在应用层的中间件。主要优点是性能较好,且不长时间占用连接资源,它以高效并且对业务0侵入的方式解决微服务场景下面临的分布式事务问题,它目前提供 AT模式(即2PC)及 TCC模式的分布式事务解决方案。
    【Seata的设计思想如下】:Seata 的设计目标其一是对业务无侵入,因此从业务无侵入的 2PC方案着手,在传统 2PC的基础上演进,并解决 2PC方案面临的问题。Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致,要么一起成功提交,要么一起失败回滚。此外,通常分支事务本身就是一个关系数据库的本地事务,下图是全局事务与分支事务的关系图:
    img

    Transaction Coordinator (TC): 事务协调器,它是独立的中间件,需要独立部署运行,它维护全局事务的运行状态,接收 TM指令发起全局事务的提交与回滚,负责与RM通信协调各各分支事务的提交或回滚。
    Transaction Manager ™****:事务管理器,TM需要嵌入应用程序中工作,它负责开启一个全局事务,并最终向 TC发起全局提交或全局回滚的指令。
    Resource Manager (RM): 控制分支事务,负责分支注册、状态汇报,并接收事务协调器 TC的指令,驱动分支(本地)事务的提交和回滚。
    新用户注册送积分 Seata的分布式事务过程
    img

    具体的执行流程如下
    【1】用户服务的 TM向 TC申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的XID
    【2】用户服务的 RM 向 TC注册分支事务,该分支事务在用户服务执行新增用户逻辑,并将其纳入 XID对应全局事务的管辖;
    【3】用户服务执行分支事务,向用户表插入一条记录;
    【4】逻辑执行到远程调用积分服务时(XID 在微服务调用链路的上下文中传播)。积分服务的RM 向 TC注册分支事务,该分支事务执行增加积分的逻辑,并将其纳入 XID对应全局事务的管辖;
    【5】积分服务执行分支事务,向积分记录表插入一条记录,执行完毕后,返回用户服务;
    【6】用户服务分支事务执行完毕;
    【7】TM向 TC发起针对 XID的全局提交或回滚决议;
    【8】TC调度 XID下管辖的全部分支事务完成提交或回滚请求;
    Seata 实现 2PC与传统 2PC的差别
    架构层次方面,传统 2PC方案的 RM实际上是在数据库层,RM本质上就是数据库自身,通过 XA协议实现,而 Seata的 RM是以 jar包的形式作为中间件层部署在应用程序这一侧的。两阶段提交方面,传统 2PC无论第二阶段的决议是 commit还是 rollback,事务性资源的锁都要保持到 Phase2完成才释放。而 Seata的做法是在 Phase1 就将本地事务提交,这样就可以省去 Phase2持锁的时间,整体提高效率。

    四、Seata实现2PC事务


    【业务说明】:本示例通过 Seata中间件实现分布式事务,模拟三个账户的转账交易过程。两个账户在三个不同的银行(张三在bank1、李四在bank2),bank1和bank2是两个微服务。交易过程是,张三给李四转账指定金额。
    img
    交互流程如下
    【1】请求 bank1进行转账,传入转账金额;
    【2】bank1减少转账金额,调用bank2,传入转账金额;
    【3】创建数据库;
    正常提交流程如下:
    img
    回滚流程如下回滚流程省略前的RM注册过程
    img
    要点说明
    【1】每个 RM使用 DataSourceProxy连接数据库,其目的是使用ConnectionProxy,使用数据源和数据连接代理的目的就是在第一阶段将 undo_log业务数据放在一个本地事务提交,这样就保证只要有业务操作就一定有 undo_log。
    【2】在第一阶段 undo_log中存放了数据修改前和修改后的值,为事务回滚作好准备,所以第一阶段完成就已经将分支事务提交,也就释放了锁资源
    【3】TM开启全局事务开始,将 XID全局事务id放在事务上下文中,通过 feign调用也将 XID传入下游分支事务,每个分支事务将自己的Branch ID(分支事务ID)与 XID关联。
    【4】第二阶段全局事务提交,TC会通知各分支参与者提交分支事务,在第一阶段就已经提交了分支事务,这里各参与者只需要删除undo_log即可,并且可以异步执行,第二阶段很快可以完成。
    【5】第二阶段全局事务回滚,TC会通知各分支参与者回滚分支事务,通过 XID和 Branch ID找到相应的回滚日志,通过回滚日志生成反向的 SQL并执行,以完成分支事务回滚到之前的状态,如果回滚失败则会重试回滚操作。

    开发环境:【数据库】**:MySQL-5.7.25 包括 bank1和 bank2两个数据库;
    JDK
    64位 jdk1.8.0_201;
    微服务框架
    spring-boot-2.1.3、spring-cloud-Greenwich.RELEASE;
    Seata客户端(RM、TM)
    spring-cloud-alibaba-seata-2.1.0.RELEASE;
    Seata服务端(TC)
    :**seata-server-0.7.1;
    微服务及数据库的关系】 **:【1】dtx/dtx-seata-demo/seata-demo-bank1 银行1,操作张三账户, 连接数据库bank1;
    2】dtx/dtx-seata-demo/seata-demo-bank2 银行2,操作李四账户,连接数据库bank2;
    服务注册中心
    dtx/discover-server;
    核心代码粘贴
    :【1】**张三的服务,开启全局事务 @GlobalTransaction和本地事务 @Transactional,并远程调用李四服务。GlobalTransactionalInterceptor 会拦截 @GlobalTransactional注解的方法,生成全局事务ID(XID),XID会在整个分布式事务中传递。 在远程调用时,spring-cloud-alibaba-seata会拦截 Feign调用将 XID传递到下游服务。

     1 import io.seata.core.context.RootContext;
     2 import io.seata.spring.annotation.GlobalTransactional;
     3 import org.springframework.transaction.annotation.Transactional;
     4 
     5 /**
     6  * @desc  张三的服务
     7  * @author zzx
     8  * @version 1.0
     9  **/
    10 @Service
    11 @Slf4j
    12 public class AccountInfoServiceImpl implements AccountInfoService {
    13 
    14     @Autowired
    15     AccountInfoDao accountInfoDao;
    16     
    17     //远程李四的服务接口
    18     @Autowired
    19     Bank2Client bank2Client;
    20 
    21     @Transactional
    22     @GlobalTransactional//开启全局事务(重点) 使用 seata 的全局事务
    23     @Override
    24     public void updateAccountBalance(String accountNo, Double amount) {
    25         log.info("bank1 service begin,XID:{}", RootContext.getXID());
    26         //扣减张三的金额
    27         accountInfoDao.updateAccountBalance(accountNo,amount *-1);
    28         //调用李四微服务,转账
    29         String transfer = bank2Client.transfer(amount);
    30         if("fallback".equals(transfer)){
    31             //调用李四微服务异常
    32             throw new RuntimeException("调用李四微服务异常");
    33         }
    34     }
    35 }
    

    【2】李四服务核心代码,只需要开启本地服务即可。

     1 import io.seata.core.context.RootContext;
     2 import org.springframework.transaction.annotation.Transactional;
     3 
     4 /**
     5  * @desc 李四的服务
     6  * @author Administrator
     7  * @version 1.0
     8  **/
     9 @Service
    10 @Slf4j
    11 public class AccountInfoServiceImpl implements AccountInfoService {
    12 
    13     @Autowired
    14     AccountInfoDao accountInfoDao;
    15 
    16 
    17     @Transactional
    18     @Override
    19     public void updateAccountBalance(String accountNo, Double amount) {
    20         log.info("bank2 service begin,XID:{}",RootContext.getXID());
    21         //李四增加金额
    22         accountInfoDao.updateAccountBalance(accountNo,amount);
    23         if(amount==3){
    24             //人为制造异常
    25             throw new RuntimeException("bank2 make exception..");
    26         }
    27     }
    28 }
    

    五、怎么使用Seata框架,来保证事务的隔离性?

    因 seata一阶段本地事务已提交,为防止其他事务脏读脏写需要加强隔离。
    【1】脏读 select语句加 for update(会去申请全局锁),代理方法增加 @GlobalLock@GlobalTransaction
    【2】脏写 必须使用 @GlobalTransaction
    【3】注:如果你查询的业务的接口没有 GlobalTransactional 包裹,也就是这个方法上压根没有分布式事务的需求,这时你可以在方法上标注 @GlobalLock注解,并且在查询语句上加 for update。 如果你查询的接口在事务链路上外层有GlobalTransactional注解,那么你查询的语句只要加for update就行。设计这个注解的原因是在没有这个注解之前,需要查询分布式事务读已提交的数据,但业务本身不需要分布式事务。 若使用 GlobalTransactional注解就会增加一些没用的额外的 rpc开销比如 begin 返回xid,提交事务等。GlobalLock简化了 rpc过程,使其做到更高的性能。

    总结

    传统2PC(基于数据库 XA协议)和Seata实现 2PC的两种 2PC方案,由于Seata的0侵入性并且解决了传统 2PC长期锁资源的问题,所以推荐采用 Seata实现2PC。 Seata实现2PC要点:
    【1】全局事务开始使用 @GlobalTransactional标识
    【2】每个本地事务方案仍然使用**@Transactional**标识;
    【3】每个数据都需要创建 undo_log表,此表是 seata保证本地事务一致性的关键;

    性并且解决了传统 2PC长期锁资源的问题,所以推荐采用 Seata实现2PC。 Seata实现2PC要点:
    【1】全局事务开始使用 @GlobalTransactional标识
    【2】每个本地事务方案仍然使用**@Transactional**标识;
    【3】每个数据都需要创建 undo_log表,此表是 seata保证本地事务一致性的关键;

    seata 是可以对多个数据源进行事务控制的,前提是一个分支事务操作一个数据源;

    展开全文
  • flink 两阶段提交

    2021-01-27 11:22:37
    flink exactly-once系列目录:一、两阶段提交概述二、TwoPhaseCommitSinkFunction与FlinkKafkaProducer源码分析三、StreamingFileSink源码分析四、事务性输出实现五、最终一致性实现一、flink Exactly-Once与At-...

    flink exactly-once系列目录:

    一、两阶段提交概述

    二、TwoPhaseCommitSinkFunction与FlinkKafkaProducer源码分析

    三、StreamingFileSink源码分析

    四、事务性输出实现

    五、最终一致性实现

    一、flink Exactly-Once与At-Least-Once

    关于消息的消费、处理语义可以分为三类:

    1. at most once : 至多一次,表示一条消息不管后续处理成功与否只会被消费处理一次,那么就存在数据丢失可能

    2\. exactly once : 精确一次,表示一条消息从其消费到后续的处理成功,只会发生一次

    3\. at least once :至少一次,表示一条消息从消费到后续的处理成功,可能会发生多次

    在我们程序处理中通常要求能够满足exectly once语义,保证数据的准确性,flink 通过checkpoint机制提供了Exactly-Once与At-Least-Once 两种不同的消费语义实现, 可以将程序处理的所有数据都保存在状态内部,当程序发生异常失败重启可以从最近一次成功checkpoint中恢复状态数据,通过checkpoint中barrier对齐机制来实现这两不同的语义,barrier对齐发生在一

    58dd5dd8ead69a11f1e4b70aa1741e5c.png

    image

    个处理节点需要接收上游不同处理节点的数据,由于不同的上游节点数据处理速度不一致,那么就会导致下游节点接收到 barrier的时间点也会不一致,这时候就需要使用barrier对齐机制:在同一checkpoint中,先到达的barrier是否需要等待其他处理节点barrier达到后在发送后续数据,barrier将数据流分为前后两个checkpoint(chk n,chk n+1)的概念,如果不等待那么就会导致chk n的阶段处理了chk n+1阶段的数据,但是在source端所记录的消费偏移量又一致,如果chk n成功之后,后续的任务处理失败,任务重启会消费chk n+1阶段数据,就会到致数据重复消息,如果barrier等待就不会出现这样情况,因此barrier需要对齐那么就是实现exectly once语义,否则实现的是at least once语义。由于状态是属于flink内部存储,所以flink 仅仅满足内部exectly once语义。

    二、两阶段提交2PC

    在分布式系统中,可以使用两阶段提交来实现事务性从而保证数据的一致性,两阶段提交分为:预提交阶段与提交阶段,通常包含两个角色:协调者与执行者,协调者用于用于管理所有执行者的操作,执行者用于执行具体的提交操作,具体的操作流程:

    1. 首先协调者会送预提交(pre-commit)命令有的执行者

    2. 执行者执行预提交操作然后发送一条反馈(ack)消息给协调者

    3. 待协调者收到所有执行者的成功反馈,则发送一条提交信息(commit)给执行者

    4. 执行者执行提交操作

    83a9a53f46903c2ed5077682adc37189.png

    image

    如果在流程2中部分预提交失败,那么协调者就会收到一条失败的反馈,则会发送一条rollback消息给所有执行者,执行回滚操作,保证数据一致性;但是如果在流程4中,出现部分提交成功部分提交失败,那么就会造成数据的不一致,因此后面也提出了3PC或者通过其他补偿机制来保证数据最终一致性,接下看看flink 是如何做到2PC,保证数据的一致性。

    三、flink中两阶段提交

    flink中两阶段提交是为了保证端到端的Exactly Once,主要依托checkpoint机制来实现,先看一下checkpoint的整体流程,

    8f9122ba8db6f28f729c34710612b61f.png

    image

    1\. jobMaster 会周期性的发送执行checkpoint命令(start checkpoint);

    2.当source端收到执行指令后会产生一条barrier消息插入到input消息队列中,当处理到barrier时会执行本地checkpoint, 并且会将barrier发送到下一个节点,当checkpoint完成之后会发送一条ack信息给jobMaster ;

    3\. 当DAG图中所有节点都完成checkpoint之后,jobMaster会收到来自所有节点的ack信息,那么就表示一次完整的checkpoint的完成;

    4. JobMaster会给所有节点发送一条callback信息,表示通知checkpoint完成消息,这个过程是异步的,并非必须的,方便做一些其他的事情,例如kafka offset提交到kafka。

    对比flink 整个checkpoint机制调用流程可以发现与2PC非常相似,JobMaster相当于协调者,所有的处理节点相当于执行者,start-checkpoint消息相当于pre-commit消息,每个处理节点的checkpoint相当于pre-commit过程,checkpoint ack消息相当于执行者反馈信息,最后callback消息相当于commit消息,完成具体的提交动作。那么我们应该怎么去使用这种机制来实现2PC呢?

    flink 提供了CheckpointedFunction与CheckpointListener这样两个接口,CheckpointedFunction中有snapshotState方法,每次checkpoint触发执行方法,通常会将缓存数据放入状态中,可以理解为是一个hook,这个方法里面可以实现预提交,CheckpointListener中有notifyCheckpointComplete方法,checkpoint完成之后的通知方法,这里可以做一些额外的操作,例如FlinkKafakConsumerBase 使用这个来完成kafka offset的提交,在这个方法里面可以实现提交操作。

    在2PC中提到如果对应流程2预提交失败,那么本次checkpoint就被取消不会执行,不会影响数据一致性,那么如果流程4提交失败了,在flink中可以怎么处理的呢? 我们可以在预提交阶段(snapshotState)将事务的信息保存在state状态中,如果流程4失败,那么就可以从状态中恢复事务信息,并且在CheckpointedFunction的initializeState方法中完成事务的提交,该方法是初始化方法只会执行一次,从而保证数据一致性。

    展开全文
  • 两阶段提交协议 两阶段提交协议把分布式事务分为个阶段,一个是准备阶段,另一个是提交阶段; 准备阶段和提交阶段都是由事务管理器发起的; 我们可以将事务管理器称为协调者,将资源管理器称为参与者。 流程 ...

    两阶段提交协议

    • 两阶段提交协议把分布式事务分为两个阶段,一个是准备阶段,另一个是提交阶段;
    • 准备阶段和提交阶段都是由事务管理器发起的;
    • 我们可以将事务管理器称为协调者,将资源管理器称为参与者。

    流程

    准备阶段:

    协调者向参与者发起指令,参与者评估自己的状态,如果参与者评估指令可以完成,则会写redo或者undo日志(Write-Ahead Log的一种),然后锁定资源,执行操作,但是并不提交。
    在这里插入图片描述

    提交阶段:

    • 如果每个参与者明确返回准备成功,也就是预留资源和执行操作成功,则协调者向参与者发起提交指令,参与者提交资源变更的事务,释放锁定的资源;
    • 如果任何一个参与者明确返回准备失败,也就是预留资源或者执行操作失败,则协调者向参与者发起中止指令,参与者取消已经变更的事务,执行undo日志,释放锁定的资源。在这里插入图片描述

    存在问题

    两阶段提交协议在准备阶段锁定资源,这是一个非常损耗资源的操作,能保证强一致性,但是实现起来复杂、成本较高、不够灵活,更重要的是它有一些致命的问题

    阻塞:

    从上面的描述来看,对于任何一次指令都必须收到明确的响应,才会继续进行下一步,否则处于阻塞状态,占用的资源被一直锁定,不会被释放。

    单点故障:

    如果协调者宕机,参与者没有协调者指挥,则会一直阻塞,尽管可以通过选举新的协调者替代原有协调者,但是如果协调者在发送一个提交指令后宕机,而提交指令仅仅被一个参与者接收,并且参与者接收后也宕机,则新上任的协调者无法处理这种情况。

    脑裂:

    协调者发送提交指令,有的参与者接收到并执行了事务,有的参与者没有接收到事务就没有执行事务,多个参与者之间是不一致的。

    数据状态不确定

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

    小结

    上面的问题发生的概论比较小,但都需要人工干预处理,没有自动化的解决方案,因此两阶段提交协议在正常情况下能保证系统的强一致性,但是在出现异常的情况下,当前处理的操作处于错误状态,需要人工干预解决,因此可用性不够好。

    展开全文
  • 顾名思义,2PC将分布式事务分成了阶段阶段分别为提交请求(投票)和提交(执行)。协调者根据参与者的响应来决定是否需要真正地执行事务,具体流程如下。 提交请求(投票)阶段 协调者向所有参与者发送...
  • Mysql两阶段提交

    千次阅读 2021-01-17 16:04:43
    在看Mysql相关内容的时候经常听到两阶段提交,那以前都是云里雾里的,通过学习丁奇老师的这篇文章彻底明白了其流程和含义。提到两阶段提交,必须先说一下个日志:redo log和binlog重要的日志模块:redo log数据在...
  • 在分布式系统中,为了保证数据的高可用,通常会将数据保留多个副本...本文介绍分布式事务处理方案之一的两阶段提交协议。分布式事务分布式事务是指发生在多个数据节点之间的事务,分布式事务比单机事务要复杂的多...
  • 【MySQL】【笔记】MySQL的阶段1.事务的两阶段提交​ MySQL为了兼容其他非事务引擎的复制,在server...​ MySQL通过两阶段提交解决了服务层binlog与引擎层Innodb的redo log的一致性与协同问题。第一阶段:In...
  • 文章目录 两阶段提交协议 1. 两阶段提交的前提条件 2. 两阶段提交的基本算法 a. 第一阶段(提交请求阶段) b. 第二阶段(提交执行阶段) 3. 两阶段提交的缺点 Flink-两阶段提交协议 1. Flink-Kafka构建端到端Exactly...
  • 事务和两阶段提交

    2021-02-26 10:14:53
    2 两阶段提交 在分布式系统中,事务往往包含有多个参与者的活动,单个参与者上的活动是能够保证原子性的,而多个参与者之间原子性的保证则需要通过两阶段提交来实现,两阶段提交是分布式事务实现的关键。...
  • 3.在Flink KafkaProducer中继承了TwoPhaseCommitSinkFunction来实现两阶段提交的功能(要弄清楚阶段分别干了什么事) 该类下 有四个子类 protected abstract TXN beginTransaction() throws Exceptio...
  • 在分布式系统中,为了让每个节点都能够感知到其他节点的事务...顾名思义,2PC将分布式事务分成了阶段阶段分别为提交请求(投票)和提交(执行)。协调者根据参与者的响应来决定是否需要真正地执行事务,具体...
  • 两阶段提交(2PC)

    2021-01-27 19:32:17
    2PC两阶段提交协议:P-准备阶段(prepare)C-提交阶段(commit)概念在计算机部分关系数据库,如oracle和mysql中支持两阶段提交协议:准备阶段(prepare phase):事务管理器给每个参与者发送prepare消息,每个数据库参与...
  • mysql的两阶段提交原理(1) perpare阶段 写入redo日志1、设置undo state=TRX_UNDO_PREPARED;2、刷事务更新产生的redo日志;(2) commit阶段 写入binlog日志1、将事务产生的binlog写入文件,刷入磁盘;2、设置undo页的...
  • 两阶段提交及JTA

    2021-03-09 20:18:28
    分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)。分布式事务实现机制如同作者在《SQL优化(六) MVCC...
  • 3PC的优点和缺点: 优点: 1.相比2PC,最大的优点就是降低了第一阶段的阻塞范围(第一阶段是不阻塞的...2.能够在单点故障后继续达成一致(2PC在提交阶段会出现此问题),而3PC会根据协调者的状态进行回滚或者提交 ...
  • 在双1的情况下,两阶段提交的过程环境准备:mysql 5.5.18, innodb 1.1version配置:sync_binlog=1innodb_flush_log_at_trx_commit=1autocommit=0设置断点:sql_parse.cc::dispatch_command--命令跳转入口sql_parse.cc:...
  • 这篇文章就简单的聊一聊 MySQL 数据库中的两阶段提交两阶段提交发生在数据变更期间(更新、删除、新增等),两阶段提交过程中涉及到了 MySQL 数据库中的个日志系统:redo 日志和 binlog 文件。redo 日志前面已经...
  • 一、2PC2PC即两阶段提交协议,是将整个事务流程分为个阶段,准备阶段(Prepare phase)、提交阶段(commit phase),2是指个阶段,P是指准备阶段,C是指提交阶段整个事务过程由事务管理器和参与者组成,事务管理器...
  • MySQL事务提交的时候,需要同时完成redo log和binlog的提交,为了保证个日志的一致性,需要用到两阶段提交 数据库两阶段提交的流程 假设执行一条SQL语句: update T set c=c+1 where ID=2; 流程如下图所示...
  • 文章目录问题协调者统一调度二阶段提交协议 ...在分布式事务中,阶段和三阶段提交是经典的一致性算法,那么阶段和三阶段提交的具体流程是怎样的,三阶段提交又是如何改进的呢? 协调者统一调度 在分布式事务
  • MySQL的崩溃恢复crash_...那为啥redo日志是两阶段提交呢? 这是需要和它处在的环境条件有关系的。那首先先看下read log是如何进行数据修改操作的。当MySQL更新数据的时候,其内部流程是怎么实现的呢?假设我要执行...
  • 目录 一、2PC 1.1、提交事务请求(投票阶段) 1.2、执行事务提交 ...1.1、提交事务请求(投票阶段) ...事务询问:由协调者向所有参与者发送事务内容,询问是否可以执行事务提交操作 ...该阶段拥有种操作:.
  • flink exactly-once系列目录:一、[两阶段提交概述](http://mp.weixin.qq.com/s?__biz=MzU5MTc1NDUyOA==&mid=2247483818&idx=1&sn=8c7bf4d00e81d7635bfa26b78a78ebba&chksm=fe2b65e5c95cecf349d9819...
  • 两阶段提交(2PC) 目录两阶段提交(2PC)@[TOC](目录)一,两阶段提交(2PC)第一个阶段分为三步:第二阶段(正常情况)第二阶段(异常情况)二,2PC的缺点三,总结 分布式事务的基本理论:基本遵循CPA理论,采用柔性事务...
  • 分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)。分布式事务实现机制如同作者在《SQL优化(六) MVCC...
  • 分布式事务两阶段提交在分布式事务中,需要协调所有分布式原子事务参与者,并决定提交或回滚分布式事务,因此采用两阶段提交协议:第一阶段为请求阶段或表决阶段,事务协调者通知事务参与者准备提交或取消事务,然后...
  • redo log两阶段提交 的图都是流程图,不是交互图,太难记忆了,所以决定自己画一张 以一条更新语句的执行流程来学习下redo log两阶段提交。 update student set age=age+1 whre id=2; 1.执行器:调用引擎接囗取id=2...
  • MySQL事务提交的时候,需要同时完成redo log和binlog的提交,为了保证个日志的一致性,需要用到两阶段提交(与分布式的两阶段提交不同,这里的两阶段提交是发生在数据库内部)数据库两阶段提交的流程假设执行一条SQL...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 274,803
精华内容 109,921
关键字:

两阶段提交问题