paxos 算法实现和设计要点

先想到的几个点

1. 用了fast Paxos, 只有一个leader(master,coordinator).  如果leader fail(单点)，那么新的master需要选举。  master选举本身也是个 basic paxos instance， 所以多个节点都请求为master，这里多个节点都扮演了proposer（不是fast paxos了), 这就是普通的paxos算法了.

2.  Phase 2 中如果有收到acceptor 返回的值，那么必须使用其序列号最高的那个值。

3.  Paxos Group replica直接的连接维护： 如果是FC，那么使用connection事件；如果以太网连接，那么必须去polling/ping 对方的机器。其实这里问题很多。

3.1  节点间的连接状态是否要维护在所有的节点上还是就master上。 个人觉得应该在所有的节点上。

3.2  如何处理网络的transient ？

3.3 网络出问题。 集群被隔成几个小集群，互相不能通信了。 某两台机器之间不能连接了。

4. 假设用basic paxos,  有proposer 1, proposer 2和 proposer 3，他们先后发出一轮(one epouch) paxos, 分别是instance 1, instance 2, instance 3, 然后instance 1已经accept 了 proposal from proposer 1 ,  acceptor 2 在想 accept proposal from proposer 1之前promise了 proposal from instance 2 然后accept了proposal frominstance 3 但是在proposer 1和proposer 2获得多数派的acknowledge之前被proposer 3的proposal 抢占了。 所以， proposer 3 的paxos Instance 3会得到不同的值，但是不幸的是在instance 3 达到多数派回复之前，instance 1 达到多数派了，但是按paxos 协议，instance 3选取的是 instance 2 的值啊。  

    所以这里问题是, acceptor回复的是自己之前accept过的值和epoch号还是 回复自己之前accept过且已经被多数派accept也就是说已经choosed的值啊 ？？？？？？？？？？？

5. Proposal是 单个的还是批量的，单个的话会导致效率问题，批量的话又如何组织呢 ？

6. Learner的可以由proposer/master来担任， master如果故障那么learner也故障，反之也一样，而master的单点故障已经有master lease和paxos选举