Once a value has been chosen, future proposals must propose the same value.
•Proposal Number：提案编号；
send Accept(ID, val) to at least a majority of acceptors
环境 1：提案已 Chosen accepted_N = n // save the accepted proposal number
•Proposal：提案 = 提案编号 + 提案的值；
val = accepted_VALUE // value from PROMISE message with the highest accepted ID
但是许多人诉苦这篇论文基础看不懂啊，人们只记着了谁人奇怪的故事，而不是 Paxos 算法。Lamport 走到哪都要被人诉苦一通。于是他忍无可忍，2001 年从头颁发了一篇关于 Paxos 的论文——”Paxos Made Simple[3]”，这次论文中一个公式也没有，摘要也只有一句话：
else
else
val = VALUE // we can use our proposed value
if no
响应（也叫 PROMISE 阶段）：
术语
可是问题依然存在：每个吸收者该如何抉择是否接管这次请求的值呢？[1] Lamport 本身的描写: http://lamport.azurewebsites.net/pubs/pubs.html#lamport-paxos
伪代码：
为了办理 Split Votes 问题，我们答允接管多个差异的值，收到的每一个(every)请求都接管，这时候新的问题呈现了，如下，大概不止一个值被 Chosen，这违反了安详性（safety）。
Proposer 选择一个提案编号 n，向所有的 Acceptor 广播 Prepare(n) 请求。Paxos 只从一个或多个值中选择一个值，假如需要反复运行 Paxos 来建设复制状态机，我们称之为 multi-Paxos，但假如每个呼吁都通过一个Basic Paxos算法实例来到达一致，会发生大量开销。对付 multi-Paxos 可以做一些优化，我们在下篇文章中接头 Paxos 的变种。
环境 2：提案未 Chosen，Proposer 可见
Google Chubby 的作者 Mike Burrows 说过：There is only one consensus protocol, and that’s Paxos.
环境 3：提案未提交，Proposer 不行见
第一轮 Prepare RPCs：
请求（也叫 Prepare 阶段）：
引言
个中，小我私家认为讲授 Paxos 最好的视频[4]来自于 Raft 算法作者 Diego Ongaro，本文回收 Diego 教材中的图片来领略 Paxos 算法，也更正了一个小我私家认为 Diego 笔误的处所。
•不然（即 n 小于便是 Acceptor 之前收到的最大编号）忽略，但经常会回覆一个拒绝响应。
为了降服单点写入问题，于是有了大都派（Quorum）写，思路就是写入一半以上的节点。即，假如集群中有 N 个节点，客户端需要写入 W >= N/2 + 1 个节点。不需要主节点。这种要领可以容忍最多 (N-1)/2 个节点妨碍。
if (proposal_accepted == true) // was a proposal already accepted?
•Proposer：提案提倡者；
3.在提案被 Chosen 后，S5 收到客户端提案值为 Y 的请求，向 S3-S5 发送 Prepare(4.5) 请求，由于编号 4 > 3 会收到提案值为 X 已经被 Chosen 的 PROMISE() 响应
[3] Paxos Made Simple: https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
2.由于 S1-S3 没有任何提案被 Chosen，S1 继承向 S1-S3 发送 Accept(3.1, X) 请求，提案被乐成 Chosen
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
