本文主要是介绍paxos问题与相关的资料记下，回头再好好整理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
自己思考的几个问题：
1. paxos为什么要两阶段？一阶段不行吗？
我在paxos made simple中找到这句话
【在一次消息中】Several values could be proposed by different proposers at about the same time, leading to a situation in which every acceptor has accepted a value, but no single value is accepted by a majority of them.
就是如果同时有多个议案，可能会导致每个acceptor都接受一个议案，形成不了大多数
2. 什么叫value被选择了？
A value is chosen when a single proposal with that value has been accepted by a majority of the acceptors. In that case, we say that the proposal (as well as its value) has been chosen.
3. value被选择了能改变吗？
For any v and n, if a proposal with value v and number n is issued, then there is a set S consisting of a majority of acceptors such that
either
(a) no acceptor in S has accepted any proposal numbered less than n
(b) v is the value of the highest-numbered proposal among all proposals numbered less than n accepted by the acceptors in S.
从(b)中可以看出一旦v被选择了，则作为 value of the highest-numbered proposal ， 是不会改变的
4. acceptor做什么事情？
第一阶段：
如果OK(An acceptor can accept a proposal numbered n iff it has not responded to a prepare request having a number greater than n)
(a) A promise never again to accept a proposal numbered less than n, and
(b) The proposal with the highest number less than n that it has accepted, if any
否则可以忽视
第二阶段：
If an acceptor receives an accept request for a proposal numbered n, it accepts the proposal unless it has already responded to a prepare
request having a number greater than n
5. 为什么优化后(指的是可以忽视number小的提议)要remember信息, 原文：With this optimization, an acceptor needs to remember only the highest-numbered proposal that it has ever accepted and the number of the highest-numbered prepare request to which it has responded，Why？
Because P2c must be kept invariant regardless of failures, an acceptor must remember this information even if it fails and then restarts.
即需要保证P2C这个前提，参考3的问题，值不能改变，不能丢失。
6. 接着上面的问题，那我不优化是不是就可以不记住这些信息呢？即不用持久化了，可以吗？
这个问题暂时搁着
7. 为什么需要leader？
leader为了解决活锁问题，同时，在实际设计中，为了简化复杂性，所有的proposal都交给leader提出，理论上，任何的一个Proposer都可以提的，这也是为什么称它为Proposer。
8. proposer干什么的？
第一阶段：
A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors.
第二阶段：
If the proposer receives a response to its prepare requests(numbered n) from a majority of acceptors, then it sends an accept
request to each of those acceptors for a proposal numbered n with a value v, where v is the value of the highest-numbered proposal among the responses, or is any value if the responses reported no proposals。
实际上，都是由leader来干的事情
9.有一小段看的不是很懂，关于leaner的
Because of message loss, a value could be chosen with no learner ever finding out. The learner could ask the acceptors what proposals they have accepted, but failure of an acceptor could make it impossible to know whether or not a majority had accepted a particular proposal.In that case, learners will find out what value is chosen only when a new proposal is chosen. If a learner needs to know whether a value has been chosen, it can have a proposer issue a proposal, using the algorithm described above.
In that case指的是failure of an acceptor吗？既然失败了，为什么还会有learners will find out what value is chosen？
最后一句话的意思是让proposer也像提给其他的人那样给learner也发一次吗？
10. 关于leader选举，paxos made simple中提到的是这样的
The famous result of Fischer, Lynch, and Patterson [1] implies that a reliable algorithm for electing a proposer must use either randomness or real time—for example, by using timeouts. H
[1] 指的是Michael J. Fischer, Nancy Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. Journal of the ACM, 32(2):374–382, April 1985.
11. 什么是Byzantine fault？
A Byzantine fault is an arbitrary fault that occurs during the execution of an algorithm by a distributed system. It encompasses both omission failures (e.g., crash failures, failing to receive a request, or failing to send a response) andcommission failures (e.g., processing a request incorrectly, corrupting local state, and/or sending an incorrect or inconsistent response to a request). When a Byzantine failure has occurred, the system may respond in any unpredictable way, unless it is designed to have Byzantine fault tolerance.
【任意失败】
12. paxos made simple中的例子
所有的instances(1-134, 138, 139) 已经完成 phase 2, 但并没有被执行
实例:命令
instance1: account1 存款 $1000
instance2: account2 取款 $200
instance3: account3 存款$50
...
instance134: account134 转账 $1000
instance135: instances (1-135, 138, 139) 将会对135提出的决议产生影响. 比如, instance135(对account1做了改变) 依赖于之前的 instances，比如说是instance1(同样对account1做了改变)，这些信息可以从acceptors获得
原文是In phase 1, an acceptor responds with more than a simple OK only if it has already received a phase 2 message from some proposer. (In the scenario, this was the case only for instances 135 and 140.)
instance136:
出现gap的可能
1. 对某一账户account136的操作，消息在一阶段提议给过程中可能是丢失了
2. 在一阶段提议后被其他更高的投票取代
3. 第二阶段发送请求接受(accept!)给acceptors的时候丢失，或者被acceptors接受要慢于其他的编号更高的请求。
对于，136则执行no-op操作
instance137: 同上，执行no-op操作
instance138: 两阶段执行完毕
instance139: account139 转账 $1000
instance140: 和135同样的情形
instance141---：只需要第二个阶段就行了，但是可能会出现gap的可能
原因是
1. 提出的提案编号总是递增的，由于acceptors第一阶段必然会接受的
2. 能够形成大多数，因为实例之间不互相干扰
如果形成不了大多数，还是要跳会到第一阶段的。
以上是基于我的理解
材料：
Paxos Made Practical
http://read.seas.harvard.edu/~kohler/class/08w-dsi/mazieres07paxos.pdf
Paxos Made Live - An Engineering Perspective
http://www.cs.ucla.edu/~kohler/class/08w-dsi/chandra07paxos.pdf
paxos实现
另一个实现是在北大天网实验室的类chubby实现---debby，是使用ICE现实的，看 过之后总觉得有些不太通顺的地方，似乎代码的实现并没有严格遵循paxos算法（很可能是本人水平不足，没看出其中的玄机）；还有一个是Diskless Paxos的实现，不使用disk保存状态怎么实现各个角色的“可重启”呢？还没时间研究，应该还是挺有意思的；除了这些，在google code上有paxos的java实现，BerkeleyDB的复制也有使用了paxos算法。
Paxos适合什么场合？
参考转载的《Paxos算法在大型系统中常见的应用场景》
摘：http://www.cnblogs.com/chinacloud/archive/2011/01/10/1931669.html
paxos made simple：http://pdos.csail.mit.edu/6.824/papers/paxos-simple.pdf
中文翻译：http://blog.csdn.net/sparkliang/article/details/5740882
paxos made simple ppt：http://www.google.com.hk/url?sa=t&rct=j&q=paxos+made+simple&source=web&cd=8&ved=0CGkQFjAH&url=http%3A%2F%2Fwww.cs.nyu.edu%2Fsrg%2Ftalks%2FPaxos.ppt&ei=62pZT_XaFIL2mAWW45XODw&usg=AFQjCNH2sTjV57BZb6pec3AKt-vCWFqAMg&cad=rja
paxos made simple pdf：http://homes.cerias.purdue.edu/~crisn/courses/cs590T/cs590T_lect3_paxos_simple.pdf
paxos made code：http://www.inf.usi.ch/faculty/pedone/MScThesis/marco.pdf
wiki：http://en.wikipedia.org/wiki/Paxos_(computer_science)
the-paxos-commit-algorithm：
http://www.slideshare.net/paolos84/the-paxos-commit-algorithm
这篇关于paxos问题与相关的资料记下，回头再好好整理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
