分布式一致性算法 - raft 图解

前言

应用服务架构的发展是一个循序渐进的过程，从最开始的单机架构逐步演化到如今的基于微服务的分布式架构。与此同时，应用服务最底层的数据支撑 – 数据存储服务也逐渐由单节点单副本逐步往多节点多副本的方向演进。

多副本节点通过数据复制技术，可以实现分布式容灾，提高服务的可用性，降低单点故障带来的风险；同时多节点部署，还可以很大程度上提高整个系统的吞吐量，降低访问延迟。但是与此同时，基于 CAP 理论，多副本技术也带来了一致性的问题。

raft 算法的诞生正是为了解决在分布式场景之下的数据一致性问题。本文我们将从 raft 的诞生开始，聊一聊其作为集中式架构的领导者选举以及日志复制的具体流程。

raft 的诞生

raft 算法最早出自于 Diego Ongaro 博士的论文《In search of an Understandable Consensus Algorithm》，但是这篇论文比较短小，只是简单介绍了一下原理，对一些细节部分没有提及。更详细的论文是他的《CONSENSUS: BRIDGING THEORY AND PRACTICE》，在这篇论文里面，作者很详细的谈及了 raft 实现上的一些细节部分，这也成为了很多工程实践上的一个重要参考，比如 etcd raft 的实现就基本上与这篇论文一致。

其实早在 raft 算法之前，paxos 算法是当时业界公认的共识算法，并且也有了一些工程上面的实践（例如 Google 的分布式锁系统 Chubby）。但是由于 paxos 算法本身理论过于复杂，并且在工程实践上难度也比较高，这促使 Diego Ongaro 等人急切想要寻找一个简单易懂，并且实现上也比较简单的新算法。于是，基于 Multi-Paxos 算法的思想，raft 算法就此诞生（可以理解为 raft 算法是 paxos 的简化版）。

After struggling with Paxos ourselves, we set out to
find a new consensus algorithm that could provide a better foundation for system building and education. Our approach was unusual in that our primary goal was understandability: could we define a consensus algorithm for
practical systems and describe it in a way that is signifi-
cantly easier to learn than Paxos?

预备知识

在具体学习 raft 算法之前，我们先了解一些下文会用到的相关词汇。

成员身份

raft 算法是一个典型的集中式架构，既然是集中式架构，那么集群中肯定就会存在不同的成员身份，分别具有不同的职责。既然是中央集权，那么就需要一个集权利于一身的领导者，有了领导者，那肯定也需要有被领导者管理的平民即跟随者，同时因为领导者不可能永远不发生意外，那么相对应的，就需要有下一任领导者的候选人。这么类比下来，我们整个 raft 集群的成员身份也就确定了：

• 领导者（Leader）：集群的“最高领导人”，负责处理客户端请求、管理集群中的日志复制，并且还会定时向其他节点发起心跳请求，告诉大家“我还活着，不要发起领导者选举”。一个集群中最多只能有一个领导者。
• 候选者（Candidate）：如果等待领导者心跳超时，跟随者便可以升级为候选者，进入候选者状态之后，就开始向其他节点发起投票请求，如果在选举过程中获得了大多数选票，那么它便晋升为领导者。
• 跟随者（Follower）：正常的时候就做个普普通通的吃瓜群众，默默处理领导者发过来的日志消息，并随时随刻等待领导者心跳请求。但是一旦等待领导者心跳请求超时，就可以推荐自己当候选者。