Raft协议详解前言:子问题分解

Posted 捕风的树叶

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Raft协议详解前言:子问题分解相关的知识,希望对你有一定的参考价值。

     分布式一致性,一直是分布式系统中非常重要的部分。在多机集群中,如何保证不同服务器上同一副本的数据是一致正确的,如何保证在故障频发的集群中数据能够安全保存等问题,都需要靠分布式一致性来解决。在对分布式一致性算法进行设计的时候,存在如下几点需要注意的地方:


1. 算法的正确性保证,不论在丢包、宕机、延迟等情况,都不能返回错误的结果

2. 只要大部分机器可以用,那么算法就可以正常运行

3. 不依靠时序来保证一致性

4. 收敛速度应该比较快,能尽快在大部分上机器完成,少部分没有完成的不影响算法使用


> (我知道上面这几句有点不是很好理解,后面我尽量只讲好理解的)


    很多一致性算法来进行保证分布式一致性问题。比如很出名的Paxos协议,Google的分布式锁Chubby就是基于Paxos实现的,还有Zookeeper等。但是Paxos的问题在于比较难以理解,实现起来非常困难。即使基于Paxos的Zookeeper和Chubby,其实现和Paxos仍然有一定的出入。这就导致了一个非常严重的问题,就是你的实现没有按照完整的Paxos实现的话,那么你的方法就没有被理论所很好的支撑,可能你的实现就会出现很多问题。


    那么,基于这个问题呢,斯坦福的大佬们就提出了Raft算法。这个算法和Paxos其实在功能上,和性能上差不多。好处就是便于理解以及工程实现。当前也有挺多公司采用Raft算法,但是其实这个算法在实际的应用场景下,还存在一定的问题。比如阿里也在使用Gossiping算法。这里我们就不在多加讨论。我们这个文章系列还是对Raft进行学习。文章内容基于该算法发表的论文,小伙伴们也可以去读一下论文原文。



Raft


    上面我们讲到,Raft的主要贡献就是设计一个简单易于理解和实现的算法。那么他如何达到这个目的的呢?从两方面入手的,首先是将复杂的问题进行分解,分成了几个小的问题;第二是减少系统中的变量状态,使问题尽量简单一点。这其实也能对我们以后进行系统设计提供借鉴。那么接下来我们开始详细介绍Raft。


    刚才讲到Raft进行了问题分解,分成了四个小问题,小问题分别是:如何选主(leader election)、如何进行日志复制(log replication)、安全性保证(safety)以及维护成员变化(membership changes)。可能小伙伴还不太知道为啥要分为这几个问题,我这里先讲一下。要讲这个,咱们首先得看一个图。


                     图1 Raft算法组件组成图


    我们看一下Raft的组成里面有哪些东西。上图有三台服务器(Server),假设是一个集群(集群我们要求是奇数个)。每台服务器上分别运行着Raft算法。其中有三个基本组成,分布是一致性模块(Consensus Module)、日志(log)、状态机(State Machine)。下面先简单大概说一下集群是如何运行的,咱们先有个大概印象。


    首先第一个问题是,这几台机器中都有数据,我们的目标是保证里面保存的数据都是一样的,那假如其中有一台数据不一样,那么到底应该以谁的为准?这就是选主问题,在Raft里面,有一个Leader的服务器,一切以Leader的数据为准。那么谁当Leader呢?那就靠Raft中的选主算法(Leader election)决定。


    第二,为了保证客户端对数据的每一个操作,都能真正地保证操作成功(或者告知不能操作成功),Raft依靠的还是两阶段提交方法。学过两阶段提交协议的同学可能会比较熟悉。其实很简单。就像很多人去交电费。由于交电费的地方比较落后,因此那边的工作人员对于来排队缴费的人,操作流程是:首先对每一个来交电费的人进行登记,登记你要买多少电费,先记在本子上。然后到了晚上再统一将登记本上登记的电划给用户。在本文场景中,Raft首先将用户对数据的操作,保存在Log中。比如“将X赋值为3”这个操作先保存起来,然后在统一将这个操作真正去运行,持久化在State Machine中。因此日志是对于数据一致的关键保证。因此我们做数据副本,其实就是做日志副本,需要考虑日志怎么样才能安全复制到其他机器上去。这就是日志复制(log replication)。


    而要对这一系列流程进行安全性保障,就需要一致性模块进行算法上的控制。安全性保证(safety)。


    当然,由于集群一般会不断变化,比如机器坏了,比如机器配置需要升级等等,导致集群的数量、配置等会发生变化。那么如何保证在集群变化的时候,也能使得一致性能够得到保证呢?那么就需要进行维护成员变化(membership changes)


    上面就是几个小问题之间的联系。只要把上面几个问题搞清楚了,那么Raft也就搞清楚了。我们后面就分别对这几个问题进行详细说明。

以上是关于Raft协议详解前言:子问题分解的主要内容,如果未能解决你的问题,请参考以下文章

Raft协议详解-leader发送心跳代码go

区块链灵魂之:Raft算法详解!

Raft:区块链灵魂算法详解

Raft协议

Raft算法

Raft理论知识详解