作者介绍
戌米(笔名) ， 金融级行业核心业务分布式数据库DBA ， 负责大型金融级系统的国产化数据库改造工作 ， 爱好分布式数据库底层技术 。
大家平时看分布式领域的一些资料 ， 和了解原生分布式数据库TiDB、OceanBase时 ， 常常会听到一个“共识算法”的概念 ， 两大代表性的共识算法Paxos和Raft更是常常出现在数据库文档、技术论坛等地方 。 但一去了解 ， 往往会发现论文原文或相关的翻译极其复杂 ， 相当难以理解 。
可见共识算法的难度有多高 。 为了让大家能不费那么大劲地弄懂共识算法的基本理念 ， 笔者把Raft算法论文《In Search of an understandable Consensus Algorithm》 ， 用更通俗的语言组织了一下 ， 只要你拿出10分钟来看完 ， 相信你也会对共识算法有一个基本的理解 。
后文将先简单介绍一下共识算法的概念、作用 ， 然后分模块开展Raft的讲解 。
一、共识算法概述
1、什么是共识算法？
要了解共识算法 ， 首先我们要区分一致性问题（consistency）和共识问题（consensus） 。
consistency就是大家比较熟悉的事务ACID特性中的C ， 指的是事务可以从一个满足完整性约束的状态转换到另一个完整性约束的状态 ， 是事务要满足的一种特性 。
而consensus指的是分布式系统中的节点如何就某些东西达成一致 ， 可能是一个值、一系列动作 ， 也可能是一个决定 。
很多人往往会把consensus和consistency搞混 ， 从而把共识算法称作“一致性算法” 。 严格来讲 ， 这种叫法也不能算错 ， 但中文“一致性”的含义和使用实在太广 ， 很容易引发歧义 。 所以我在本文中一并把以Paxos和Raft为代表的算法称作“共识算法” ， 也提倡大家都使用这种称呼 。
2、共识算法可以用来做什么？
我们知道在一个分布式系统中 ， 通常会使用增加副本的方式来保证系统的高可用 。 但容易忽略的一点是 ， 怎样才能确保增加的副本可以发挥出作用？或者说 ， 主备切换时 ， 选择哪台机器来成为主？（备机如何判断主机宕了？每台备机都想成为主机怎么办？每台备机都不想成为主机怎么办？）
一个比较直接的思路是 ， 由客户端或另一类节点维持所有数据节点的信息 ， 当发现主不可用时 ， 它们从清单中选择另一台机器做主 。
但这就出现了另一个问题 ， 这类选主的节点的高可用 ， 怎么保证？
显然 ， 如果对管理数据节点的节点再设管理节点 ， 那么这个问题还会嵌套下去 ， 没有得到解决 。 要根本上解决这个问题 ， 我们就需要让节点可以在不依赖外界因素的情况下自动完成主节点的选举 ， 这就是共识算法的作用 。
目前主要有两种共识算法：Paxos和Raft 。
在具体介绍两种共识算法之前 ， 我们先了解一下复制状态机（Replicated State Machine）的概念 。

文章图片

复制状态机的核心理念是：相同的初始状态+相同的输入=相同的结束状态 。
简单一点描述就是：多个节点上 ， 从相同的初始状态开始 ， 执行相同的一串命令 ， 产生相同的最终状态 。
可以说 ， 我们使用共识算法 ， 就是为了实现复制状态机 。 一个分布式场景下的各节点间 ， 就是通过共识算法来保证命令序列的一致 ， 从而始终保持它们的状态一致 ， 从而实现高可用的 。 （投票选主是一种特殊的命令）
二、Raft算法
相比于Paxos ， Raft最大的特性就是易于理解（Understandable） 。 为了达到这个目标 ， Raft主要做了两方面的事情：