深入理解Raft算法.docxVIP

深化理解Raft算法 最近在分布式系统全都性方面，Raft算法比较火啊。所以就抽时间看了下这个算法。 之前已经有Paxos算法，用于处理分布式系统最终全都性问题，而且已经有了zookeeper这个成熟的开源实现。那么这个Raft算法有啥用呢？依据Raft官网的说法，这个算法的错误容忍和功能和Paxos算法类似，但是拥有愈加简约易懂的设计。 看过Paxos算法的童鞋们都晓得，这货简单地和屎一样，为了实现去中心化而考虑了各种简单的边界条件和时序下的牢靠性。而Raft算法则依据实际应用中的需要，简化了设计模型，不接受去中心化设计，而是自动选举中心节点，并且在各种情况和时序下可以保证能够正确的选举出中心节点并保证数据的全都性。而且也正是由于能够选举出独一的主节点（Leader）使得整个通信流程格外地简约，并且易于理解和维护。 那么它是如何做到这些的呢？ 基本算法设计 Raft的基本设计可以参照官网引见 https://raft.github.io/ 官方网站上的图例可以点击节点，然后模仿节点crash或者超时或者收到恳求时的通信流程。其实也是一个javascript的简约实现，有利于我们理解Raft算法的流程。 另外还有一个基本要点的流程有点像PPT的东东也能挂念我们理解 /raft/ 当然最完整的就是这篇Paper了，《In Search of an Understandable Consensus Algorithm (Extended Version)》。大体翻译提取下这篇论文里的核心内容吧。 基本思路是每个节点分为Leader、Follower、Candidate三个形态。 Leader: 主节点 Follower: 从节点 Candidate: 正在竞选主节点（参选节点） 消息形态分为: Uncommit: 未提交转态（Client发到主节点，主节点还没有得到大多数从节点的提交回执） Commited: 已提交转态（从节点收到主节点的消息提交，还未收到确认报文） Applied: 已确认转态（从节点收到主节点的确认报文，或主节点已收到大多数从节点的提交回执） 全部的节点中都要记录以下信息 CurrentTerm: 节点的当前选举版本号（发起竞选主节点时要更新这个值），后面的Term指代消息中的选举版本号或者生产消息时的选举版本号 Voted For: 主节点投票给谁 Log: log是论文里的描述，其实也就是消息的内容，后面用消息指代这里提到的Log Commit Index: 提交序号（每次收到客户端消息时要更新这个值） LastApplied: 最终确认的消息序号 下面是仅主节点需要记录的数据 NextIndex[]: 预估的每个从节点下一个的Log的序号（初始化为最终的log索引+1） MatchIndex[]: 已经确认的每个从节点的下一个Log的序号（初始化为0） RPC消息有两种： AppendEntries RPC（心跳、消息同步RPC） RPC恳求: RPC回复: 收方判定条件 假如恳求包内Term CurrentTerm，回复失败 假如节点内不包含Term等于PrevLogTerm但CommitIndex不等于PrevLogIndex的消息，则回复失败 假如存在消息和拿到的恳求包里的冲突（CommitIndex相同但Term不同），则移除全部冲突之后的消息，并用新的消息掩盖 假如消息不在已有消息集合中，追加数据 假如LeaderCommit大于本地的CommitIndex，CommitIndex要设置成LeaderCommit和最终一条消息（Entries）的CommitIndex里的最小值 RequestVote RPC（竞选主节点RPC） RPC恳求: RPC回复: 接收方判定条件 假如恳求包内LastLogTerm = CurrentTerm，投拒绝票 论文里写得是*小于*，实际应当是*小于等于*，实际测试也是小于等于。由于等于的情况包含，从节点已经投了一个同期的参选节点，或者本人是参选节点，收到一个同期的竞选消息。 假如Voted For是空的或者和CandidateId相等，则仅参选节点的消息最新(up-to-date)才投同意票 消息最新(up-to-date)的判定方式是: 假如参选节点的最终的消息的Term比投票者更大或者Term相等且CommitIndex大于等于投票节点的最终一个消息。那么参选节点的消息会被投票者认为是最新（只是相对于投票者更新） PS: 这里我一开头认为是节点的Term和CommitIndex，导致后面的协商流程一直理解不了。但是这是实际上应当是最终一条消息的Term和CommitIndex。 服务器规律规章 全部服务器 假如CommitIndex Last