版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/yujuan110/article/details/86571820
目录
1.Raft解决什么样的问题
2.Raft的工作流程
- replicated state machine
- 节点的三种状态 - 任期（term）
- 工作流程
3.具体问题分析
- leader election
- log replication - safety
4.特殊情况分析
- Cluster membership changes
- Log Compaction
1.Raft解决什么样的问题
拜占庭将军问题是分布式领域最复杂、最严格的容错模型。但在日
常工作中使用的分布式系统面对的问题不会那么复杂，更多的是因
为计算机故障宕机，或者网络通信问题而没法传递信息，这种情况
不考虑计算机之间互相发送恶意信息，极大简化了系统对容错的要
求，最主要的是达到一致性。
假设将军中没有叛军，信使的信息可靠但有可能被暗杀的情况下，
将军们如何达成一致性决定？
Raft的提出背景
第一个被证明的共识算法是 Paxos，由拜占庭将军问题的作者 Leslie
Lamport 在1990年提出，最初以论文难懂而出名，后来在2001重发了
一篇简单版的论文 Paxos Made Simple，然而还是很难懂。
Raft是斯坦福的Diego Ongaro、John Ousterhout在2013年发布的论文《In
Search of an Understandable Consensus Algorithm》中提出的算法；
从2013年发布到现在到现在已经有了十多种语言的Raft算法实现框架，如
etcd，Google的Kubernetes也是用了etcd。
Raft vs.Paxos
- Raft和Paxos都只需要保证n/2+1个节点正常工作就能提供服务。
- Raft和Paxos有着相同的效率。
- Raft更易理解。
- Raft将问题划分为3个子问题：leader election, log replication ,safety，并且使用了更强的一致性来减少了必须需要考虑的状态.
replicated log
- 分布式存储系统通常需要维护多个副本来提高系统可靠性，代价就是 必须维护多个副本的一致性。 Raft协议基于replicated state
- machine，即一组server记录相同 的操作日志，从相同的初始状态起，按相同的顺序执行相同的命令， 最终会达到一直的状态。
- Raft有一个明确的场景，就是管理replicated log的一致性