如何基于Raft绕过​分布式算法一致性的那些痛?

主题大纲:

1、点拨分布式系统和Raft算法要点

2、深入剖析Raft实现原理

3、干货:基于Raft的分布式系统实战经验

 

最近我们开源了一个运行在Mesos上的分布式调度器swan(https://github.com/Dataman-Cloud/swan),在研发过程中发现由于目前的分布式存储并不能满足我们所有需求,所以自己动手将Raft嵌入到swan中,以保证多节点之间的数据同步。在这个过程中我们积累了一些Raft相关的经验和教训,在这里与大家分享。

 

一、关于分布式系统

 

分布式系统具有可扩展性和高可用性强等特点,被越来越多的应用到各个应用场景中,但是在分布式系统中,各个服务器之间数据的一致性一直是无法绕过的难题。

 

所谓一致性,它是指分布式系统中,多个服务器的状态达成一致。但由于各种意外可能,某个服务器发生崩溃或变得不可靠,它就不能与其他服务器达成一致性状态。这样就需要一种Consensus协议,这个协议是为了确保容错性,也就是即使系统中有一两个服务器宕机,也不会影响其他的服务器正常提供服务。

 

在过去Paxos一直是分布式协议的标准,但是Paxos难于理解,更难以实现。较于Paxos,来自Stanford的新的分布式协议Raft更好用一些,它是一个为真实世界应用建立的协议,主要注重协议的可理解性和落地。

 

二、Raft如何在多个服务器之间实现数据的一致性

 

下面简单介绍一下Raft如何在多个服务器之间保证数据的一致性。为了达成一致性这个目标,首先Raft需要进行选举,在Raft中,任何时候一个服务器可以扮演下面角色之一:

 

  1. Leader:处理所有客户端交互,日志复制等,一般一次只有一个Leader;

  2. Follower:类似选民,完全被动;

  3. Candidate候选人:类似Proposer律师,可以被选为一个新的领导人。参选者需要说服大多数选民(服务器)投票给他。

 

选举的过程大概分为以下几步:

  • 任何一个服务器都可以成为一个候选者Candidate,它向其他服务器Follower发出要求选举自己的请求;

  • 其他服务器同意了,发出OK。注意如果在这个过程中,有一个Follower宕机,没有收到请求选举的要求,候选者可以自己选自己,只要达到N/2 + 1 的大多数票,候选人还是可以成为Leader的;