分布式入门之4:二阶段提交

1. 背景:

初时提出,是为解决分布式数据库的事务问题。单机数据库事务可靠日志技术,MVCC技术实现。分布式情况下,就需要额外的手段来保证,这才出现了二阶段提交。

2. 流程:

从角色上,二阶段提交分为两种角色:协调者(coordinate)参与者(participant)。流程思路上很简单:

1. 协调者询问询问所有参与者,能否提交;参与者返回是否能提交的结果;

2. 协调者根据参与者的返回结果决定是否提交事务,并通知参与者执行。

但实际上,二阶段提交需要考虑不少异常场景:

对照上图:

1 宕机类:

协调者宕机:起来后,看本地日志。

如果在begin_commit,则发送prepare。即使参与者已经发送过了响应,也不影响。流程正常。

如果在global_commit或global_abort,则重新发送global-commit或global-abort。(如果参与者已经提交过,怎么办)。

如果协调者起不来,起新的协调者,向参与者取状态。如有commit的,则继续commit,否则abort。

参与者宕机:起来后,看本地日志。

如果在init,则等prepare。如果协调者已经发过,会超时,见下。

如果在ready日志,则按流程发送vote-commit继续往下走。

如果在abort或commit日志处,则什么都不干,等协调者重发。

2 等待响应超时类

大体来说,一阶段超时直接退出流程,二阶段超时持续重试。

协调者超时:

等待参与者对prepare响应超时(已收到全为vote-commit,但仍有未响应的参与者)。这时,直接放弃,发送global_abort。

等待global-commit或global-abort的响应超时。这时,无他法,只有不断重试。这可能会引起参与者重复提交。

参与者超时:

init后,在prepare等待处超时。直接进入abort。后面即使收到prepare,流程仍然正确。

确认可以提交后,在等待协调者二阶段命令时超时。说明已经发过vote_commit,由于不知道流程状态,只能不断重发vote_commit。

二阶段协议应用较少,理论价值大于实践价值。

时间: 2024-10-27 10:47:52

分布式入门之4:二阶段提交的相关文章

分布式基础之二阶段提交

分布式基础之二阶段提交 二阶段提交(Two Phase Commit)在分布式事务处理中非常常见.它主要用来保证分布式事务处理的一致性,决定事务的提交或回滚.目前二阶段提交广泛应用于关系型数据库的分布式事务处理中,它是分布式系统中的一个常见协议. 需求 为什么要二阶段提交?因为在分布式系统中,每个节点只知道自己的事务是否执行成功了,而分布式系统要求一致性,也就是所有的节点的状态都应该一致.如果某一个事务只在部分节点执行成功,那么势必会导致各分布式节点不一致.二阶段提交就是用来保证要么所有的节点都

Mysql事物与二阶段提交

 1.事务的四种特性(ACID) 事务可以是一个非常简单的SQL构成,也可以是一组复杂的SQL语句构成.事务是访问并且更新数据库中数据的一个单元,在事务中的操作,要么都修改,要么都不做修改,这就是事务的目的,也是事务模型区别于其他模型的重要特征之一. 事务的原子性:原子是不可分割的,事务不可分割(没有commit数据不能被读到). 事务的持久性:在commit之后,不能丢数据.(就是在提交后,数据必须落盘redo落盘). 事务的隔离性:在数据库里面,各个事务之间不能互相影响. 事务的一致性:事务

二阶段提交和三阶段提交

一.2PC 2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase).提交阶段(commit phase),2是指两个阶段,P是指准备阶段,C是指提交阶段 整个事务过程由事务管理器和参与者组成,事务管理器负责 决策整个分布式事务的提交和回滚,事务参与者负责自己本地事务的提交和回滚 在计算机中部分关系数据库如Oracle.MySQL支持两阶段提交协议,如下图: 准备阶段(Prepare phase):事务管理器给每个参与者发送Prepare消息,每个数据库参与者

MongoDB官方文档翻译系列之 -- 执行二阶段提交

简介 本篇文档提供了一个使用二阶段提交将数据写入多个文档的方法来处理多文档更新或"多文档事务".在此基础上,你可以扩展实现类似数据回滚的功能. 背景 在MongoDB数据库中,作用于单个document的操作总是原子性的:但是,涉及到多个document的操作,也就是我们常说的"多文档事务",是非原子性的. 由于document可以设计的非常复杂并且能包含多个"内嵌"document,因此单文档原子性对很多实际场景提供了必要的支持.(译者注:比如

二阶段提交应用项目(Two-phase commit protocol )2PC 高并发

整个系统的需求文档为英文描述. A Simple 2-Phase Commit System The company ABC provides its customers wire transfer service. For example, it can withdraw $1000 from John's account in Bank of China and deposit the money to John's another account in China Construction

对分布式事务及两阶段提交、三阶段提交的理解

转载至:http://www.cnblogs.com/binyue/p/3678390.html,最近学习需要,先转载方便用用来强化加深印象 一.分布式数据一致性 在分布式系统中,为了保证数据的高可用,通常会将数据保留多个副本(replica),这些副本会放置在不同的物理的机器上. (1)什么是数据一致性 在数据有多份副本的情况下,如果网络.服务器或者软件出现故障,会导致部分副本写入成功,部分副本写入失败.这就造成各个副本之间的数据不一致,数据内容冲突. 造成事实上的数据不一致. (2)CAP定

<从PAXOS到ZOOKEEPER分布式一致性原理与实践>读书笔记-两阶段提交与三阶段提交

一.背景 本书第一章的分布式架构,写了从单机的acid到分布式的CAP.参见之前的文章.本篇是第二章的一致性协议部分,分两篇整理. 在分布式系统中,为了保证数据的高可用,通常,我们会将数据保留多个副本(replica),这些副本会放置在不同的物理的机器上.为了对用户提供正确的增\删\改\查等语义,我们需要保证这些放置在不同物理机器上的副本是一致的. 为了解决这种分布式一致性问题,有很多经典算法:如二阶段提交.三阶段提交,paxos算法. 二.二阶段提交(2PC) 二阶段提交(Two-phaseC

分布式事务之两阶段提交

一.二阶段提交协议 一般分为协调器C和若干事务执行者Si两种角色:    当执行某一事务T的所有站点Si都通知C事务执行完成,C即启动二阶段提交协议.    (1) 首先C向所有Si发<prepare>消息(C先将<prepare>消息写到本机日志) ,Si收到<prepare>消息后,根据本机T的执行情况,如果成功返回<ready T>,不成功返回<abort T>.(返回前都应把要返回的消息写到日志里)     (2) C收集完所有Si的返回

分布式理论系列(二)2PC 到 3PC 到 Paxos 到 Raft 到 Zab

分布式理论系列(二)2PC 到 3PC 到 Paxos 到 Raft 到 Zab 本文介绍一致性实现的几种方案: 2PC 到 3PC 到 Paxos 到 Raft 到 Zab 两类一致性(操作原子性与副本一致性) 2PC 3PC 协议用于保证属于多个数据分片上的操作的原子性.这些数据分片可能分布在不同的服务器上,2PC 协议保证多台服务器上的操作要么全部成功,要么全部失败. Paxos Raft Zab 协议用于保证同一个数据分片的多个副本之间的数据一致性.当这些副本分布到不同的数据中心时,这个