六:分布式事务一致性协议paxos的分析

最近研究paxos算法,看了许多相关的文章,概念还是很模糊,觉得还是没有掌握paxos算法的精髓,所以花了3天时间分析了libpaxos3的所有代码,此代码可以从https://bitbucket.org/sciascid/libpaxos 下载。对paxos算法有初步了解之后,再看此文的效果会更好;如果你也想分析libpaxos3的话,此文应该会对你有不小帮助;关于paxos的历史这里不多做介绍,关于描述paxos算法写的最好的一篇文章应该就是维基百科了,地址戳这里:http://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95

在paxos算法中,分为4种角色:

Proposer :提议者

Acceptor:决策者

Client:产生议题者

Learner:最终决策学习者

上面4种角色中,提议者和决策者是很重要的,其他的2个角色在整个算法中应该算做 打酱油的,Proposer就像Client的使者,由Proposer使者拿着Client的议题去向Acceptor提议,让Acceptor来决 策。这里上面出现了个新名词:最终决策。现在来系统的介绍一下paxos算法中所有的行为:

Proposer提出议题
Acceptor初步接受 或者 Acceptor初步不接受
如果上一步Acceptor初步接受则Proposer再次向Acceptor确认是否最终接受
Acceptor 最终接受 或者Acceptor 最终不接受
上面Learner最终学习的目标是Acceptor们最终接受了什么议题?注意,这里是向所有Acceptor学习,如果有多数派个Acceptor最终接受了某提议,那就得到了最终的结果,算法的目的就达到了。画一幅图来更加直观:

为什么需要3个Acceptor?因为Acceptor必须是最少大于等于3个,并且必须是奇数个,因为要形成多数派嘛,如果是偶数个,比如4个,2个接受2个不接受,各执己见,没法搞下去了。

为什么是3个Proposer? 其实无所谓是多少个了,1~n 都可以的;如果是1个proposer,毫无竞争压力,很顺利的完成2阶段提交,Acceptor们最终批准了事。如果是多个proposer就比较复杂了,请继续看。

上面的图中是画了很多节点的,每个节点需要一台机器么?答案是不需要的,上面的图 是逻辑图,物理中,可以将Acceptor和Proposer以及Client放到一台机器上,只是使用了不同的端口号罢了,Acceptor们启动不同 端口的TCP监听,Proposer来主动连接即可;完全可以将Client、Proposer、Acceptor、Learner合并到一个程序里面; 这里举一个例子:比如开发一个JOB程序,JOB程序部署在多台服务器上(数量为奇数),这些JOB有可能同时处理一项任务,现在使用paxos算法让这 些JOB自己来商量由谁(哪台机器)来处理这项任务,这样JOB程序里就需要包含Client、Proposer、Acceptor、Learner这4 大功能,并且需要配置其他JOB服务器的IP地址。

再举一个例子,zookeeper常常用来做分布式事务锁。Zookeeper所 使用的zad协议也是类似paxos协议的。所有分布式自协商一致性算法都是paxos算法的简化或者变种。Client是使用zookeeper服务的 机器,Zookeeper自身包含了Acceptor, Proposer, Learner。Zookeeper领导选举就是paxos过程,还有Client对Zookeeper写Znode时,也是要进行Paxos过程的,因 为不同Client可能连接不同的Zookeeper服务器来写Znode,到底哪个Client才能写成功?需要依靠Zookeeper的paxos保 证一致性,写成功Znode的Client自然就是被最终接受了,Znode包含了写入Client的IP与端口,其他的Client也可以读取到这个 Znode来进行Learner。也就是说在Zookeeper自身包含了Learner(因为Zookeeper为了保证自身的一致性而会进行领导选 举,所以需要有Learner的内部机制,多个Zookeeper服务器之间需要知道现在谁是领导了),Client端也可以 Learner,Learner是广义的。

现在通过一则故事来学习paxos的算法的流程(2阶段提交),有2个Client(老板,老板之间是竞争关系)和3个Acceptor(政府官员):

现在需要对一项议题来进行paxos过程,议题是“A项目我要中标!”,这里的“我”指每个带着他的秘书Proposer的Client老板。
Proposer当然听老板的话了,赶紧带着议题和现金去找Acceptor政府官员。
作为政府官员,当然想谁给的钱多就把项目给谁。
Proposer-1小姐带着现金同时找 到了Acceptor-1~Acceptor-3官员,1与2号官员分别收取了10比特币,找到第3号官员时,没想到遭到了3号官员的鄙视,3号官员告诉 她,Proposer-2给了11比特币。不过没关系,Proposer-1已经得到了1,2两个官员的认可,形成了多数派(如果没有形成多数 派,Proposer-1会去银行提款在来找官员们给每人20比特币,这个过程一直重复每次+10比特币,直到多数派的形成),满意的找老板复命去了,但 是此时Proposer-2保镖找到了1,2号官员,分别给了他们11比特币,1,2号官员的态度立刻转变,都说Proposer-2的老板懂事,这下子 Proposer-2放心了,搞定了3个官员,找老板复命去了,当然这个过程是第一阶段提交,只是官员们初步接受贿赂而已。故事中的比特币是编号,议题是 value。
    这个过程保证了在某一时刻,某一个proposer的议题会形成一个多数派进行初步支持;

===============华丽的,第一阶段结束================

  5. 现在进入第二阶段提交,现在proposer-1小姐使用分身术(多线 程并发)分了3个自己分别去找3位官员,最先找到了1号官员签合同,遭到了1号官员的鄙视,1号官员告诉他proposer-2先生给了他11比特币,因 为上一条规则的性质proposer-1小姐知道proposer-2第一阶段在她之后又形成了多数派(至少有2位官员的赃款被更新了);此时她赶紧去提 款准备重新贿赂这3个官员(重新进入第一阶段),每人20比特币。刚给1号官员20比特币, 1号官员很高兴初步接受了议题,还没来得及见到2,3号官员的时候

这时proposer-2先生也使用分身术分别找3位官员(注意这里是 proposer-2的第二阶段),被第1号官员拒绝了告诉他收到了20比特币,第2,3号官员顺利签了合同,这时2,3号官员记录client-2老板 用了11比特币中标,因为形成了多数派,所以最终接受了Client2老板中标这个议题,对于proposer-2先生已经出色的完成了工作;

这时proposer-1小姐找到了2号官员,官员告诉她合同已经签了,将合同给 她看,proposer-1小姐是一个没有什么职业操守的聪明人,觉得跟Client1老板混没什么前途,所以将自己的议题修改为“Client2老板中 标”,并且给了2号官员20比特币,这样形成了一个多数派。顺利的再次进入第二阶段。由于此时没有人竞争了,顺利的找3位官员签合同,3位官员看到议题与 上次一次的合同是一致的,所以最终接受了,形成了多数派,proposer-1小姐跳槽到Client2老板的公司去了。

===============华丽的,第二阶段结束===============

  Paxos过程结束了,这样,一致性得到了保证,算法运行到最后所有的 proposer都投“client2中标”所有的acceptor都接受这个议题,也就是说在最初的第二阶段,议题是先入为主的,谁先占了先机,后面的 proposer在第一阶段就会学习到这个议题而修改自己本身的议题,因为这样没职业操守,才能让一致性得到保证,这就是paxos算法的一个过程。原来 paxos算法里的角色都是这样的不靠谱,不过没关系,结果靠谱就可以了。该算法就是为了追求结果的一致性。

时间: 2024-12-26 22:35:33

六:分布式事务一致性协议paxos的分析的相关文章

五:分布式事务一致性协议paxos的应用场景

1.应用场景 (1)分布式中的一致性 Paxos算法主要是解决一致性问题,关于“一致性”,在不同的场景有不同的解释: NoSQL领域:一致性更强调“能读到新写入的”,就是读写一致性数据库领域:一致性强调“所有的数据状态一致”,经过一个事务后,如果事务成功,所有的表数据都按照事务中的SQL进行了操作,该修改的修改,该增加的增加,该删除的删除,不能该修改的修改了,该删除的没删掉:如果事务失败,所有的数据还是在初始状态:状态机:在状态机中的一致性更强调在每个初始状态一致的状态机上执行一串命令后状态都必

四,分布式事务一致性协议paxos通俗理解

转载地址:http://www.lxway.com/4618606.htm 维基的简介:Paxos算法是莱斯利·兰伯特(Leslie Lamport,就是 LaTeX 中的"La",此人现在在微软研究院)于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法. Paxos算法目前在Google的Chubby.MegaStore. Spanner等系统中得到了应用,Hadoop中的ZooKeeper也使用了Paxos算法,在上面的各个系统中,使用的算法与Lamport提出的 原

三:分布式事务一致性协议2pc和3pc

一:分布式一致性协议--->对于一个分布式系统进行架构设计的过程中,往往会在系统的可用性和数据一致性之间进行反复的权衡,于是就产生了一系列的一致性协议.--->长期探索涌现出一大批经典的一致性协议和算法.其中最著名的就是二阶段提交协议,三阶段提交协议和paxos算法. 二:2PC与3PC--->在分布式系统中,每一个机器节点虽然都能够明确知道自己在进行事务操作过程中的结果是成功或失败,但却无法直接获取到其他分布式节点的操作结果.因此,当一个事务操作需要跨越多个分布式节点的时候,为了保持事

分布式事务一致性解决方案分析

一.从数据一致性谈起 一致性问题,"万恶之源"是数据冗余和分布并通过网络交互+网络异常是常态. 1.数据一致性的情形 主库.从库和缓存数据一致性,相同数据冗余,关系数据库,为保证关据库的高可用和高性能,一般会采用主从(备)架构并引入缓存.其中数据不一致性存在于数据冗余的时间窗口内.常用的解决方案见数据库之架构. 多副本数据之间的数据一致性,相同数据副本,大数据领域,一份数据会有多个副本并存储到不同的节点上.客户端可以访问任何一个节点进行读写操作.常用的解决方案是基于Paxos.ZAB.

明白了,原来分布式事务一致性可以这样搞

1.分布式事务问题的产生 何为事务? 所谓事务,大多数开发人员对事务并不陌生,它是由中间件提供的一种特有的机制.这种机制可以将一个活动所涉及的全部操作当做一个不可分割的执行单元,只有这个执行单元的所有操作均能正常执行的情况下才提交事物:否则,只要其中任一一个操作执行失败,都将导致整个执行单元回滚.现在的关系型数据库.部分消息中间件都具备这样的事务处理能力. 事务特性有哪些? Atomicity--原子性,是说事务中的所有操作的结果,要么全部成功,要么全部失败,不会存在中间状态.事务在执行过程中如

分布式系统理论(二):一致性协议Paxos

摘要: 分布式系统理论第二章,此系列主要以理论为主. Paxos算法 Paxos算法是莱斯利·兰伯特(Leslie Lamport)于1990年提出的一种基于消息传递的一致性算法. Paxos 算法是一个解决分布式系统中,多个节点之间就某个值(注意是某一个值,不是一系列值)达成一致的通信协议.能够处理在少数派离线的情况下,剩余的多数派节点仍然能够达成一致. Lamport是通过故事的方式提出Paxos 问题:希腊岛屿Paxon 上的执法者在议会大厅中表决通过法律(一次paxos过程),并通过服务

【分布式】一致性协议

一.前言 继续前面的学习,这篇我们来学习在分布式系统中最重要的一块,一致性协议,其中就包括了大名鼎鼎的Paxos算法. 二.2PC与3PC 在分布式系统中,每一个机器节点虽然能够明确知道自己在进行事务操作过程中的结果是成功或是失败,但是却无法直接获取到其他分布式节点的操作结果,因此,当一个事务操作需要跨越多个分布式节点的时候,为了保持事务处理的ACID的特性,需要引入协调者的组件来统一调度所有分布式节点的执行逻辑,而被调度的节点则被称为参与者,协调者负责调度参与者的行为并最终决定这些参与者是否要

分布式事务一致性方案

http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency 在OLTP系统领域,我们在很多业务场景下都会面临事务一致性方面的需求,例如最经典的Bob给Smith转账的案例.传统的企业开发,系统往往是以单体应用形式存在的,也没有横跨多个数据库.我们通常只需借助开发平台中特有数据访问技术和框架(例如Spring.JDBC.ADO.NET),结合关系型数据库自带的事务管理机制来实现事务性

【原】JMS实现分布式事务一致性

前言:关于分布式事务话题一直是颇有争议的话题,在这里通过自己对消息中间件实现分布式事务做一个简单的demo,同时也让自己能在实践中可以获取经验和对分布式事务自己的一些思考. 1.本地事务 传统的ssh,ssm,ssi这些java框架在配置好事务管理之后,我们的应用就能保证事务一致性;例如 在同一个数据库中A给B转账100元并发送100代金券,在这个过程中,不管是服务器挂掉还是转账失败抛出异常,最终都能保证A的钱要么转出去成功B收到100元和代金券,或者A和B都没有发生变化  2.分布式事务 余额