Basic-Paxos解决的问题：在一个分布式系统中，如何就一个提案达成一致。
需要借助两阶段提交实现：
Prepare阶段：
Proposer选择一个提案编号n并将prepare请求发送给 Acceptor。
Acceptor收到prepare消息后，如果提案的编号大于它已经回复的所有prepare消息，则Acceptor将自己上次接受的提案回复给Proposer，并承诺不再回复小于n的提案。
Accept阶段：
当一个Proposer收到了多数Acceptor对prepare的回复后，就进入批准阶段。它要向回复prepare请求的Acceptor发送accept请求，包括编号n和根据prepare阶段决定的value（如果根据prepare没有已经接受的value，那么它可以自由决定value）。
在不违背自己向其他Proposer的承诺的前提下，Acceptor收到accept请求后即接受这个请求。
Mulit-Paxos
Mulit-Paxos解决的问题：在一个分布式系统中，如何就一批提案达成一致。
当存在一批提案时，用Basic-Paxos一个一个决议当然也可以，但是每个提案都经历两阶段提交，显然效率不高。Basic-Paxos协议的执行流程针对每个提案（每条redo log）都至少存在三次网络交互：1. 产生log ID；2. prepare阶段；3. accept阶段。
所以，Mulit-Paxos基于Basic-Paxos做了优化，在Paxos集群中利用Paxos协议选举出唯一的leader，在leader有效期内所有的议案都只能由leader发起。
这里强化了协议的假设：即leader有效期内不会有其他server提出的议案。因此，对于后续的提案，我们可以简化掉产生log ID阶段和Prepare阶段，而是由唯一的leader产生log ID，然后直接执行Accept，得到多数派确认即表示提案达成一致（每条redo log可对应一个提案）。
异步通信环境并非只有paxos能解决一致性问题，经典的两阶段提交也能达到同样的效果，但是分布式环境里面，除了消息网络传输的恶劣环境，还有另外一个让人痛心疾首的，就是机器的当机，甚至永久失联。在这种情况下，两阶段提交将无法完成一个一致性的写入，而paxos，只要多数派机器存活就能完成写入，并保证一致性。
至此，总结一下paxos就是一个在异步通信环境，并容忍在只有多数派机器存活的情况下，仍然能完成一个一致性写入的协议
====
Paxos 和两阶段提交（Two-Phase Commit，2PC）都是分布式系统中常用的一致性协议，用于确保分布式系统中的数据一致性。虽然它们都是用于解决分布式系统中的一致性问题，但是它们的实现方式和应用场景有所不同。
Paxos 是一种基于消息传递的一致性协议，它通过多个阶段的投票来达成一致性。在 Paxos 协议中，每个节点都可以充当提议者（Proposer）、接受者（Acceptor）或者学习者（Learner）。当一个节点想要提交一个提案时，它首先向其他节点发送一个提案，然后等待其他节点的回复。如果大多数节点同意该提案，那么该提案就被接受，并且被提交到系统中。Paxos 协议的优点是它可以在网络分区的情况下保证一致性，但是它的实现比较复杂，需要多个阶段的投票。
两阶段提交是一种基于事务的一致性协议，它通过两个阶段的提交来达成一致性。在 2PC 协议中，每个节点都可以充当协调者（Coordinator）或者参与者（Participant）。当一个节点想要提交一个事务时，它首先向其他节点发送一个预提交请求，然后等待其他节点的回复。如果所有节点都同意该事务，那么该事务就被提交到系统中。如果有任何一个节点拒绝该事务，那么该事务就被回滚。2PC 协议的优点是它比较简单，容易实现，但是它不能在网络分区的情况下保证一致性。
因此，Paxos 和两阶段提交的联系在于它们都是用于解决分布式系统中的一致性问题，但是它们的实现方式和应用场景有所不同。Paxos 更适用于需要在网络分区的情况下保证一致性的场景，而两阶段提交更适用于需要简单实现的场景。
