- 浏览: 213234 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
strong8808:
activemq5.8.0 客户端,服务端启动序列图 -
xurichusheng:
第一题,如果使用 not exists 的话,可以改成:SEL ...
SQL笔试题 -
dingjun1:
cuisuqiang 写道如何解决呢?我的是对了也照样缓存增加 ...
事务未正确关闭引起的HIBERNATE SESSION不能正确关闭 -
dingjun1:
aijezdm915 写道lz ,我也是在写项目描述是犯愁,能 ...
如果在简历中描述项目 -
aijezdm915:
lz ,我也是在写项目描述是犯愁,能否给个你的简历demo,我 ...
如果在简历中描述项目
转载:
http://blog.sina.com.cn/s/blog_5d97745a0101ei6f.html
在分布式系统设计领域,Paxos可谓是最重要一致性的算法。Google的大牛们称
All working protocols for asynchronous consensus we have so far encountered have Paxos at their core.
可见此算法的地位。网络上讨论此算法的文章多如牛毛,但大多数让人看了之后仍然是一头雾水,就连维基百科中,对此算法的描述亦有含糊和错误之处。但实际上,此算法的核心思想还是比较简单的,只是大多数文章的分析脱离了实际应用,或是陷入大量实现细节以致掩盖了算法的核心。本文将先给出Paxos算法的设计目的,和算法流程,再反过来分析算法的原理。
Paxos算法实现的是分布式系统多个结点之上数据的一致性,这个算法有如下特性
1.基于消息传递,允许消息传输的丢失,重复,乱序,但是不允许消息被攥改
2.在结点数少于半数失效的情况下仍然能正常的工作,结点失效可以在任何时候发生而不影响算法正常执行。
下面是Basic Paxos算法,注意,这个算法只具有在多个冲突请求中选出一个的功能,并不具备序列化多个请求依次执行的功能。
Paxos算法包含三个角色Proposor,Acceptor,Learner。
实现的时候采用一组固定数目Server,每个Server同时担任上述三个角色,多个Client将自己的请求值Value_i随机发给一个Server处理,然后这一组Server经过协商后得出统一的一个值Chosen_Value,这个值必须被每个Server学习到,同时回复给所有发起请求的Client。
具体算法流程如下,为避免歧义,关键字眼Propose,Proposal,Accept,Value,Choose等保留英文原文
每个Proposor 拿到某个Client的请求Value_i后,在此阶段还不能发起Proposal,只能发送一个Proposal序号N,将序号发送给所有 Acceptor(即所有Server包括自己),整个系统中所有Proposal的序号不能重复而且每个Proposor自己用到的序号必须是递增的,通常的做法是,假设K台Server协同运行Paxos算法,那么Server_i(i=0...K-1)用的Proposal序号初始值为i,以后每次要产生新序号时递增K,这样保证了所有Server的Proposal序号不重复。
阶段1b---Respond with Promise
每个Acceptor收到Proposal序号后,先检查之前是否Repond序号更高的Proposal,若没有,那么就给出Response,这个 Response带有自己已经Accept的序号最高的Proposal(若还没Accept任何Proposal,回复null),同时,Promise自己不再Accept低于接收序号的Proposal。否则,拒绝Respond。
阶段2a---发起Proposal,请求Accept
Proposal 如果得到了来自超过半数的Acceptor的Response,那么就有资格向Acceptor发起Proposal<N,value>。其中,N是阶段1a中发送的序号,value是收到的Response中序号最大的Proposal的Value,若收到的Response全部是 null,那么Value自定义,可直接选一个Client请求的Value_i
阶段2b--Accept Proposal
检查收到的Proposal的序号是否违反阶段1b的Promise,若不违反,则Accept收到的Proposal。
所有Acceptor Accept的Proposal要不断通知所有Learner,或者Learner主动去查询,一旦Learner确认Proposal已经被超过半数的Acceptor Accept,那么表示这个Proposal 的Value 被 Chosen,Learner就可以学习这个Proposal的Value,同时在自己Server上就可以不再受理Proposor的请求。
这个算法能达到什么效果呢,只要保证超过半数的Server维持正常工作,同时连接工作Server的网络正常(网络允许消息丢失,重复,乱序),就一定能保证,
P2a: 在将来某一时刻,自从某个Proposal被多数派Acceptor Accept后,之后Accept的Proposal Value一定和这个Proposal Value相同。
这就是整个算法的关键,保证了这一点,剩下的Learn Value过程就简单了,无需再为消息丢失,Server宕机而担心,例如,假设5台Server编号0~4,Server0,Server1,Server2已经Accept Proposal 100,然后Server0,Server1学习到Proposal 100,刚学习完成Server0,Server1就都宕机了,但这时候,Server2 Server3和Server4由于没有学习到Chosen value,因此还要继续提出Proposal,然后呢,根据这个神奇的算法,最后能使得Server3 Server4将来Accept的值一定是之前选出来过的Proposal 100的Value。
看到这里,大家应该能够隐隐猜到,在这个过程中,Server2之前Accept Proposal 100的Value起了关键作用,下面,我们就来严格证明上述红色字体表示的算法关键点:
1.发起Proposal前要先获得多数派Acceptor中Accept过的序号最大的Proposal Value。若Value为null才能采用自己的Value。
2.阶段1b Promise自己不再Accept低于接收序号的Proposal。
3.Propsal被超半数的Acceptor Accept才能被认定为Chosen Value从而被Learner学习。
这几个约束条件共同作用,达到了上述P2a要求的效果,Paxos算法提出者Leslie Lamport是怎么构造出来的呢,事实上很简单:
首先,把P2a加强为如下条件:
P2b:自从某个Proposal被多数派Acceptor Accept后,之后Proposor提出的Proposal Value一定和这个Proposal Value相同。
显而易见,由P2b可以推出P2a,那么怎么满足P2b呢,实际上,只要满足如下条件:
P2c:发起的Proposal的Value为任意一个多数派Acceptor集合中Accept过的序号最大的Proposal Value。若这个Acceptor集合中没有Accept过Proposal才能采用自己的Value。
如何从P2c推出P2b呢,利用数学归纳法可以轻易做出证明:假设在某一时刻一个超半数Acceptor集合C共同Accept了某个Proposal K,由于集合C和任意一个多数派Acceptor集合S必有一个共同成员,那么,在这个时刻之后,任意一个多数派Acceptor集合S 中Accept过的最大序号的Proposal只可能是Proposal K或序号比Proposal K更大的Proposal,假设为Proposal K2。同理,Proposal K2的Value等于Proposal K或Proposal K3的Value,而K<K3<K2,递推下去,最终推出根据P2c定出的Value必然是Proposal K的Value。
我们可以看到,P2c条件基本就是上述两阶段协议的关键点1,但是还有一个问题,这个P2c条件要求找出这个“最大序号Value”和提出Proposal必须是一个原子操作,这实际上是难以实现的,所以,上述两阶段协议用了一个巧妙的方法避开了这个问题,这就是上述关键点2 Promise所起的作用了。在Acceptor respond“最大序号Value”的时候,Promise不再Accept低于收到序号的Proposal,这样“找出这个‘最大序号Value’”和“提出Proposal”之间就不可能插入新的被Accept的序号,从而避免P2c条件被破坏。
到这里为止,基本的Paxos算法就已经透彻分析完了,但是,现在这个算法是使用多个Proposal,会造成活锁问题,需要引入leader来优化,而且,这个算法还只能实现在多个冲突Value中选举一个Value的功能,至于序列化多个Value实现状态机,就需要multi-paxos算法。
simple paxos中文译本:
参考:http://www.cnblogs.com/chen77716/archive/2011/01/27/2130804.html
http://blog.sina.com.cn/s/blog_5d97745a0101ei6f.html
在分布式系统设计领域,Paxos可谓是最重要一致性的算法。Google的大牛们称
All working protocols for asynchronous consensus we have so far encountered have Paxos at their core.
可见此算法的地位。网络上讨论此算法的文章多如牛毛,但大多数让人看了之后仍然是一头雾水,就连维基百科中,对此算法的描述亦有含糊和错误之处。但实际上,此算法的核心思想还是比较简单的,只是大多数文章的分析脱离了实际应用,或是陷入大量实现细节以致掩盖了算法的核心。本文将先给出Paxos算法的设计目的,和算法流程,再反过来分析算法的原理。
Paxos算法实现的是分布式系统多个结点之上数据的一致性,这个算法有如下特性
1.基于消息传递,允许消息传输的丢失,重复,乱序,但是不允许消息被攥改
2.在结点数少于半数失效的情况下仍然能正常的工作,结点失效可以在任何时候发生而不影响算法正常执行。
下面是Basic Paxos算法,注意,这个算法只具有在多个冲突请求中选出一个的功能,并不具备序列化多个请求依次执行的功能。
Paxos算法包含三个角色Proposor,Acceptor,Learner。
实现的时候采用一组固定数目Server,每个Server同时担任上述三个角色,多个Client将自己的请求值Value_i随机发给一个Server处理,然后这一组Server经过协商后得出统一的一个值Chosen_Value,这个值必须被每个Server学习到,同时回复给所有发起请求的Client。
具体算法流程如下,为避免歧义,关键字眼Propose,Proposal,Accept,Value,Choose等保留英文原文
每个Proposor 拿到某个Client的请求Value_i后,在此阶段还不能发起Proposal,只能发送一个Proposal序号N,将序号发送给所有 Acceptor(即所有Server包括自己),整个系统中所有Proposal的序号不能重复而且每个Proposor自己用到的序号必须是递增的,通常的做法是,假设K台Server协同运行Paxos算法,那么Server_i(i=0...K-1)用的Proposal序号初始值为i,以后每次要产生新序号时递增K,这样保证了所有Server的Proposal序号不重复。
阶段1b---Respond with Promise
每个Acceptor收到Proposal序号后,先检查之前是否Repond序号更高的Proposal,若没有,那么就给出Response,这个 Response带有自己已经Accept的序号最高的Proposal(若还没Accept任何Proposal,回复null),同时,Promise自己不再Accept低于接收序号的Proposal。否则,拒绝Respond。
阶段2a---发起Proposal,请求Accept
Proposal 如果得到了来自超过半数的Acceptor的Response,那么就有资格向Acceptor发起Proposal<N,value>。其中,N是阶段1a中发送的序号,value是收到的Response中序号最大的Proposal的Value,若收到的Response全部是 null,那么Value自定义,可直接选一个Client请求的Value_i
阶段2b--Accept Proposal
检查收到的Proposal的序号是否违反阶段1b的Promise,若不违反,则Accept收到的Proposal。
所有Acceptor Accept的Proposal要不断通知所有Learner,或者Learner主动去查询,一旦Learner确认Proposal已经被超过半数的Acceptor Accept,那么表示这个Proposal 的Value 被 Chosen,Learner就可以学习这个Proposal的Value,同时在自己Server上就可以不再受理Proposor的请求。
这个算法能达到什么效果呢,只要保证超过半数的Server维持正常工作,同时连接工作Server的网络正常(网络允许消息丢失,重复,乱序),就一定能保证,
P2a: 在将来某一时刻,自从某个Proposal被多数派Acceptor Accept后,之后Accept的Proposal Value一定和这个Proposal Value相同。
这就是整个算法的关键,保证了这一点,剩下的Learn Value过程就简单了,无需再为消息丢失,Server宕机而担心,例如,假设5台Server编号0~4,Server0,Server1,Server2已经Accept Proposal 100,然后Server0,Server1学习到Proposal 100,刚学习完成Server0,Server1就都宕机了,但这时候,Server2 Server3和Server4由于没有学习到Chosen value,因此还要继续提出Proposal,然后呢,根据这个神奇的算法,最后能使得Server3 Server4将来Accept的值一定是之前选出来过的Proposal 100的Value。
看到这里,大家应该能够隐隐猜到,在这个过程中,Server2之前Accept Proposal 100的Value起了关键作用,下面,我们就来严格证明上述红色字体表示的算法关键点:
1.发起Proposal前要先获得多数派Acceptor中Accept过的序号最大的Proposal Value。若Value为null才能采用自己的Value。
2.阶段1b Promise自己不再Accept低于接收序号的Proposal。
3.Propsal被超半数的Acceptor Accept才能被认定为Chosen Value从而被Learner学习。
这几个约束条件共同作用,达到了上述P2a要求的效果,Paxos算法提出者Leslie Lamport是怎么构造出来的呢,事实上很简单:
首先,把P2a加强为如下条件:
P2b:自从某个Proposal被多数派Acceptor Accept后,之后Proposor提出的Proposal Value一定和这个Proposal Value相同。
显而易见,由P2b可以推出P2a,那么怎么满足P2b呢,实际上,只要满足如下条件:
P2c:发起的Proposal的Value为任意一个多数派Acceptor集合中Accept过的序号最大的Proposal Value。若这个Acceptor集合中没有Accept过Proposal才能采用自己的Value。
如何从P2c推出P2b呢,利用数学归纳法可以轻易做出证明:假设在某一时刻一个超半数Acceptor集合C共同Accept了某个Proposal K,由于集合C和任意一个多数派Acceptor集合S必有一个共同成员,那么,在这个时刻之后,任意一个多数派Acceptor集合S 中Accept过的最大序号的Proposal只可能是Proposal K或序号比Proposal K更大的Proposal,假设为Proposal K2。同理,Proposal K2的Value等于Proposal K或Proposal K3的Value,而K<K3<K2,递推下去,最终推出根据P2c定出的Value必然是Proposal K的Value。
我们可以看到,P2c条件基本就是上述两阶段协议的关键点1,但是还有一个问题,这个P2c条件要求找出这个“最大序号Value”和提出Proposal必须是一个原子操作,这实际上是难以实现的,所以,上述两阶段协议用了一个巧妙的方法避开了这个问题,这就是上述关键点2 Promise所起的作用了。在Acceptor respond“最大序号Value”的时候,Promise不再Accept低于收到序号的Proposal,这样“找出这个‘最大序号Value’”和“提出Proposal”之间就不可能插入新的被Accept的序号,从而避免P2c条件被破坏。
到这里为止,基本的Paxos算法就已经透彻分析完了,但是,现在这个算法是使用多个Proposal,会造成活锁问题,需要引入leader来优化,而且,这个算法还只能实现在多个冲突Value中选举一个Value的功能,至于序列化多个Value实现状态机,就需要multi-paxos算法。
simple paxos中文译本:
参考:http://www.cnblogs.com/chen77716/archive/2011/01/27/2130804.html
发表评论
-
jstatd jsp 等不能正常运行的原因
2013-12-11 11:04 630[root@ bin]# ./jstatd Could not ... -
jvm信息查看
2013-06-03 08:28 7581、查看当前服务的cpu 、内存、磁盘等使用情况,看看是不是使 ... -
tomcat配置数据源(转载)
2012-02-23 10:57 946转载:http://www.douban.com/note/7 ... -
UML 用例图中包含(include)、扩展(extend)和泛化(generalization)三种关系详解
2011-10-21 18:59 731转载:http://www.cnblogs.com/fan01 ... -
第三方接口开发注意事项
2011-09-20 15:54 15231、防止业务数据重复保存,要有唯一识别的编号用于标识相同的业务 ... -
Unveiling the java.lang.Out OfMemoryError
2011-04-13 19:02 902Unveiling the java.lang.Out OfM ... -
getOutputStream() has already been called for this response异常的原因和解决方法
2010-11-27 14:32 858getOutputStream() has already b ... -
servlet filter url-pattern
2010-10-28 09:47 1298ApplicationFilterFactory: /** ... -
JVM内存
2010-09-26 16:03 1013转载:http://blog.csdn.net/c ... -
java nio 笔记
2010-08-19 20:16 1971一、基础知识 操作系统 ... -
集合框架
2010-08-04 22:09 861集合框架: BitSet:??? Ha ... -
基本数据结构介绍
2010-08-01 18:22 937二叉查找树: 性质:设x为二叉查找树中的一个结点。如果y是x的 ... -
理解弱引用(Understanding Weak References)转
2010-07-31 12:58 1229转载:http://blog.csdn.net/x ... -
设置SESSION超时时间
2010-07-02 15:07 1467设置session时间的3个方法: 1. 在tomcat--c ... -
垃圾收集机制
2010-04-23 16:49 809转载:http://tech.ccidnet.com/art ... -
JAVA语言细节总结
2010-04-17 12:47 8611、java 源代码文件通常称为一个编译单元,每个编译单元内最 ... -
utf8的编码原理
2009-07-20 15:08 1152大概意思: 在UTF8中,字符使用1到6个八位序列编码。 只有 ... -
转发(forward)、包含(include)及转向(redirect)的区别与联系
2009-07-17 15:57 977转发(forward)、包含(include)及转向(redi ... -
对数运算公式
2009-07-03 16:15 2150附件二为自然对数的介绍PPT -
二叉树相关知识
2009-07-03 16:04 938一、二叉树的构建与打印 Node.java publ ...
相关推荐
Paxos算法深入分析.doc
很不错的paxos算法分析文档,值得一看,虽不能深入研究,但是可以初步了解!
Paxos算法是一种在异步分布式系统中实现共识...通过深入探讨Paxos议会与分布式系统设计中的相似性,Paxos算法的价值和应用范围得到了强调,同时,该文献也对Paxos算法在不同计算机科学领域的应用和研究发展进行了说明。
通过详细阐述Paxos算法的工作原理,并设计具体的教学案例,该教学方案在实际教学实践中获得了良好的教学效果,加深了学生对Paxos算法工作原理的理解。 Paxos算法是由莱斯利·兰伯特(Leslie Lamport)提出的一种...
本文旨在深入探讨Paxos算法的基本原理、运作机制以及其实现细节,并结合Google Chubby等实际应用案例进行分析。 #### Paxos算法概述 Paxos算法最初由Leslie Lamport提出,旨在解决分布式系统中的一致性问题。该...
这篇名为"cheap-paxos.pdf"的论文深入探讨了Paxos算法的一个变种——廉价Paxos(Cheap Paxos),它在保持Paxos算法基本性质的同时,优化了性能,降低了复杂性,尤其适用于大规模分布式系统。 Paxos算法最初由Leslie...
### Paxos算法详解 #### 一、Paxos算法概览与背景 Paxos算法是一种用于解决分布式...通过以上分析,我们不仅了解了Paxos算法的基本原理,还掌握了其实现的关键步骤。这对于深入研究分布式一致性算法具有重要意义。
为了深入理解基于Paxos算法的ATS数据分布式存储模型,我们首先需要探讨相关的概念和技术背景。 Paxos算法是一种解决分布式系统中一致性问题的算法,由莱斯利·兰伯特(Leslie Lamport)提出。在分布式系统中,多个...
- **性能与容错分析**:分析了Paxos算法在不同条件下的时间性能表现,并对其容错能力进行了深入探讨。 #### 结论 通过本文的介绍可以看出,Clock GTA模型为理解和分析Paxos算法提供了一个强大的工具。这种模型不仅...
Paxos算法实验报告 ...本次实验报告对Paxos算法进行了深入的解析和分析,展示了Paxos算法的基本概念、流程、思想和应用,旨在帮助学生更好地理解Paxos算法,并掌握分布式系统中的一致性解决方案。
《从PAXOS到ZOOKEEPER:分布式一致性原理与实践》是一本深入探讨分布式系统一致性问题的书籍,尤其关注了PAXOS算法和ZooKeeper的实现。在这个数字化时代,分布式系统的应用越来越广泛,而分布式一致性是这些系统中至...
本书《从PAXOS到ZOOKEEPER:分布式一致性原理与实践》深入浅出地介绍了PAXOS算法的原理和ZOOKEEPER的实现,同时结合实际案例分析了分布式一致性在各种应用场景下的解决方案。通过阅读这本书,读者不仅可以理解分布式...
书中主要围绕Paxos算法和ZooKeeper两大主题展开,旨在帮助读者理解分布式环境中的数据一致性是如何实现的,并通过源码分析使读者能够更深入地了解实际应用。 Paxos算法是Leslie Lamport提出的一种解决分布式系统中...
Paxos算法是分布式计算领域中的一个里程碑,它为解决分布式系统中的一致性问题提供了理论基础。Zookeeper则是Apache的一个开源项目,它是基于Paxos等一致性算法实现的分布式协调服务,广泛应用于大数据、云计算等...
《从Paxos到Zookeeper:分布式一致性原理与实践》这本书深入浅出地探讨了分布式系统中的一个重要概念——一致性,以及如何在实际操作中通过Paxos算法和Zookeeper实现这一概念。分布式一致性是分布式系统设计的核心,...
书中深入探讨了Paxos算法的原理及其在分布式系统中的应用,并以此作为基础,进一步分析了Zookeeper的工作原理和实践应用。 Paxos算法是由莱斯利·兰伯特提出的一种解决分布式系统中的一致性问题的算法,它是分布式...
《从PAXOS到ZOOKEEPER分布式一致性原理与实践》是一本深入...通过阅读和分析这些源码,你将能够更好地理解分布式一致性的重要性,掌握如何在实际项目中应用PAXOS算法和ZOOKEEPER,从而提高分布式系统的可靠性和稳定性。
**分布式算法——libpaxos详解** 分布式计算领域中,一致性是至关重要的,尤其是在大规模、高可用性系统中。libpaxos是一个实现Paxos算法的...然而,Paxos算法并不简单,理解和掌握其背后的逻辑需要深入的学习和实践。
这本书详细阐述了从理论到实践的分布式一致性解决方案,涵盖了Paxos算法及其在Zookeeper中的应用。 Paxos算法是Leslie Lamport提出的一种分布式一致性协议,被誉为解决分布式系统一致性问题的基础。它确保在一个...
课程作业可能包括分布式一致性(如Paxos或Raft协议)、分布式计算任务调度、网络路由算法等内容。学习这些算法有助于理解如何在分布式环境下确保数据的一致性、容错性和性能。 最后,**近似算法**是面对NP难问题时...