Multi-Paxos
先看动画学个大概：
http://thesecretlivesofdata.com/raft/
然后参考下面这个学细节
https://www.bilibili.com/video/BV1wt411y7Da/?spm_id_from=333.788.videocard.0
1、客户端给server发送command
2、server使用paxos协议，选择command
3、server等待前一个log entries被applied,然后apply一个新的command到状态机
4、server状态机的结果给客户端。
解答以下问题：
来了一个客户端请求，要用哪个log entry?
性能优化：
- 选个leader来减少proposer 冲突
- 消除大量的Prepare 请求
保证全部复制好
客户端协议
配置改变
注：这个算法其实没有得到严格的证明，说不定有bug。哈哈哈哈
当客户端的请求到达的时候：
- 找到第一个还没被chosen的logEntry
- 运行basic paxos,propose 客户端的command
- prepare请求返回了acceptedValue？
- yes：选择acceptedValue，重新开始
- no：选择客户端的command
如上图，先假设server3掉线了，client command=jmp，发到了server1；
server1找到最小的not chosen index = 3，运行paxos，prepare请求，发现server1已经acceptedValue=cmp，那就接受index=3:cmp，然后重新开始
server1找到最小的not chosen index = 4，运行paxos，prepare请求，发现server2已经acceptedValue=sub，那就接受index=4:sub，然后重新开始
server1找到最小的not chosen index = 5，运行paxos，prepare请求，没发现acceptedValue，终于可以使用client的command。index=5:jmp
选leader：
有最大的id的人当leader
每Tms 每个server发送心跳给其他server
如果一个server在过去的2Tms 没有收到其他server更高的id，他就成为了leader：
- 可以接受客户端的请求
- 扮演proposer和Acceptor
如果server不是leader
- 拒绝客户端请求，转发给leader
- 只能当Acceptor
消除Prepares
为什么需要prepare？
- 用来block掉老的proposal
- 让proposal number代表整个log，而不是一个entry
有点难懂，未完待续。。。。。。。