剖析Raft

Paper

In Search of an Understandable Consensus Algorithm

Raft more understandable than Paxos and also provides a better foundation for building practical systems

Novel features

  • Strong leader: Raft uses a stronger form of leadership than other consensus algorithms. For example, log entries only flow from the leader to other servers. This simplifies the management of the replicated log and makes Raft easier to understand. 只有leader对外提供服务,log只能从leader流向其他角色。
  • Leader election: Raft uses randomized timers to elect leaders. This adds only a small amount of mechanism to the heartbeats already required for any consensus algorithm, while resolving conflicts simply and rapidly. 这个特点很有意思,每次选举都增加随机时间,防止多个候选者同时发起选举,分割选票,导致无法正常结束选举。
  • Membership changes: Raft’s mechanism for changing the set of servers in the cluster uses a new joint consensus approach where the majorities of two different configurations overlap during transitions. This allows the cluster to continue operating normally during configuration changes. 集群配置改变时,仍然可以提供服务。

Replicated state machines

副本状态机常用于解决分布式系统中的容错问题,比如管理选举leader以及存储配置信息防止leader雪崩。

  • consensus module

接收来自客户端的命令,保存至log;与其他的一致性模块通信保证log的正确性

  • log

每个服务都会保存一份相同的操作顺序日志,这样每个服务都会执行相同的命令,产生相同的结果。

  • state machine

根据log,计算状态

Consensus problem

Raft通过leader解决一致性问题,leader全权管理log副本。leader接收客户端请求,然后复制给其他服务,最后通知其他服务提交,改变各自的状态机。

提高理解性(paxos难以理解),Raft将一致性问题分解成三个子问题:

Basics

Raft集群有三种角色:leader(领导者), follower(追随者), or candidate(候选者)。一般情况下,集群中只有一个leader以及若干个follower。

角色

  • leader:接收客户端请求(如果请求发给其他服务,则转发给leader);管理log副本
  • follower:被动接收leader和candidate的请求
  • candidate:用于选举新的leader
Figure 4 - states and transitions

term

Raft将时间切分成任意长度的term。

  • term用连续的整数进行编号。

  • 每个term开始前都有一次选举,如果一个candidate赢得选举,就将成为leader。

  • 每个服务都保存自己的当前term编号(CTN),服务通信时交换CTN

    • follower发现自己过期,就会更新自己的CTN
    • leader/候选人发现自己过期,就会立马变成follower
    • 服务拒绝过期请求
Figure 5 - terms

RPC

  • RequestVote:由候选人在选举阶段发起
  • AppendEntries:由leader发起,复制log条目以及提供心跳

Leader election

服务启动的时候都是follower,如果follower能够从leader/candidate定期收到合法的RPC,就会一直保持状态。如果follower超过一段时间没有收到RPC(超时),就会开始选举流程。

  1. follower增长自己的CTN,并且转变成candidate
  2. 对集群中其他服务发起RequestVote RPC,争取选票,直到发生以下情况:
    • win(在一个term中,收到一半以上选票,变成leader,发送AppendEntries RPC)
    • other wins(接收其他服务的AppendEntries RPC,如果RPC中的CTN大于等于自己的CTN,就变成follower,否则拒绝,继续candidate)
    • time out without winner(随机timeout + 重试)

Noted:

针对timeout,分割选票无法选举问题,Raft采用随机选举超时解决。

Log replication

  1. leader接收来自客户端的请求
  2. 将命令作为新的entry添加到log
  3. 发起AppendEntries RPC将entry发送给其他服务(RPC失败,leader一直retry,直到所有RPC成功)
  4. 等待安全复制(大多数服务成功添加entry到log,称为提交,提交之后更新本地状态机)
  5. leader执行命令更新状态机,并且返回结果给客户端

Safety

你可能感兴趣的:(剖析Raft)