介绍
Raft是一种为了管理日志复制的分布式一致性算法。Raft 出现之前，Paxos 一直是分布式一致性算法的标准。Paxos 难以理解，更难以实现。Raft 的设计目标是简化 Paxos，使得算法既容易理解，也容易实现。Paxos 和 Raft 都是分布式一致性算法，这个过程如同投票选举领袖（Leader），参选者（Candidate）需要说服大多数投票者（Follower）投票给他，一旦选举出领袖，就由领袖发号施令。Paxos 和 Raft 的区别在于选举的具体过程不同。
Raft 可以解决分布式 CAP 理论中的 CP，即 一致性（C：Consistency） 和 分区容忍性（P：Partition Tolerance），并不能解决 可用性（A：Availability） 的问题。
在 Raft 中，任何时刻，每个服务器都处于这三个角色之一 ：
- Leader - 领导者，通常一个系统中是一主（Leader）多从（Follower）。Leader 负责处理所有的客户端请求。
- Follower - 跟随者，不会发送任何请求，只是简单的 响应来自 Leader 或者 Candidate 的请求。
- Candidate - 参选者，选举新 Leader 时的临时角色。
Raft 的基本原理
Raft 将一致性问题分解成了三个子问题：选举 Leader、日志同步、安全性。
Raft 的选举机制
协议为每个节点定义了三个状态：Leader、Candidate、Follower，将时间定义为 Term，每个 Term 有一个 ID。
Raft 使用一种心跳机制来触发 Leader 选举。Leader 需要周期性的向所有 Follower 发送心跳消息，以此维持自己的权威并阻止新 Leader 的产生。每个 Follower 都设置了一个随机的竞选超时时间，一般为 150ms ~ 300ms，如果在竞选超时时间内没有收到 Leader 的心跳消息，就会认为当前 Term 没有可用的 Leader，并发起选举来选出新的 Leader。开始一次选举过程，Follower 先要增加自己的当前 Term 号，并转换为 Candidate。
- Term 类似逻辑时钟，在每个 Term 都会有 Leader 被选举出来。
- Leader 负责处理所有的写请求、发起日志复制、定时心跳，每个 Term 期间最多只能有一个 Leader，可能会存在选举失败的场景，那么这个 Term 内是没有 Leader。
- Follower 处于被动状态，负责处理 Leader 发过来的 RPC 请求，并且做出回应。
- Candidate 是用来选举一个新的 Leader，当 Follower 超时，就会进入 Candidate 状态。
- 初始状态，所有的节点都处于 Follower 状态，节点超时后，递增 current Term 进入 Candidate，该节点发送广播消息 RequestVote RPC 给其他 Follower 请求投票。当收到多数节点的投票后，该节点从 Candidate 进入 Leader。Follower 在收到投票请求后，会首先比较 Term，然后再比较日志 index，如果都满足则更新本地 Current Term 然后回应 RequestVote RPC 为其投票。每个 Term 期间，follower 只能投一次票。
Raft 的日志同步机制
当 Leader 被选举出来后，就可以接受写请求。每个写请求即代表了用户需要复制的指令或 Command。Raft 协议会给写请求包装上 Term 和 Index，由此组成了 Raft 的 Log entry. Leader 把 Log entry append 到日志中，然后给其它的节点发 AppendEntries RPC 请求。当 Leader 确定一个 Log entry 被大多数节点已经写入日志当中，就 apply 这条 Log entry 到状态机中然后返回结果给客户端。
RAft的安全机制
Raft 还增加了一些限制来完善 Raft 算法，以保证安全性：保证了任意 Leader 对于给定的 Term，都拥有了之前 Term 的所有被提交的日志条目。
拥有最新的已提交的日志条目的 Follower 才有资格成为 Leader。
Raft 使用投票的方式来阻止一个 Candidate 赢得选举除非这个 Candidate 包含了所有已经提交的日志条目。Candidate 为了赢得选举必须联系集群中的大部分节点，这意味着每一个已经提交的日志条目在这些服务器节点中肯定存在于至少一个节点上。如果 Candidate 的日志至少和大多数的服务器节点一样新（这个新的定义会在下面讨论），那么他一定持有了所有已经提交的日志条目。
RequestVote RPC 实现了这样的限制：RequestVote RPC 中包含了 Candidate 的日志信息， Follower 会拒绝掉那些日志没有自己新的投票请求。
Raft 成员变更机制
成员变更就意味着集群节点数的增加或减少以及替换。Raft 协议定义时考虑了成员变更的场景，从而避免由于集群变化引起的系统不可用。Raft 是利用上面的 Log Entry 和一致性协议来实现该功能。成员的变更也是由 Leader 发起的，Leader 会在本地生成一个新的 Log entry，同时将 Log entry 推送到其他的 Follower 节点。
Follower 节点收到 Log entry 后更新本地日志，并且应用该 log 中的配置关系。多数节点应用后，Leader 就会提交这条变更 log entry。还要考虑新就配置的更替所带来的问题。更详细的不再赘述。
Raft应用
通过 RAFT 提供的复制状态机，可以解决分布式系统的复制、修复、节点管理等问题。Raft 极大的简化当前分布式系统的设计与实现，让开发者只关注于业务逻辑，将其抽象实现成对应的状态机即可。基于这套框架，可以构建很多分布式应用：
- 分布式锁服务；
- 分布式存储系统，比如分布式消息队列、分布式块系统、分布式文件系统、分布式表格系统等，比如大名鼎鼎的 Redis 就是基于 Raft 实现分布式一致性；
- 高可靠元信息管理，比如各类 Master 模块的 HA
Raft算法实现braft
braft 是基于 brpc 的 Raft 协议工业级 C++ 实现，设计之初就考虑高性能和低延迟。由百度云分布式存储团队打造，在百度内部已经有比较广泛的应用，比如一些关键模块的高可用，以及分布式块存储、分布式文件系统、分布式 NewSQL 系统、分布式文件系统等存储系统。它有如下特点：
- braft 是一个功能完备且经过可靠性验证的 Raft 实现，支持 configuration change、prevote、leader transfer 等特性；
- 高性能也是 braft 追求的核心目标，在实现的很多环节都进行了精细优化，比如无锁任务队列、log 的批量提交和执行以及一些逻辑原地执行等；
- 接口简单容易理解，支持自定义扩展其中的 storage，拥有比较完善的错误回调。用简单的接口实现简单的概念，braft配合brpc即使经验不丰富的工程师也可以很容易的快速构建出健壮的分布式系统。
项目地址如下：
https://github.com/brpc/braft
