分布式一致性算法Raft详解

分布式存储系统通常通过维护多个副本来进行fault-tolerance，提高系统的availability，带来的代价就是分布式存储系统的核心问题之一：维护多个副本的一致性。一致性协议就是用来干这事的，即使在部分副本宕机的情况下。Raft是一种较容易理解的一致性协议。一致性协议通常基于replicated state machines，即所有结点都从同一个state出发，都经过同样的一些操作序列，最后到达同样的state。

为了便于理解，Raft大概将整个过程分为三个阶段，leader election，log replication和commit(safety)。

每个server处于三个状态：leader，follower，candidate。正常情况下，所有server中只有一个是leader，其它的都是follower。server之间通过RPC消息通信。follower不会主动发起RPC消息。leader和candidate(选主的时候)会主动发起RPC消息。

Leader election

时间被分为很多连续的随机长度的term(一段时间)，一个term由一个唯一的id标识。每个term一开始就进行leader election：

    1. followers将自己维护的current_term_id加1。

    2. 然后将自己的状态转成candidate。

    3. 发送RequestVoteRPC消息(带上current_term_id) 给 其它所有server

这个过程会有三种结果：

    1. 自己被选成了主。当收到了majority的投票后，状态切成leader，并且定期给其它的所有server发心跳消息(其实是不带log的AppendEntriesRPC)以告诉对方自己是current_term_id所标识的term的leader。每个term最多只有一个leader，term id作为logical clock，在每个RPC消息中都会带上，用于检测过期的消息，比如自己是一个过期的leader(term id更小的leader)。当一个server收到的RPC消息中的rpc_term_id比本地的current_term_id更大时，就更新current_term_id为rpc_term_id，并且如果当前state为leader或者candidate时，将自己的状态切成follower。如果rpc_term_id比本地的current_term_id更小，则拒绝这个RPC消息。

    2. 别人成为了主。如1所述，当candidate在等待投票的过程中，收到了大于或者等于本地的current_term_id的声明对方是leader的AppendEntriesRPC时，则将自己的state切成follower，并且更新本地的current_term_id。

    3. 没有选出主。当投票被瓜分，没有任何一个candidate收到了majority的vote时，没有leader被选出。这种情况下，每个candidate等待的投票的过程就超时了，接着candidates都会将本地的current_term_id再加1，发起RequestVoteRPC进行新一轮的leader election。

投票策略：

每个server只会给每个term投一票，具体的是否同意和后续的Safety有关。

 

当投票被瓜分后，所有的candidate同时超时，然后有可能进入新一轮的票数被瓜分，为了避免这个问题，Raft采用一种很简单的方法：每个candidate的election timeout从150ms-300ms之间随机取，那么第一个超时的candidate就可以发起新一轮的leader election，带着最大的term_id给其它所有server发送RequestVoteRPC消息，从而自己成为leader，然后给他们发送心跳消息以告诉他们自己是主。

Log Replication