背景：分布式
一致性模型
1.弱一致性：（最终一致性）
1.1 DNS
1.1 Gossip
2.强一致性：
2.1 同步
2.1 paxos
2.1 raft（multi-paxos）
2.1 ZAB（multi-paxos）----与raft相似，心跳发起者相反（raft由master发起心跳，zab由slave发起）
注：强一致性的算法主要是保证：多数派、顺序性
概念区分：raft、paxos算法实际上是状态机复制的共识算法，raft/paxos/zab + client = 一致性算法
paxos算法：
作者论文中模型的概念：
- Proposal提案，即分布式系统的修改请求，可以表示为[提案编号N，提案内容value]
- Client用户，类似社会民众，负责提出建议
- Propser议员，类似基层人大代表，负责帮Client上交提案
- Acceptor投票者，类似全国人大代表，负责为提案投票，不同意比自己以前接收过的提案编号要小的提案，其他提案都同意，例如A以前给N号提案表决过，那么再收到小于等于N号的提案时就直接拒绝了
- Learner提案接受者，类似记录被通过提案的记录员，负责记录提案
其他总结：
basic-Paxos：
逻辑流程图：
1.客户端发起写请求
2.proposer负责转发（专职人员---表示请求合法性）
3.发送给有投票权的Acceptor
4.Acceptor同意update或者insert，返回proposer，并通知learner记录下来
注：Acceptor才是真正的数据节点，主要保证的是Acceptor数据的一致性
multi Paxos：
设计理由：basic paxos的弊端
1.难以实现
2.效率较低（2轮RPC、一轮类似于选举leader、一轮写入请求）
3.活锁（存在多个proposer，就会出现同时提出多个法案，或者说请求，acceptor会选取版本号大的，认为版本号小的过时了，这样就可能出现各个请求由于重试，增大版本号，相互竞争，却都不能写入成功-----通常给定一个随机的等待时间解决，重试之前等待，但是依然不是很优雅）
基本流程：（角色未简化）
大致逻辑与basic paxos一致
主要优化：
只有一个proposer----只有一个可以合法发送请求者，这个proposer的高可用性可以通过集群实现，所以会有选举leader流程（确认身份）（启动、异常时），保证不需要每次都进行请求的版本检查，减少一次rpc、不会有请求冲突
简化角色：将proposer和acceptor整合成一个角色----分别是角色server的leader和follower
Raft算法：
设计理由：
1.paxos实现太复杂
2.raft为paxos的简化版
1.简化成三个子问题：
1.1 Leader Election
1.2 Log Replication
1.3 Safety
2.重定义角色：
1.1 Leader
1.2 Follower
1.3 Candidate（可以理解成一种中间状态，当Leader挂掉时候，follower想成为leader先要成为Candidate状态）
过半原则写入问题：
当机器节点被分为两个集群（网络不通）时，有过半原则；
例如：
3节点+2节点网络断开，3节点的集群可以通过master正常写入
2节点的集群可接收请求，但是写入会失败，因为没有过半，但是2节点的集群也是在运作的，并且也有一个leader，一个follower；由于这个小集群不能写入（不可用），所以还是认为这个完整的集群是只有一个leader的
当网络突然又好了，2节点的小集群发现leader的版本号落后了，所以会选择放弃自己没有commit的数据，同步3节点的集群的数据，达到一致性
以下两个动画是官方的，可以很好的理解raft原理，这里不再赘述
原理动画：http://thesecretlivesofdata.com/raft/
注：会降低一点可用性，几百毫秒的不可用（请求timeout）
