记录学习Paxos中的一些理解。
Paxos解决的问题
paxos解决的是一个分布式系统如何就某个值达成一致的问题，这里的一致性倾向于强一致性。对于主从结构的数据库，强同步模式要求主机必须把Redolog同步到备机之后，才能应答客户端。对于分布式事务提交的2PC而言，存在协调者的单点问题，并且在prepare阶段使得所有参与者同步阻塞。
因此paxos至少要解决两个问题：
- 自动的主备切换，解决主节点单点问题
- 部分节点宕机，服务仍然可用
Paxos协议
- prepare阶段：
- proposer选择一个提案编号n并将prepare请求发送给acceptors中的一个多数派；
- acceptor收到prepare消息后，如果提案的编号大于它已经回复的所有prepare消息，则acceptor将自己上次接受的提案回复给proposer，并承诺不再回复小于n的提案；
- 批准阶段：
- 当一个proposer收到了多数acceptors对prepare的回复后，就进入批准阶段。它要向回复prepare请求的acceptors发送accept请求，包括编号n和根据P2c决定的value（如果根据P2c没有已经接受的value，那么它可以自由决定value）。
- 在不违背自己向其他proposer的承诺的前提下，acceptor收到accept请求后即接受这个请求。
P2c：如果一个编号为n的提案具有value v，那么存在一个多数派，要么他们中所有人都没有接受（accept）编号小于n的任何提案，要么他们已经接受（accept）的所有编号小于n的提案中编号最大的那个提案具有value v。
Paxos的理解
选主
paxos可以解决自动的主备切换，并保证数据的强同步。paxos通常用来选主，这不说明paxos是一个主从结构，只是为了工程化的实现方便和性能考虑增加了leader（raft），Multi-Paxos并不是由leader驱动去Prepare的。leader的产生是paxos协议的产物。
Multi-Paxos中的leader通过lease机制，保持这个leader的身份，使得其他proposer不再发起提案，这样就进入了一个leader任期。在leader任期中，由于没有了并发冲突，这个leader在对后续的日志进行投票时，不必每次都向多数派询问logID，也不必执行prepare阶段，直接执行accept阶段即可。
这里还需要考虑的一个问题是，由于多个server并发执行leader Elect，可能出现两个server在相近的时间内，先后执行leader Elect都成功，都认为自己是leader的情况。因此，当选leader在开始以leader身份提供服务之前，要使用leader ProposalID写一条日志（称为StartWorking日志），得到多数派确认后，再开始提供服务。这是因为根据Basic-Paxos的约束，可以推断出：先执行leader Elect成功的leader（称为L1），它的proposalID（称为P1）一定会小于后执行leader Elect成功的leader（称为L2）的proposalID（称为P2），而经过了两轮leader Elect，机群内多数派持久化的proposalID一定是P2，而此时L1使用P1执行accept时，由于P1<P2，它将无法得到机群内多数派的accept。
prepare
- prepare阶段无需携带提案内容，只携带Proposalid即可。
- 对于prepare阶段的承诺，其实有两个
- 不再应答Proposalid小于等于（注意：这里是 <= ）当前请求的PrepareRequest；
- 不再应答Proposalid小于（注意：这里是 < ）当前请求的AcceptRequest
- prepare阶段的应答是返回自己已经 Accept过的提案中ProposalID最大的那个提案的内容，如果没有则返回空值。
accept
Proposer收集到多数派应答的PrepareResponse后，从中选择proposalid最大的提案内容，作为要发起Accept的提案，如果这个提案为空值，则可以自己随意决定提案内容。然后携带上当前Proposalid，向Paxos集群的所有机器发送AccpetRequest。
读取
如果一条logID在写入过程中，并未在majority上持久化，那么需要在读取返回结果前，将这个结果在机群上持久化成功。