Raft共识算法入门教程


1 分布式基础概念

    1.1  数据副本与一致性问题

    1.2  分布式系统的进化史

    1.3  全面解读CAP定理

    1.4  CAP理论为什么不能同时满足?

    1.5  BASE原则

2 全面解读Raft共识算法

    2.1  全面解读Raft共识算法

    2.2  Raft日志的作用

    2.3  Raft日志复制

    2.4  Raft共识算法是否属于二阶段提交?

    2.5  Raft算法中的三种超时时间

    2.6  Raft算法动图展示

3 实战操练Raft共识算法

全面解读CAP定理

2000年的时候,加州大学伯克利分校的光头教授Eric Brewer提出了CAP猜想:CAP永远不可能同时满足,提高其中任意两者的同时,必然要牺牲第三者。这个定理告诉大家,不要再浪费时间去研究如何兼顾了,因为这根本就是不可能的,只能根据具体应用,来决定如何在三者之间进行取舍。

后来,CAP猜想由麻省理工学院的两位科学家证明。CAP猜想的证明相对比较简单:采用反证法,如果三者可同时满足,则因为允许P的存在,一定存在节点之间的丢包,如此则不能保证C,证明简洁而严谨。从此,CAP理论正式在学术上成为了分布式计算领域的公认定理,并深深的影响了分布式计算的发展。

但是,在CAP理论提出十二年之后,Eric Brewer教授又出来辟谣:“三选二”的公式一直存在着误导性,它会过分简单化各性质之间的相互关系。这三种性质都可以在某种程度上进行衡量,并不是非黑即白的有或无。可用性显然是在0%到100%之间连续变化的,一致性分很多级别,连分区也可以细分为不同含义,如系统内的不同部分对于是否存在分区可以有不一样的认知。所以,一致性和可用性并不是水火不容,非此即彼的。

《全面解读CAP定理》
第一节:什么是 CAP 定理?
第二节:什么是分区?什么是分区容错性?
第三节:为什么只能 3 选 2?
第四节:真实的CP场景:GitHub事故:断网43秒,瘫痪24小时
第五节:CAP理论的新理解

第一节:什么是 CAP 定理?

2000 年的时候,Eric Brewer 教授提出了CAP猜想,2年后,被 Seth Gilbert和 Nancy Lynch从理论上证明了猜想的可能性,从此,CAP定理正式在学术上成为了分布式计算领域的公认定理,并深深的影响了分布式计算的发展。

CAP定理,又称CAP原则,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 定理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。

CAP定理的精髓就是要么AP,要么CP,要么AC,但是不存在CAP。因此在进行分布式架构设计时,必须做出取舍。而由于网络硬件肯定会出现延迟丢包等问题,所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有任何分布式系统能同时保证这三点。

选项 描述
C(Consistence) 一致性,指数据在多个副本之间能够保持一致的特性(严格的一致性)。
A(Availability) 可用性,指系统提供的服务必须一直处于可用的状态,每次请求都能获取到正确的响应,但是不保证获取的数据为最新数据。
P(Partition tolerance) 分区容错性,分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障。

第二节:什么是分区?什么是分区容错性?

在分布式系统中,不同的节点分布在不同的子网络中,由于一些特殊的原因,这些子节点之间出现了网络不通的状态,但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域,这就是分区。

分区容错性,说白了,就是指是否允许出现分区。一旦出现分区,则各个分区之间的数据副本无法达到一致性。

第三节:为什么只能 3 选 2?

假设有一个系统如下:

整个系统由两个节点配合组成,节点之间通过网络通信,当节点 A 进行更新数据库操作的时候,需要同时更新节点 B 的数据库(满足一致性)。这个系统怎么满足 CAP 呢?

C:当节点A更新的时候,节点B也要更新;
A:必须保证两个节点都是可用的;
P:当节点 A,B 出现了网络分区,必须保证对外可用。

可见,三者根本无法同时满足,只要出现了网络分区,一致性就无法满足,因为节点 A 根本连接不上节点 B。如果强行满足一致性,就必须停止服务运行,从而放弃可用性 。所以,最多满足两个条件,并有下面几种情况:

组 合 分析
CA 满足一致性和可用,放弃分区容错。此时已经变成了单机系统,谈不上是分布式系统了。对于分布式系统而言,分区容错性是一个最基本的要求,因为分布式系统中的组件必然需要部署到不通的节点,必然会出现子网络,在分布式系统中,网络问题是必定会出现的异常。因此分布式系统只能在C(一致性)和A(可用性)之间进行权衡。

放弃分区容错性,比较简单的方式就是把所有的数据都放在一个分布式节点上。那不就又成为了单机应用了吗?
CP 满足一致性和分区容错,也就是说,要放弃可用。当系统被分区,为了保证一致性,必须放弃可用性,让服务停用。

放弃可用性,一旦出现网络故障,受到影响的服务需要再等待一定时间,因为系统处于不可用的状态。
AP 满足可用性和分区容错,当出现分区,同时为了保证可用性,必须让节点继续对外服务,这样必然导致失去一致性。

放弃一致性,这里所指的一致性是强一致性,但是确保最终一致性。是很多分布式系统的选择。

第四节:真实的CP场景:GitHub事故:断网43秒,瘫痪24小时

2018年10月31日,GitHub技术负责人Jason Warner的一篇技术深度解析稿成为IT圈爆款。文中,Jason坦诚地对外讲述了10月21日100G光缆设备故障后,Github服务降级的应急过程以及反思总结。

从Jason Warner的文章中不难看出,造成断网43秒瘫痪24小时的罪魁祸首是数据库。由于部署在两个数据中心的数据库集群没有实时同步。意外发生时,Github的工程师担心数据丢失,不敢快速将主数据库安全切换到东海岸的备份数据中心。

程序员们在GitHub这篇“忏悔录”下面留言,表达对数据库集群的“哀悼”。但更多IT从业者关心的问题是,如何避免这样的灾难事件降临到自己的公司,自己维护的系统。

分布式数据库专家认为,此次Github事件是典型的城市级故障。如果系统采用的是高可用的三地五中心解决方案,就可以自如应对。

原来,Github类似银行采用的传统数据库两地三中心模式,即“主库(主机房)+同城热备库(同城热备机房)+异地灾备库(异地灾备机房)”。这种方式下通常只有主机房的服务器能提供写服务。如果主城市出现城市级故障,灾备城市的数据库虽然可以工作,但由于没有同步的最新数据,因此灾备库的数据是有损的。Github表示,为了保证数据完整性,他们不得不牺牲恢复时间。

其实,这个问题采用三地五中心方案可以更好的应对。城市故障时,只要活着的两个城市的三个机房两两之间能够通信,就可以正常服务,也不会有任何的数据损失。

第五节:CAP理论的新理解

有读者存在疑问:根据CAP理论,在分布式系统中一致性和可用性只能选一个,那Paxos、Raft等共识算法是如何做到在保证一定的可用性的同时,对外提供强一致性呢?

这个疑问的根源在于没有明白CAP理论后期的发展。在CAP理论提出十二年之后,其作者又出来辟谣:“三选二”的公式一直存在着误导性,它会过分简单化各性质之间的相互关系。

首先,由于分区很少发生,那么在系统不存在分区的情况下没什么理由牺牲C或A。

其次,C与A之间的取舍可以在同一系统内以非常细小的粒度反复发生,而每一次的决策可能因为具体的操作,乃至因为牵涉到特定的数据或用户而有所不同。

最后,这三种性质都可以在程度上衡量,并不是非黑即白的有或无。可用性显然是在0%到100%之间连续变化的,一致性分很多级别,连分区也可以细分为不同含义,如系统内的不同部分对于是否存在分区可以有不一样的认知。所以,一致性和可用性并不是水火不容,非此即彼的。