分布式存储系统通常通过维护多个副本来进行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