raft我真的懂了

写在前面

读懂本文章你会得到什么？

1. 什么是raft？raft是怎么运行的？为什么要用raft？
2. 如何学习raft？
3. 分布式领域一些其他基本知识，没有详细讲解，但提供思路，抛砖引玉

接下来让我们一起揭开raft的神秘面纱。

背景

What raft

Raft是一种共识算法。共识算法是做什么的？为什么需要共识算法？
要解释共识算法，得先讲述复制状态机

复制状态机

一组 Server 的状态机计算相同状态的副本，即使有一部分 Server 宕机了它们仍然能够继续运行。最终，这些 Server 看起来就像一个单独的、高可靠的状态机。

状态机处理日志中相同顺序的命令序列，因此会输出相同的结果。
一般通过使用复制日志来实现复制状态机。保证复制日志的一致性是共识算法的任务。

共识算法

共识算法管理来自客户端的状态机命令的复制日志，确保每一个日志最终包含相同的请求且顺序也相同。即上图中的log
对于实际系统，共识算法一般具有如下特点：

• 安全。满足在所有非拜占庭条件下确保安全（从来不会返回错误结果），包括网络延迟、分区、丢包、重复和重排序。
• 高可用。只要集群中的大部分 Server 正常运行，并能够互相通信且可以同客户端通信，这个集群就完全可用。因此，拥有5个 Server 的集群可以容忍其中的2个 Server 失败。假使通过停掉某些 Server 使其失败，稍后它们会从持久化存储的状态进行恢复，并重新加入到集群中。
• 不依赖于时序。确保日志的一致性：时钟错误，以及极端情况下的消息延迟。
• 少量慢server不影响整体性能。通常情况下，只要集群中大多数 Server 成功响应了某一轮 RPC 调用，一个命令就算完成。少部分较慢的 Server 不应该影响到整个系统性能。

Why raft？

Raft算法在2014年由Diego Ongaro提出。在Raft提出之前的10多年，Paxos几乎是共识算法的代名词，大多数共识算法的实现都基于它或者受它影响，但是其有两个致命缺点：

Paxos难理解

Diego Ongaro 发现就算是经验丰富的专家，在理解 Paxos 算法的道路上也是费了不少劲。而他也是等读了一些 Paxos 算法的简化解释和开始开发自己的共识算法时，才算真正掌握了 Paxos 算法，这过程足足花了一年。

Paxos难实现

下面是来自 Chubby （Google基于Paxos实现的分布式锁服务，典型应用是GFS和Big Table）实现的一条有代表性的评论：

Paxos 算法的描述与实际实现之间存在巨大的鸿沟…最终的系统将会基于一个没有被证明的协议而构建起来。

Raft 是一种比Paxos更易理解，更容易在生产实现的共识算法，Raft把Understandability 作为算法设计的首要目的

raft特点

工程实现简单

一个能力不错的工程师在充分理解了 Raft 算法后，都可以相对容易地用他所擅长的编程语言快速实现算法的原型。时至今日，几乎每种主流编程语言都对 Raft 算法有一个实现版本，可参考这个列表；

社区传播性广

每个人都能搞懂的东西总比复杂难懂的东西流传要广，这是毋庸置疑的。虽然 Raft 算法是 Diego Ongaro 在斯坦福大学的博士论文，但是其精简版（就是篇幅较短的那篇论文）并非曲高和寡。读者只要具备良好的计算机算法基础，花个几天时间（甚至更短），都可以弄明白 Raft 算法的主体过程。懂的人多了，自然也就形成了社区，社区越活越，为算法添砖加瓦的人也就越多。

易于应用和验证

没有人敢把自己不理解的东西应用于生产环境中。正因 Raft 算法的清晰易懂，越来越多的开源项目尝试引入 Raft 算法来解决分布式一致性问题。特别地，在分布式存储领域，基于 Raft 算法构建的项目百花齐放，欣欣向荣。

轶闻趣事

以下内容摘抄自Raft 算法的前世今生 - 知乎专栏
在 Raft 算法提出之前，学术界早已有 Paxos 算法 来解决分布式共识问题。Paxos 算法由 Leslie Lamport 于 1990 年提出。Lamport 在叙述 Paxos 算法时采用了一种非常奇特的方式进行：讲故事。Lamport 虚拟了一个叫 Paxos 的希腊城邦，这个城邦按照议会民主制的政治模式来制定法律，其中有议员，议长和传纸条的服务员等几类角色。通过这种拟人化的角色和场景，Lamport 概述了议案制定的过程，即 Paxos 算法（多个议员间就议案达成一致的结论）。论文投稿时，审稿人觉得这个算法很有趣但不是很重要（可能受限于当时计算机发展水平，分布式共识算法应用场景有限），Lamport 当时就觉得这些人毫无幽默感。时隔多年后，Lamport 的朋友因构建分布式系统的需要，正在寻找一种共识算法，于是发现了 Paxos 算法的重要性。当越来越多的人意识到 Paxos 算法的重要性后，Lamport 在 1998 年重新发表了之前的那篇论文 并一举受到重视。Lamport 后面发现还是很多人觉得 Paxos 算法难以理解，于是又将之前的论文做了简化并发表出来。
到了 2006 年，Google 在两篇经典论文 Bigtable:A Distributed Storage System for Structured Data 和 The Chubby lock service for loosely-coupled distributed systems 中提及用 Paxos 算法实现了一个分布式锁服务 Chubby，于是 Paxos 算法开始进入工业界领域被广大技术人员熟知。
在分布式共识算法领域，Paxos 算法可以说是宗师级角色，统治该领域十余年，大多数共识算法都是在其基础上进行改进和优化，Raft 算法也不例外。正因如此，Chubby 的作者 Mike Burrows 曾说过（据说是他说的）：只有一种分布式共识算法，那就是 Paxos，其他共识算法都只是 Paxos 算法的不完整版（大意）。

Paxos 算法存在的问题

Raft 算法的作者 Diego Ongaro 在研究 Paxos 算法时，深受其复杂性困扰。他觉得 Paxos 算法是一门极其难懂的算法，其工程化实践更是困难重重，原始的 Paxos 算法不经过一番修改很难应用于工程之中，而修改后的 Paxos 算法又很难保证其正确性。他总结出 Paxos 算法有两个大问题：

非常难以理解

完整的 Paxos 算法很难让人建立起易理解的直觉。Diego Ongaro 发现就算是经验丰富的专家，在理解 Paxos 算法的道路上也是费了不少劲。而他也是等读了一些 Paxos 算法的简化解释和开始开发自己的共识算法时，才算真正掌握了 Paxos 算法，这过程足足花了一年。

没有给工程实现提供一个好的基础

目前还没有一个被广泛使用和认可的 multi-Paxos 算法。Lamport 的算法描述只提供了一个素描式的框架，其中隐去了很多细节。这导致很多对 multi-Paxos 的实现最终都是一个未被严格证明的协议。Paxos 算法形式化的描述对证明其正确性很有用，但在工程实现上则价值不大。
Paxos 算法的内核采用的是对称的 peer-to-peer 方式，这是对真实世界决议的简化描述，但实际应用中很少采用。如果要在一组决议中达成一致，最简单也最快的方式就是选出一个 leader，由 leader 来协调决议。
Paxos 算法自首次提出以来已过去十多年了，开源社区几乎没有一个被广泛认可的工程实现，很多 Paxos 算法的实现都是对其完整版的近似。
正因如此，Diego Ongaro 打算自己开发一门新的共识算法，一门能够为教学和工程实践提供良好基础，并能等价于 Paxos 算法的共识算法。于是，他决定把 Understandability 作为这门算法的首要设计原则。这门新的共识算法就是 Raft 算法。

Raft 算法的命名

Raft 算法为什么取名为 Raft 呢 ？关于这个问题，Diego Ongaro 曾在 Google Groups 的 raft-dev 频道这么说到：
我们选择取名为 Raft 是因为下面几个原因：

• Raft 不是某几个单词首字母的缩写，但是我们想到了这么几个词：reliable（可靠的），replicated（可复制的），redundant（冗余的）和 fault-toleran （容错的）；

• 我们想到了 logs（算法中意为 “日志”，英文还有一个意思是 “原木”），我们将 “日志”（原木） 组合起来构建起了整套算法；

• 我们把 Paxos 想象成了一个岛，并谋划着怎么逃离这个岛；
  他们曾经想了很多名字，至于最后为什么以 Raft（英文为 “筏” 的意思）作为正式的名字，细节他们也记不清了。我猜他们应该是困在 Paxos 这个孤岛上太久，好不容易收集齐了木头，扎了木筏（raft），准备扬帆起航。

基础

服务器状态