你是否真的理解分布式中的一致性与共识

为了解决单节点存储瓶颈、访问耗时、单点故障等问题,通常将数据存储到多个节点,称之为分布式技术。分布式不仅可以将负载分散、还可以避免单点故障、降低延时。然而,分布式也引入了额外的问题:网络中的数据可能会丢失、重新排序、重新推送或任意延迟;不同节点的时钟漂移;节点的暂停或崩溃。

解决分布式问题的最好方式是找到一些通用的抽象,实现一次,然后依赖这些保证。就像事务一样,通过使用事务,应用程序不用去关心多个操作出现部分成功部分失败的问题「原子性 」、数据写入约束问题「一致性 」、多个客户端并发访问题「隔离性 」、存入的数据丢失问题「持久性」。即使数据执行期间发生了崩溃、冲突和磁盘故障,事务隐藏了这些问题,应用程序不用关心。

分布式系统中最重要的抽象就是共识:就是让所有节点对某一件事达成一致。一旦达成共识,应用程序就可以忽略许多问题。例如:在单主复制的场景中,如果主库宕机,剩余的节点可以使用共识算法来选举新的领导者。从而避免同时有两个节点都认为自己是领导者,造成的脑裂问题。在分区数据库中,为了保证事务的原子性,则需要涉及一个事务的多个节点就事务的提交而达成共识。

一致性与共识的关系

在开始讨论共识算法之前,不得不讨论一下一致性的问题。上面说到,共识就是让所有节点对某一件事达成一致 。而一致性是指多个节点,给定一系列操作,在约定协议的保障下,使它们对外界呈现的状态是一致的。一致性描述的是结果状态,即多个节点对外界呈现的状态;共识是一种机制/算法,描述的是过程,即如何实现多个节点的一致性。

一致性

一致性是指多个节点,给定一系列操作,在预定协议的保障下,对外界呈现的状态。在实际实现中,会对一致性进行分类。按照系统的容忍度,可以将一致性分为:最终一致性、因果一致性、顺序一致性、线性一致性「强一致性」。其实和事务的隔离级别一样,均是出于对性能的考虑,分为不同级别,从而提升性能。

最终一致性

最终一致性,也叫弱一致性。分布式中的各个节点,在停止操作的一段时间后,各个节点的数据是完全相同的。简单来说,就是一段时间后,节点的数据会达到最终一致的状态。

大多数异步复制的数据库只能保证最终一致性。如下图所示,用户更新头像之后,需要过一段时间,两个从库才能达到和主库一致的状状态。

最终一致性的实现方式比较简单。例如在 msyql 中,从库往往选择监听主库的 binlog,对数据回放,从而保证最终一致性。最终一致性带来的问题是,不同节点之间达成完全一致状态的时间是不能确定的,可能是几毫秒,也可能是分钟,这往往会导致写入的数据不能被及时查到。

单调读

单调读是一个比最终一致性更强的保证。即保证用户的多次读取,不会发生读取新值之后又读到旧值的情况

如下图所示,在满足最终一致性的前提下,仍然会有业务异常。即 user:2345 看到 user 1234 回复的消息。但是再次刷新却看不到了回复的消息。常见的解决方案就是保证同一个 user 读取的节点是固定的。

因果一致性

因果一致性是一个比单调读更强的保证。对于一些列按照某个顺序的写请求,那么读取这些内容时也会按照写入的顺序呈现。不会出现后写入的数据先被读到的现象。

如下图所示,在一个分区的场景中。由于不同节点之间的网络延时不固定,导致 observer 看到的消息是先有 Cake 的回复,再有 Poons 的问题。从而造成业务异常。常见的方案是将因果关系的写入路由到同一个分区,从而保证因果顺序。

顺序一致性

顺序一致性是比因果一致性更强的保证 ,即执行结果符合每个用户按顺序执行的结果。

为了方便介绍,采用用户视角,而不是数据库视角。每一个柱都是由数据库发出的请求,柱头是请求的发送时刻,柱尾是客户端收到响应的时刻。因为客户端和数据之间通信存在网络延时,并不知道数据库处理请求的具体时间。在顺序一致性的保证下, A 和 B 会收到什么响应:

  • A 的第一次读操作,完成于写操作之前,返回 0。
  • A 的最后一个读操作,完成于写之后,返回 1。因为写操作一定在收到响应之后处理完成,而读操作发生在响应之后,因此必须看到新写入的值。
  • 在写操作时间上重叠的任何操作「A 的第二次读, B 的两次读」,可能会返回 0 或 1。这些操作是并发的,并不知道数据库执行的顺序。即可能出现 A 第二次读到 1,B 第二次读到 0 的现象。

线性一致性

线性一致性,是最强的保证。它使多个节点看起来好像只有一个节点,而且所有操作都是原子的。

在上面顺序一致性的例子中,由于在写操作时间上重叠,A 的第二次读可能返回 1, B 的第二次读可能返回 0。它违背了线性一致性的约束,即永远读到数据的最新值「由于 A 已经读到了 1,意味后续系统应该返回最新值 1」。如下图所示,A 读到 1 之后的后续所有读取都应该为 1。从而保证数据永远读取到的是最新值。

CAP 定理

线性一致性看起来是那么的完美,应用程序可以像使用单体数据库一样使用分布式数据库。但带来的问题是严重的性能开销。

在分布式系统中,通常认为系统无法同时满足 CAP 特性,也叫 CAP 定理:

  • Consistency「一致性」:这里指的是强一致性。即分布式系统对外表现好像只有一个副本一样,写入的数据可以立即读到。
  • Availability「可用性」:对于每次请求,系统都能在一定时间内给予响应。响应的不一定是最新的数据。
  • Partition tolerance「分区容错性」: 系统在网络分区(即网络通信的中断)发生时,仍然能够保持系统的正常运行。

在 CAP 定理中,分布式系统无法满足这三种特性。意味着要么牺牲一致性,搭建一个 AP 系统;要么牺牲可用性,搭建 CP 系统。

如下图所示,是一个具有两个数据中心的架构。考虑一种情况,每个数据中心可以正常提供服务,只是数据中心之间的网络发生中断。

  • 为了保证一致性,请求到从库的客户端将不可用。需要等待网络恢复时,数据中心才能提供服务。即牺牲了可用性。
  • 为了保证请求到从库的客户端能够正常响应「可用性」,则需要牺牲强一致性,即写入主库的数据不能被立马读到。网络恢复后,两个数据中心会达到最终一致。

遗憾的是,在分布式场景下,网络故障肯定是存在的,这是受到物理规律的限制。也就意味着,在分布式系统中,一定要满足分区容错性。在此前提下,可以考虑满足一致性还是可用性。CAP 定理的要求似乎太过于严格。它只考虑了强一致性和网络分区,对于最终一致性和网络延迟、节点故障并没有进行讨论。CAP 定理似乎对于设计并实现一个分布式系统并没有太大的参考意义。

出于性能的考虑,分布式系统在设计时通常满足最终一致性,从而满足一定程度的可用性。或者牺牲一定程度的可用性「可能在一段时间内不用,部分写入请求失败」,从而满足强一致性。

分布式事务与共识

一致性是分布式系统对外界呈现的状态。按照 CAP 定义,网络故障是不可避免的,意味着只能在一致性和可用性之间作出取舍。共识是分布式系统中就某一事件达成一致的过程。例如:对于下面的两种场景均需要分布式中各个节点达成共识,从而保证一致性。

  • 原子提交

在线性一致性的保证下,分布式系统表现的好像只有一个副本。这就意味着,在分区场景下,如果一个事务包含多个分区,仍需要保证原子性。分布式系统的各个节点需要对事务的提交达成一致,要么全部提交,要么全部回滚,从而保证事务操作的原子性。

  • 领导者选举

在单主复制的场景下,领导者发生故障。为了保证系统的可用性,需要从从库中选择一个节点作为领导者。如果从库不能就谁成为领导者而达成共识,就会导致脑裂。即存在多个主库,造成数据异常。

共识的不可能性

Fischer,Lynch 和 Paterson 证明,如果存在节点可能崩溃的风险,则不存在总是能够达成共识的算法。在分布式系统中,我们必须假设节点可能会崩溃,所以可靠的共识是不可能的。然而这里我们正在讨论达成共识的算法,到底是怎么回事?

答案是 FLP 是一种限制性很强的模型,它假定确定性算法不能使用任何时钟或超时。如果允许算法使用超时或其他方法来识别可疑的崩溃节点(即使怀疑有时是错误的),则共识变为一个可解的问题。即使仅仅允许算法使用随机数,也足以绕过这个不可能的结果。

因此,虽然 FLP 是关于共识不可能性的重要理论结果,但现实中的分布式系统通常是可以达成共识的。

两阶段提交

两阶段提交是保证分布式中各个节点原子事务提交的一个算法,即保证所有节点提交或中止。下图说明是两阶段提交的流程,整体分为两个阶段。所以叫两阶段提交。

在两阶段提交中,需要一个协调者用于协调各个节点进行事务提交/中止。这个协调者可以是应用程序的一个进程,也可以单独运行在服务器上。其详细流程如下:

  1. 提交请求阶段

    1. 协调者向所有的参与者发送事务内容,并询问是否可以提交请求,等待响应
    2. 参与者执行事务的内容,记录 undo 日志「用于回滚」、redo 日志「用于回放」,但不会真正的提交
    3. 参与者向协调者返回事务是否可以提交。可以提交:yes,不可以提交:no。可以提交意味着无论发生什么情况「磁盘容量不足、不满足约束等」参与者均能保证事务的正常提交。
  2. 提交执行阶段

    1. 当协调者收到所有的参与者发来的信息后,会根据结果来确定事务是提交还是终止。并将结果写入磁盘,即使协调者发送崩溃,故障恢复后仍知道决策结果。这被称为提交点
    2. 协调者向各个节点发送提交/中止请求,各个节点执行对应的操作。
    3. 协调者收到各个节点的 ack 信息,事务执行完毕。

上面整个流程是如何保证事务的原子性呢?当各个节点确认事务可以提交之后,意味着稍后它肯定可以提交。协调者一旦作出决定后,这一决定是不可撤销的。这些承诺保证了分布式事务的原子性「在单机数据库中,其实是把写入日志和事务提交合为一体」。

在两阶段提交中,事务的原子性完全依赖协调者。事务提交请求阶段如果有节点超时或失败,协调者会让各个节点中止事务。在事务提交执行,如果有请求失败,协调者会无条件重试。

如下图所示,如果协调者在给 db2 发送 commit 之后发生故障。此时,db1 并不知道需要提交和中止。为了保证一致性,则需要 db1 阻塞,等待协调者恢复,确认提交还是终止。

三阶段提交

两阶段提交的最大问题在于事务的原子执行其实是依赖协调者完成。如果协调者发生故障,其他阶段会被阻塞「该事务中的数据会被加锁阻塞」,直到协调者恢复。

为了解决阻塞问题,有人提出了三阶段提交,非阻塞提交。三阶段其实是对两阶段的补充。与两阶段相比,三阶段加入了一个 canCommit 阶段,判断自己是否可以执行事务,这时并不会写入 redo log 和 undo log。

三阶段如何解决协调者故障而导致的阻塞问题呢?在三阶段协议中,引入超时机制。即进入第三阶段后,如果等待不到协调者的响应则直接 commit。为什么两阶段提交不能使用超时机制?在两阶段提交中,参与者不知道协调者的决策结果,则只能阻塞等待。而在三阶段中,参与者进入了第二阶段,意味着所有的节点均可以提交。超时之后可以直接提交。

三阶段协议并不是完美的,在分布式场景下,并没有绝对的故障检测机制。常见超时判断其实是不准确的,网络拥堵,时钟漂移,协调者 gc 均会导致误判为故障。出于这个原因,两阶段提交仍然是一个常用的协议,尽管大家知道协调者的故障会导致其阻塞。

XA 事务

XA「eXtended Architecture 的缩写」是跨异构技术的两阶段提交标准。所谓异构,可以简单理解为两种不同的数据库。例如:一个事务涉及 Mysql、PG 等多个数据库。为了保证数据事务的一致性则需要参与事务的数据库均实现 XA 的标准。

XA 事务本质上是一个两阶段提交标准的实现。应用程序通过调用实现 XA 的数据库驱动与数据库进行通信,从而实现分布式事务。通常情况下会有一个 sdk 实现 XA 定义的接口,应用程序通过 sdk 启动一个线程「协调者」进行分布式事务。它会将决策结果写入日志,并向参与者发送提交或终止消息。

由于协调者是寄生在应用程序中,如果应用程序发生崩溃,协调者将会死亡。任何等待消息的参与者将会阻塞,直到协调者重启加载日志信息,并下发消息到参与者。

共识算法

使用分布式事务可以保证多个节点对事务的一致性保证。然而在具体实现的时候强依赖协调者,如果协调者发生故障,则无法保证事务的一致性。在单主复制的架构中,所有的事务都是在一个节点上,可以保证事务的原子性。然后,问题在于主节点发生故障时,如何选择一个节点作为新的主库。

最著名的容错共识算法是视图戳复制,Paxos,Raft 以及 Zab。这些算法之间有不少相似之处,但它们并不相同。这里并不作过多讨论,除非你准备自己实现一个共识系统

总结

本文主要介绍了分布式场景下的一致性和共识。按照一致性的强弱,可以分为:线性一致性、顺序一致性、因果一致性、单调读、最终一致性。

一致性是分布式系统对外展示的一致的状态。而实现这种状态的方法我们称之为共识。在分布式场景下,常见的算法有两阶段提交、三阶段提交、XA 事务;还有一类算法是采用的主从方式,核心就是故障情况下如何选主,这里算法包括 Paxos、Raft、Zab 等。

相关推荐
初晴~2 分钟前
【Redis分布式锁】高并发场景下秒杀业务的实现思路(集群模式)
java·数据库·redis·分布式·后端·spring·
盖世英雄酱581367 分钟前
InnoDB 的页分裂和页合并
数据库·后端
小_太_阳28 分钟前
Scala_【2】变量和数据类型
开发语言·后端·scala·intellij-idea
直裾30 分钟前
scala借阅图书保存记录(三)
开发语言·后端·scala
星就前端叭1 小时前
【开源】一款基于Vue3 + WebRTC + Node + SRS + FFmpeg搭建的直播间项目
前端·后端·开源·webrtc
YashanDB2 小时前
【YashanDB知识库】XMLAGG方法的兼容
数据库·yashandb·崖山数据库
独行soc2 小时前
#渗透测试#漏洞挖掘#红蓝攻防#护网#sql注入介绍11基于XML的SQL注入(XML-Based SQL Injection)
数据库·安全·web安全·漏洞挖掘·sql注入·hw·xml注入
小林coding2 小时前
阿里云 Java 后端一面,什么难度?
java·后端·mysql·spring·阿里云
AI理性派思考者2 小时前
【保姆教程】手把手教你在Linux系统搭建早期alpha项目cysic的验证者&证明者
后端·github·gpu
从善若水3 小时前
【2024】Merry Christmas!一起用Rust绘制一颗圣诞树吧
开发语言·后端·rust