这篇文章关于两阶段提交和Paxos讲的很好

http://blog.chinaunix.net/uid-16723279-id-3803058.html

两阶段提交协议与paxos投票算法

点评:2PC绝对是CP的死党,是分布式情况下强一致性算法,因此缺点也是很明显的,

单点coordinator是个严重问题:

  1. 没有热备机制,coordinator节点crash了或者连接它的网路坏了会阻塞该事务;
  2. 吞吐量不行,没有充分发动数量更多的participants的力量,一旦某个participant第一阶段投了赞成票就得在他上面加独占锁,其他事务不得介入,直到当前事务提交or回滚

注:3PC能解决coordinator和participants都挂掉的情况。

paxos

Paxos算法是莱斯利·兰伯特(Leslie Lamport,就是 LaTeX 中的"La",此人现在在微软研究院)于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。

算法的核心过程分为两阶段:

  1. prepare阶段:
  • a:proposer 选择一个提案编号 n 并将 prepare 请求发送给 足够多的acceptors
  • b:acceptor 收到 prepare 消息后,如果提案的编号大于它已经回复的所有 prepare 消息,则 acceptor 将自己上次接受的提案[2b]回复给 proposer,并承诺不再回复小于 n 的提案
  1. accept阶段:
  • a:当一个 proposor 收到了 acceptors 对 prepare 的回复后,就进入批准阶段。它要向回复 prepare 请求的 acceptors 发送 accept 请求,包括编号 n 和一个suitable value(下文会讲这个value的来头)
  • b:在不违背自己向其他 proposer 的承诺[1b]的前提下,acceptor 收到 accept 请求后丢弃曾经accept过的value[2b]接着接受这个请求并持久化

本来还有第三阶段:proposer最终提交事务,它跟2PC的第二阶段基本一样:proposer收到过半的accept后向所有acceptor发布最终的决议(有的实现版本是由learner负责统计accept票数并发布决议,这里为了跟2PC作比较不特别区分)

proposer选择一个会自增的编号n,这个编号可以由一个统一的机构颁发,但是一定得保证从这里取得的编号是自增且唯一的(即多个proposer取到的编号存在时序关系);

名词解释

  1. 一个锁:当acceptor收到prepare消息后,当且仅当这是它见过的最大的编号n时,持久化该n,并将最近一次接受提案的value返回给propose,并加锁:在1b阶段只回复大于n的prepare消息,2b阶段不接受小于n的accept请求,对于大于n的的accept请求会被接受并导致该acceptor之前所接受过的value被清空
  2. suitable value:proposer收到足够多的prepare回复后,会决定出一个suitable value作为提案:在1b中如果收集到的每一种回复都不能形成多数派,也就是说acceptor的情况有点类似乌合之众,那么proposer就可以按照它的意愿来进行投票,即可以任意设置suitable value;如果收集到的某种value过半了,则将这个value作为suitable value发起accept请求

总结

paxos虽然也是分布式情况下强一致性算法,但他在2PC上至少有两点改进

  1. 不存在说网路问题导致事务阻塞甚至失败,尤其是连接coordinator的,因为paxos的角色是可以互串的,必要时participant也能充当coordinator
  2. 加在任何一个在1b2b阶段投了赞成票的participant上的锁是可以被砸开的:只要新提案的编号更大,这样就提高吞吐量了,当然频繁的产生新proposer可能会导致活锁:永远无法达成协议,最好设置一个超时机制,过了一定的时间才产生一个proposer
时间: 01-22

这篇文章关于两阶段提交和Paxos讲的很好的相关文章

关于分布式事务、两阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究[转]

1.XA XA是由X/Open组织提出的分布式事务的规范.XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口.XA接口是双向的系统接口,在事务管理器(Transaction Manager)以及一个或多个资源管理器(Resource Manager)之间形成通信桥梁.XA之所以需要引入事务管理器是因为,在分布式系统中,从理论上讲(参考Fischer等的论文),两台机器理论上无法达到一致的状态,需要引入一

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

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

聊一聊 MySQL 中的数据编辑过程中涉及的两阶段提交

MySQL 数据库中的两阶段提交,不知道您知道不?这篇文章就简单的聊一聊 MySQL 数据库中的两阶段提交,两阶段提交发生在数据变更期间(更新.删除.新增等),两阶段提交过程中涉及到了 MySQL 数据库中的两个日志系统:redo 日志和 binlog 文件. redo 日志前面已经介绍过了,就不再介绍了,简单的聊一聊 binlog 文件,binlog 是 MySQL server 层提供的二进制文件,因此所有的存储引擎都可以使用 binlog 功能,binlog 是追加写的逻辑日志,记录了执行

h2database源码浅析:事务、两阶段提交

http://blog.csdn.net/bluejoe2000/article/details/42437633 h2database源码浅析:事务.两阶段提交 2015-01-05 22:54 734人阅读 评论(0) 收藏 举报  分类: 源码故事(18)  版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[+] Transaction Isolation Transaction isolation is provided for all data manipulation

MySQL源码之两阶段提交

在双1的情况下,两阶段提交的过程 环境准备:mysql 5.5.18, innodb 1.1 version配置: sync_binlog=1 innodb_flush_log_at_trx_commit=1 autocommit=0 设置断点: sql_parse.cc::dispatch_command --命令跳转入口 sql_parse.cc::mysql_parse sql_parse.cc::mysql_execute_command sql_parse.cc::trans_comm

MySQL binlog 组提交与 XA(两阶段提交)

1. XA-2PC (two phase commit, 两阶段提交 ) XA是由X/Open组织提出的分布式事务的规范(X代表transaction; A代表accordant?).XA规范主要定义了(全局)事务管理器(TM: Transaction Manager)和(局部)资源管理器(RM: Resource Manager)之间的接口.XA为了实现分布式事务,将事务的提交分成了两个阶段:也就是2PC (tow phase commit),XA协议就是通过将事务的提交分为两个阶段来实现分布

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

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

Atitit ACID解决方案2PC(两阶段提交)  跨越多个数据库实例的ACID保证

Atitit ACID解决方案2PC(两阶段提交)  跨越多个数据库实例的ACID保证 1.1. ACID解决方案1 1.2. 数据库厂商在很久以前就认识到数据库分区的必要性,并引入了一种称为2PC(两阶段提交)的技术来提供跨越多个数据库实例的ACID保证.这个协议分为以下两个阶段:1 1.3. 基本上,数据库实现 ACID 最关键的技术是日志和锁.2 1.4. I- 实现事务隔离的主要手段是锁.另外一个关键技术是  MVCC (Multi-version Concurrency Control

两阶段提交与三阶段提交【分布式数据一致性】

1.任何一个技术,都是为了解决某个问题,有它的使用场景. 2.考虑下面的应用场景:一个指挥官,A,B,C,D四个将军分布在四个方向,指挥官制定明天攻城的计划.如何保证四个将军同时执行攻城的命令? 第一个阶段:指挥官分别发给将军消息,计划明天攻城,四个将军分别回复是否准备好. 第二个阶段: 指挥官确认四个将军是否都准备好,如果都准备好,下发命令,明天攻城.如果存在没有准备好的,下发命令,放弃攻城,四个将军分别再回复一下说,知道了. 这就是两阶段提交,为了解决分布式数据的一致性. 3.考虑下面的情况