这是我参与「第四届青训营 」笔记创作活动的的第6天 今天我学习了分布式一致性协议相关知识。
1.1分布式系统面临的挑战
1.数据规模越来越大
2.服务的可用性要求越来越高
3.快速迭代的业务要求系统足够易用\
1.2理想中的分布式系统
高性能：可拓展、低时延、高吞吐
正确：一致性、易于理解
可靠：容错、高可用\
1.3 HDFS
2.1 Paxos
●The Part- Time Parliamen by Lamport 1989也就是人们提到的Paxos
●基本上就是一致性协议的的同义词
●该算法的正确性是经过证明的
Paxos是出了名的难以理解, Lamport本人在01年又写了-篇Paxos Made Simple
"The Paxos Algorighm, when presented in plain English, is very simple."
●算法整体是以比较抽象的形式描述，工程实现时需要做一些修改
Google在实现Chubby的时候是这样描述的
here are significant gaps between the description of the Paxos algorithm and the needs of a real-world system. . . . the final system will be based on an unproven protocol .\
2.2 Raft
2014年发表
1.易于理解作为算法的设计目标
使用了RSM、Log、 RPC的概念直接使用RPC对算法进行了描述
Strong Leader-based
使用了随机的方法减少约束
2.正确性
形式化验证
拥有大量成熟系统
2.3复制状态机（RSM）
● RSM ( replicated state machine )
Raft中所有的consensus都是直接使用Log作为载体
● Commited Index
一旦 Raft更新Commited Index，意味着这个Index前的所有Log都可以提交给状态机了Commited Index是不持久化的,状态机也是volatile的,重启后从第一条Log开始
2.4 Raft角色
2.4 Raft Term
V每个Leader服务于一个termV每个term至多只有一个leader
v每个节点存储当前的term
V每个节点term从一开始,只增不减
V所有rpc的request reponse都携带term
V只commit本term内的log
2.53.8 Raft主节点失效
Leader定期的发送AppendEntries RPCs给其余所有节点
如果Follower有一-段时间没有收到 Leader的AppendEntries，则转换身份成为Candidate
Candidate自增自己的term，同时使用RequestVote RPCs向剩余节点请求投票raft在检查是否可以投票时，会检查log是否outdated，至少不比本身旧才会投给对应的Candidate
如果多数派节点投给它,则成为该term的leader
