初接触Paxos算法，难得自认为理解地有一定思路，写下理解过程以便沟通，可能和Paxos和流程并不能严格对应，主要说的是达成提案的过程，如果问题，希望指正。
一、算法目的
有一群Acceptor，简单点每个Acceptor有一投票，只能投给一个提案；一群Proposer，提供提案，并协调达成最终提案。
最终目的投出有且只有一个提案，提案要求得到半数以上的投票，当然其他的提案就不能拿到半数以上的投票了。
二、算法理解
首先把所有Acceptor拥有的投票比喻成坑。Proposer们的提案比喻成为萝卜、青菜、黄瓜等。
占坑：Prepare请求，只要坑没填上，谁后抢就可以是谁的，而被占的一方不能填坑，只能重新抢，原因后续说明
填坑：Accept请求，已填的坑中的东西不能再改了
占坑时间：提案编号，占坑的先后对应编号的小和大
算法过程可以简单说成占坑和填坑的迭代，并最终达到某一个提案填坑超半，描述方便分三个步骤：
步骤一， 抢坑：
每一个Proposer向半数以上的Acceptor询问，当前是否坑还没被填上，如果填上的话，种的是什么，填坑的时间（编号）是什么；如果没填坑的话，先抢着，设下抢的时间。原有已抢过本坑的Proposer（编号比当前的小），下次只能重新抢了。
步骤二，判决是否填坑：
每一个Proposer收集Acceptor回复，在回复的消息中：已填坑的，最晚填坑的种的是什么，假设萝卜，这些回复的信息有多少种萝卜的，还有多少没填的坑，如果发现已种的萝卜+尚未填上的坑数大于半数，那么可以考虑种萝卜了。
1）那为啥要求 已种的萝卜+尚未填上的坑数>半数，因为尚未填上的坑数至少已被抢占了，除非被其他Proposer又抢走了，否则可以保证半数以上可以填上萝卜。当然如果坑被别人又抢走了，那其实就是重复此过程。
2）那为啥考虑最晚（最大编号）填坑的种什么呢，不在本次讨论，可能就是为了让所有Proposer提案快速收敛，达成最终一致。
3）如果 已种的萝卜+尚未填上的坑数<=半数，直接重新回到步骤一。
4）如果当前的回复涉及到的坑都是待填，那具体种什么也由自己定，一般填成自己的提案。
步骤三，填坑
向半数以上的Acceptor发起填坑请求，如果其中有个待填坑，且可以抢（Prepare>=当前待填坑的时间），则填上
完成步骤三后，可能仍没有半数以上的坑被填成萝卜，再重新回到步骤一抢坑。
三、总结
保证最后发起的填坑请求，已种的X+待填坑的>半数，以保证X可以填上半数以上
1. 初始状态下，待填坑的>半数，满足要求，Proposer初次Prepare请求获取的一般都是待填坑的
2. 考虑填坑时，如果 已种的X+待填坑的>半数，开始填坑，如果坑没被抢，最终可以保证X可以填上半数以上
3. 填坑过程中，万一已抢的坑又被抢了，对抢走坑的Proposer, 发起填坑请求时，考虑2。