paxos算法-001

转载 2016年06月02日 08:44:20

       这个是本人转载于wiki,仅仅为了方便本人阅读。


第一部分:

Paxos算法莱斯利·兰伯特英语:Leslie LamportLaTeX中的“La”)于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。[1]

问题和假设[编辑]

分布式系统中的节点通信存在两种模型:共享内存(Shared memory)和消息传递(Messages passing)。基于消息传递通信模型的分布式系统,不可避免的会发生以下错误:进程可能会慢、被杀死或者重启,消息可能会延迟、丢失、重复,在基础Paxos场景中,先不考虑可能出现消息篡改即拜占庭错误的情况。Paxos算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致,保证不论发生以上任何异常,都不会破坏决议的一致性。一个典型的场景是,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列,需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中,是分布式计算中的重要问题。因此从20世纪80年代起对于一致性算法的研究就没有停止过。

为描述Paxos算法,Lamport虚拟了一个叫做Paxos的希腊城邦,这个岛按照议会民主制的政治模式制订法律,但是没有人愿意将自己的全部时间和精力放在这种事情上。所以无论是议员,议长或者传递纸条的服务员都不能承诺别人需要时一定会出现,也无法承诺批准决议或者传递消息的时间。但是这里假设没有拜占庭将军问题(Byzantine failure,即虽然有可能一个消息被传递了两次,但是绝对不会出现错误的消息);只要等待足够的时间,消息就会被传到。另外,Paxos岛上的议员是不会反对其他议员提出的决议的。

对应于分布式系统,议员对应于各个节点,制定的法律对应于系统的状态。各个节点需要进入一个一致的状态,例如在独立Cache对称多处理器系统中,各个处理器读内存的某个字节时,必须读到同样的一个值,否则系统就违背了一致性的要求。一致性要求对应于法律条文只能有一个版本。议员和服务员的不确定性对应于节点和消息传递通道的不可靠性。

算法[编辑]

算法的提出与证明[编辑]

首先将议员的角色分为proposers,acceptors,和learners(允许身兼数职)。proposers提出提案,提案信息包括提案编号和提议的value;acceptor收到提案后可以接受(accept)提案,若提案获得多数acceptors的接受,则称该提案被批准(chosen);learners只能“学习”被批准的提案。划分角色后,就可以更精确的定义问题:

  1. 决议(value)只有在被proposers提出后才能被批准(未经批准的决议称为“提案(proposal)”);
  2. 在一次Paxos算法的执行实例中,只批准(chosen)一个value;
  3. learners只能获得被批准(chosen)的value。

另外还需要保证progress。这一点以后再讨论。

作者通过不断加强上述3个约束(主要是第二个)获得了Paxos算法。

批准value的过程中,首先proposers将value发送给acceptors,之后acceptors对value进行接受(accept)。为了满足只批准一个value的约束,要求经“多数派(majority)”接受的value成为正式的决议(称为“批准”决议)。这是因为无论是按照人数还是按照权重划分,两组“多数派”至少有一个公共的acceptor,如果每个acceptor只能接受一个value,约束2就能保证。

于是产生了一个显而易见的新约束:

P1:一个acceptor必须接受(accept)第一次收到的提案。

注意P1是不完备的。如果恰好一半acceptor接受的提案具有value A,另一半接受的提案具有value B,那么就无法形成多数派,无法批准任何一个value。

约束2并不要求只批准一个提案,暗示可能存在多个提案。只要提案的value是一样的,批准多个提案不违背约束2。于是可以产生约束P2:

P2:一旦一个具有value v的提案被批准(chosen),那么之后批准(chosen)的提案必须具有value v。

注:通过某种方法可以为每个提案分配一个编号,在提案之间建立一个全序关系,所谓“之后”都是指所有编号更大的提案。

如果P1和P2都能够保证,那么约束2就能够保证。

批准一个value意味着多个acceptor接受(accept)了该value.因此,可以对P2进行加强:

P2a:一旦一个具有value v的提案被批准(chosen),那么之后任何acceptor再次接受(accept)的提案必须具有value v。

由于通信是异步的,P2a和P1会发生冲突。如果一个value被批准后,一个proposer和一个acceptor从休眠中苏醒,前者提出一个具有新的value的提案。根据P1,后者应当接受,根据P2a,则不应当接受,这中场景下P2a和P1有矛盾。于是需要换个思路,转而对proposer的行为进行约束:

P2b:一旦一个具有value v的提案被批准(chosen),那么以后任何proposer提出的提案必须具有value v。

由于acceptor能接受的提案都必须由proposer提出,所以P2b蕴涵了P2a,是一个更强的约束。

但是根据P2b难以提出实现手段。因此需要进一步加强P2b。

假设一个编号为m的value v已经获得批准(chosen),来看看在什么情况下对任何编号为n(n>m)的提案都含有value v。因为m已经获得批准(chosen),显然存在一个acceptors的多数派C,他们都接受(accept)了v。考虑到任何多数派都和C具有至少一个公共成员,可以找到一个蕴涵P2b的约束P2c:

P2c:如果一个编号为n的提案具有value v,那么存在一个多数派,要么他们中所有人都没有接受(accept)编号小于n 
的任何提案,要么他们已经接受(accept)的所有编号小于n的提案中编号最大的那个提案具有value v。

可以用数学归纳法证明P2c蕴涵P2b:

假设具有value v的提案m获得批准,当n=m+1时,采用反证法,假如提案n不具有value v,而是具有value w,根据P2c,则存在一个多数派S1,要么他们中没有人接受过编号小于n的任何提案,要么他们已经接受的所有编号小于n的提案中编号最大的那个提案是value w。由于S1和通过提案m时的多数派C之间至少有一个公共的acceptor,所以以上两个条件都不成立,导出矛盾从而推翻假设,证明了提案n必须具有value v;

若(m+1)..(N-1)所有提案都具有value v,采用反证法,假如新提案N不具有value v,而是具有value w',根据P2c,则存在一个多数派S2,要么他们没有接受过m..(N-1)中的任何提案,要么他们已经接受的所有编号小于N的提案中编号最大的那个提案是value w'。由于S2和通过m的多数派C之间至少有一个公共的acceptor,所以至少有一个acceptor曾经接受了m,从而也可以推出S2中已接受的所有编号小于n的提案中编号最大的那个提案的编号范围在m..(N-1)之间,而根据初始假设,m..(N-1)之间的所有提案都具有value v,所以S2中已接受的所有编号小于n的提案中编号最大的那个提案肯定具有value v,导出矛盾从而推翻新提案n不具有value v的假设。根据数学归纳法,我们证明了若满足P2c,则P2b一定满足。

P2c是可以通过消息传递模型实现的。另外,引入了P2c后,也解决了前文提到的P1不完备的问题。

算法的内容[编辑]

要满足P2c的约束,proposer提出一个提案前,首先要和足以形成多数派的acceptors进行通信,获得他们进行的最近一次接受(accept)的提案(prepare过程),之后根据回收的信息决定这次提案的value,形成提案开始投票。当获得多数acceptors接受(accept)后,提案获得批准(chosen),由proposer将这个消息告知learner。这个简略的过程经过进一步细化后就形成了Paxos算法。

在一个paxos实例中,每个提案需要有不同的编号,且编号间要存在全序关系。可以用多种方法实现这一点,例如将序数和proposer的名字拼接起来。如何做到这一点不在Paxos算法讨论的范围之内。

如果一个没有chosen过任何proposer提案的acceptor在prepare过程中回答了一个proposer针对提案n的问题,但是在开始对n进行投票前,又接受(accept)了编号小于n的另一个提案(例如n-1),如果n-1和n具有不同的value,这个投票就会违背P2c。因此在prepare过程中,acceptor进行的回答同时也应包含承诺:不会再接受(accept)编号小于n的提案。这是对P1的加强:

P1a:当且仅当acceptor没有回应过编号大于n的prepare请求时,acceptor接受(accept)编号为n的提案。

现在已经可以提出完整的算法了。

决议的提出与批准[编辑]

通过一个决议分为两个阶段:

  1. prepare阶段:
    1. proposer选择一个提案编号n并将prepare请求发送给acceptors中的一个多数派;
    2. acceptor收到prepare消息后,如果提案的编号大于它已经回复的所有prepare消息,则acceptor将自己上次接受的提案回复给proposer,并承诺不再回复小于n的提案;
  2. 批准阶段:
    1. 当一个proposer收到了多数acceptors对prepare的回复后,就进入批准阶段。它要向回复prepare请求的acceptors发送accept请求,包括编号n和根据P2c决定的value(如果根据P2c没有已经接受的value,那么它可以自由决定value)。
    2. 在不违背自己向其他proposer的承诺的前提下,acceptor收到accept请求后即接受这个请求。

这个过程在任何时候中断都可以保证正确性。例如如果一个proposer发现已经有其他proposers提出了编号更高的提案,则有必要中断这个过程。因此为了优化,在上述prepare过程中,如果一个acceptor发现存在一个更高编号的提案,则需要通知proposer,提醒其中断这次提案。

实例[编辑]

用实际的例子来更清晰地描述上述过程:

有A1, A2, A3, A4, A5 5位议员,就税率问题进行决议。议员A1决定将税率定为10%,因此它向所有人发出一个草案。这个草案的内容是:

现有的税率是什么?如果没有决定,则建议将其定为10%.时间:本届议会第3年3月15日;提案者:A1

在最简单的情况下,没有人与其竞争;信息能及时顺利地传达到其它议员处。

于是, A2-A5回应:

我已收到你的提案,等待最终批准

而A1在收到2份回复后就发布最终决议:

税率已定为10%,新的提案不得再讨论本问题。

这实际上退化为二段提交协议。

现在我们假设在A1提出提案的同时, A5决定将税率定为20%:

现有的税率是什么?如果没有决定,则建议将其定为20%.时间:本届议会第3年3月15日;提案者:A5

草案要通过侍从送到其它议员的案头. A1的草案将由4位侍从送到A2-A5那里。现在,负责A2和A3的侍从将草案顺利送达,负责A4和A5的侍从则不上班. A5的草案则顺利的送至A3和A4手中。

现在, A1, A2, A3收到了A1的提案; A3, A4, A5收到了A5的提案。按照协议, A1, A2, A4, A5将接受他们收到的提案,侍从将拿着

我已收到你的提案,等待最终批准

的回复回到提案者那里。

而A3的行为将决定批准哪一个。

情况一[编辑]

假设A1的提案先送到A3处,而A5的侍从决定放假一段时间。于是A3接受并派出了侍从. A1等到了两位侍从,加上它自己已经构成一个多数派,于是税率10%将成为决议. A1派出侍从将决议送到所有议员处:

税率已定为10%,新的提案不得再讨论本问题。

A3在很久以后收到了来自A5的提案。由于税率问题已经讨论完毕,他决定不再理会。但是他要抱怨一句:

税率已在之前的投票中定为10%,你不要再来烦我!

这个回复对A5可能有帮助,因为A5可能因为某种原因很久无法与与外界联系了。当然更可能对A5没有任何作用,因为A5可能已经从A1处获得了刚才的决议。

情况二[编辑]

依然假设A1的提案先送到A3处,但是这次A5的侍从不是放假了,只是中途耽搁了一会。这次, A3依然会将"接受"回复给A1.但是在决议成型之前它又收到了A5的提案。这时协议有两种处理方式:

1.如果A5的提案更早,按照传统应该由较早的提案者主持投票。现在看来两份提案的时间一样(本届议会第3年3月15日)。但是A5是个惹不起的大人物。于是A3回复:

我已收到您的提案,等待最终批准,但是您之前有人提出将税率定为10%,请明察。

于是, A1和A5都收到了足够的回复。这时关于税率问题就有两个提案在同时进行。但是A5知道之前有人提出税率为10%.于是A1和A5都会向全体议员广播:

 税率已定为10%,新的提案不得再讨论本问题。

一致性得到了保证。

2. A5是个无足轻重的小人物。这时A3不再理会他, A1不久后就会广播税率定为10%.

情况三[编辑]

在这个情况中,我们将看见,根据提案的时间及提案者的权势决定是否应答是有意义的。在这里,时间和提案者的权势就构成了给提案编号的依据。这样的编号符合"任何两个提案之间构成偏序"的要求。

A1和A5同样提出上述提案,这时A1可以正常联系A2和A3; A5也可以正常联系这两个人。这次A2先收到A1的提案; A3则先收到A5的提案. A5更有权势。

在这种情况下,已经回答A1的A2发现有比A1更有权势的A5提出了税率20%的新提案,于是回复A5说:

我已收到您的提案,等待最终批准。

而回复了A5的A3发现新的提案者A1是个小人物,不予理会。

A1没有达到多数,A5达到了,于是A5将主持投票,决议的内容是A5提出的税率20%.

如果A3决定平等地对待每一位议员,对A1做出"你之前有人提出将税率定为20%"的回复,则将造成混乱。这种情况下A1和A5都将试图主持投票,但是这次两份提案的内容不同。

这种情况下, A3若对A1进行回复,只能说:

有更大的人物关注此事,请等待他做出决定。

另外,在这种情况下, A4与外界失去了联系。等到他恢复联系,并需要得知税率情况时,他(在最简单的协议中)将提出一个提案:

现有的税率是什么?如果没有决定,则建议将其定为15%.时间:本届议会第3年4月1日;提案者:A4

这时,(在最简单的协议中)其他议员将会回复:

税率已在之前的投票中定为20%,你不要再来烦我!

决议的发布[编辑]

一个显而易见的方法是当acceptors批准一个value时,将这个消息发送给所有learner。但是这个方法会导致消息量过大。

由于假设没有Byzantine failures,learners可以通过别的learners获取已经通过的决议。因此acceptors只需将批准的消息发送给指定的某一个learner,其他learners向它询问已经通过的决议。这个方法降低了消息量,但是指定learner失效将引起系统失效。

因此acceptors需要将accept消息发送给learners的一个子集,然后由这些learners去通知所有learners。

但是由于消息传递的不确定性,可能会没有任何learner获得了决议批准的消息。当learners需要了解决议通过情况时,可以让一个proposer重新进行一次提案。注意一个learner可能兼任proposer。

Progress的保证[编辑]

根据上述过程当一个proposer发现存在编号更大的提案时将终止提案。这意味着提出一个编号更大的提案会终止之前的提案过程。如果两个proposer在这种情况下都转而提出一个编号更大的提案,就可能陷入活锁,违背了Progress的要求。这种情况下的解决方案是选举出一个leader,仅允许leader提出提案。但是由于消息传递的不确定性,可能有多个proposer自认为自己已经成为leader。Lamport在The Part-Time Parliament一文中描述并解决了这个问题。

其他[编辑]

微软公司为简化的Paxos算法申请了专利[2]。但专利中公开的技术和本文所描述的不尽相同。

谷歌公司(Google公司)在其分布式锁服务(Chubby lock)中应用了Paxos算法[3]。Chubby lock应用于大表(Bigtable),后者在谷歌公司所提供的各项服务中得到了广泛的应用[4]

参考文献[编辑]

注:这是该算法第一次公开发表。
注:Lamport觉得同行无法接受他的幽默感,于是用容易接受的方法重新表述了一遍。
  1. ^ Lamport本人在http://research.microsoft.com/users/lamport/pubs/pubs.html#lamport-paxos 中描写了他用9年时间发表这个算法的前前后后
  2. ^ 中国专利局的相关页面
  3. ^ The Chubby lock service for loosely-coupled distributed systems
  4. ^ Bigtable: A Distributed Storage System for Structured Data

第二部分:

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算法中所有的行为:

  1. Proposer提出议题
  2. Acceptor初步接受 或者 Acceptor初步不接受
  3. 如果上一步Acceptor初步接受则Proposer再次向Acceptor确认是否最终接受
  4. 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(政府官员):

  1. 现在需要对一项议题来进行paxos过程,议题是“A项目我要中标!”,这里的“我”指每个带着他的秘书Proposer的Client老板。
  2. Proposer当然听老板的话了,赶紧带着议题和现金去找Acceptor政府官员。
  3. 作为政府官员,当然想谁给的钱多就把项目给谁。
  4. 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算法里的角色都是这样的不靠谱,不过没关系,结果靠谱就可以了。该算法就是为了追求结果的一致性。



转载地址:

https://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95


http://www.cnblogs.com/endsock/p/3480093.html

PAXOS算法的说明文档,英文的

  • 2011年07月06日 17:16
  • 117KB
  • 下载

深入理解 paxos 算法 PDF

  • 2010年11月07日 20:35
  • 658KB
  • 下载

Zookeeper的Paxos分布式一致性算法-类比的方式去理解

Paxos是一个基于消息传递的一致性算法,近几年被广泛应用于分布式计算中,Google的Chubby,Apache的Zookeeper都是基于它的理论来实现的,Paxos还被认为是到目前为止唯一的分布...

Paxos算法论文

  • 2016年10月27日 10:14
  • 79KB
  • 下载

paxos算法的分析与研究

paxos算法是对分布式系统中,对各个子系统协调一致的协议,使得子系统在一个事务中,只有一个命令能够成功,保证数据的强一致性。从百度或知乎上的文章分析看出,paxos就是对某个值,有不同的事务想修改,...

Paxos算法__我的理解

参考 :http://lib.csdn.net/base/11/structurePaxos是什么Paxos 算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。一个典型的场景是,在一个分布式...

分布式事务与一致性算法Paxos & raft & zab

说明:以下内容总结自网络 1.CAP原理 要想数据高可用,就得写多份数据 写多分数据就会导致数据一致性问题 数据一致性问题会引起性能问题 2.一致性模型 弱一致...

ZAB与Paxos算法的联系与区别。

博文中的内容来源《从Paxos到Zookeeper 分布式一致性原理与实践》这一本书,感激不尽。...

一步一步理解Basic Paxos算法

一步一步理解Basic Paxos算法

分布式一致性算法--Basic Paxos

Proposer:提议发起者 Acceptor:提议批准者 Proposal ID:每个提议都有一个编号,编号越高优先级越高 Paxos Instance: Paxos 用来在多个节点之间对同一...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:paxos算法-001
举报原因:
原因补充:

(最多只允许输入30个字)