聊一下分布式一致性基础

聊一下分布式一致性基础

一、什么是分布式一致性?所谓的分布式一致性问题,就是指在分布式环境中引入副本概念(数据备份)后,不同的数据节点可能出现的、并无法依靠程序自身解决的数据不一致问题。其实归根到底,就是数据备份更新的不一致。

举个简单的例子 : 客户端C1将数据库中一个值Key由Value1更新为Value2,由于虽然事务已经提交了但存在网络延迟等问题,客户端C2无法立刻读取到Key的最新值,从而导致了分布式系统中几份数据内容不一致的情况。

补充 : 分布式系统为什么要引入副本概念?副本,又可以称为数据备份复制,一般来说是出于以下两个原因 :

为了增加系统的可用性,以防止单点故障引起系统不可用,进而导致系统提供的服务崩溃。

多份数据备份,可以通过负载均衡算法,让不同区域的数据备份为不同地区的用户提供一致的服务,提高系统的并发抗压性能。

因此,我们必须保证不同的数据备份之间数据上的一致性(PS:此处的数据,不仅只包括我们通常讲的数据库中的数据,还包括分布式系统中常常提到的消息、提案等等)。关于这个问题,

首先分析其产生的原因 : 由更新的源节点出发,将更新信息发送到各个副本节点并完成操作,最终汇总响应给整个系统,这个过程中存在着一定的延时。

这样子的话,有一种很粗暴的解决方案(也的确有些系统引用了这种思路) : 但分布式系统执行更新操作时,将所有相关的数据备份加锁(类似于数据库的写锁概念),直到数据复制操作完成以确保数据的一致性。

那么这种做法将会导致系统性能的急剧下降 : 在大量写入操作情况下,最可怕是是引起数据雪崩性的加锁(数据备份所存在的资源不断加锁),并且可能由于前一个请求善未完成而导致后一个请求超时,最终系统整体性能急剧下降(过多的请求堵塞也可能导致系统节点崩溃)。

总的来说,系统的可用性和数据的一致性之间似乎是一对天生的矛盾,设计者在两者间进行反复的权衡,由此产生了一系列的一致性协议(如,2PC、3PC等),但这些协议将不在我们此次的讨论范围之内(后续展开)。不过由此,也催生了一个权衡两者的一致性级别 :

强一致性这种一致性级别是最强的,就是直接采用前文提到的解决方案,来保证系统在全局范围内所有副本的一致性,确保用户写入(节点扩散)是什么,任何一个用户读到(节点接收)的就是什么,但其对系统性能的影响也是最大的。

弱一致性这种一致性级别与上一种级别相反,它并不承诺用户写入(节点扩散)提交后,其他用户读出(节点接收)的一致性。但是它还是会尽其最大的努力交付到每一个数据备份。

最终一致性这是一致性级别介于前两种级别之间,系统会保证在一定时间内达到全局范围内所有副本一致性的要求,以及在超时之后的一系列纠错机制,也是现在最为常见的做法。不过其保证时间的确定还是会受到很多约束(网络、系统分布等待)。

二、分布式环境所面临的挑战

在分布式系统的应用过程中,也面临着许许多多的困难和挑战,其中最为典型的几类难题 :

通信异常由于网络本身的不可靠性,分布式系统需要在各个节点之间进行网络通信,因此每次网络通信其实也伴随着网络不可用的风险。另外,即使分布式系统各个节点之间网络通信正常,其延时也会大于单机操作(单机内存访问的延时通常在纳秒数量级,而正常一次网络通信的延时在0.1~1ms左右)。

网络分区当网络发生异常,可能导致分布式系统中部分的节点的网络时延不断增大,最终导致分布式系统中只有部分节点之间可以正常通信,而一些节点处于不可用状态——这个现象称为网络分区。当出现网络分区时,分布式系统将会出现局部小集群。在极端情况下,局部小集群需要独立完成整个分布式系统提供的服务,包括了对于数据的事务处理,这对于分布式一致性提出了非常大的挑战。

三态三态,指的是成功、失败、超时。在分布式系统中,由于网络是不可靠的,虽然在绝大多数情况下,系统能够接收到成功或者失败的响应。但是当网络出现异常的情况下,就可能会出现超时现象,通常有以下两种情况 :当出现这样的超时现象,网络通信发起方就无法确定当前请求是否被成功处理。

由于网络原因,请求(消息)并没有被成功发送到接收方,而是在发送过程中发生了消息丢失现象。

请求(消息)成功被接收方接收并进行了处理,但是在将响应反馈给发送方的过程中,出现了消息丢失现象。

节点故障这个问题比较好理解,指的是组成分布式系统的节点出现了宕机或"僵死"现象,需要提供一系列的容错处理机制。

三、CAP理论

CAP理论,一个经典的分布式系统理论 :一个分布式系统不可能同时满足一致性(Consistent)、可用性(Availability)和分区容错性(Partition tolerance) 这三个基本需求,最多只能同时满足两个。1、一致性在分布式系统中的所有数据备份,在同一时刻是否同样的值(等同于所有节点访问同一份最新的数据副本)。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致的状态。2、可用性在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求(对数据更新具备高可用性)。可用性,强调对于操作,要求在有限时间内给出返回结果。“有限时间”是指,对于用户的一个操作请求,系统必须能够在指定的时间内返回对 应的处理结果,如果超过了这个时间范围,那么系统就被认为是不可用的。另外,"有限的时间内"是指系统设计之初就设计好的运行指标,通常不同系统之间有很 大的不同,无论如何,对于用户请求,系统必须存在一个合理的响应时间,否则用户便会对系统感到失望。“返回结果”,要求系统在完成对用户请求的处理后,返回一个正常的响应结果。正常的响应结果通常能够明确地反映出队请求的处理结果,即成功和失败,而不是一个让用户迷惑的返回结果。3、分区容错性以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。分布式系统在遇到任何网络分区故障时,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。

4、三足无法鼎立4.1 CP?还是AP?这个我们从一个实例来入手 :假设我们有一台服务器A对外提供存储服务,为了避免这台服务器宕机导致服务不可用,我们又在另外一台服务器B上运行了同样的存储服务。每次用户在往服务器A写入数据的时候,A都往服务器B上写一份,然后再返回客户端。一切都运行得很好,用户的每份数据都存了两份,分别在A和B上,用户访问任意一台机器都能读取到最新的数据。某天,不幸的事情发生,A和B之间的网络断了导致A和B无法通信,也就是说网络出现了分区,那么用户在往服务器A写入数据的时候,服务器A无法将该数据写入到服务器B。这时,服务器A就必须要做出一个艰难的选择!!!选择如下 :

要么选择一致性(C)而牺牲可用性(A):为了保证服务器A和B上的数据是一致的,服务器A决定暂停对外提供数据写入服务,从而保证了服务器A和B上的数据是一致,但是牺牲了可用性。

要么选择可用性(A)而牺牲一致性(C):为了保证服务不中断,服务器A先把数据写入到了本地,然后返回客户端,从而让客户端感觉数据已经写入了。这导致了服务器A和B上的数据就不一致了。

4.2 上面的选择中没有提及到“牺牲分区容错性(P)”,为什么?从上面那个例子出发,网络分区现象其实是两台服务器无法再期望的时间内完成数据交互,原因很多可能是网络断开、网络延时、服务器宕机等。但是,对于一个分布式系统而言,分区容错性是分布式系统的一个最基本的要求。既然是一个分布式系统,那么其各种组件必然需要部署到不同的节点(不然就是单机概念了),因此必然出现子网络。而对于分布式系统而言,网络问题又是一个必定会出现的异常情况,因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。PS : 如果有一个分布式系统号称满足AC,肯定是扯淡的……4.3 对于AC的抉择,对于P的处理

可用性和一致性之间的选择不是非此即彼的,而是根据业务的需求在它们两者之间做妥协。比如,我们可以放弃对强一致性的追求,让其变成最终一致性。

对于网络分区的处理一般有以下几个步骤 :

(图片来自InfoQ)

检查是否出现网络分区

进入网络分区模式,并限制提供某些操作或者服务

心跳检查网络情况,尽快恢复整个分布式系统网络

四、BASE理论

BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结, 是基于CAP定理逐步演化而来的。BASE理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。1、基本可用基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性,即保证核心可用。2、弱状态弱状态,也称软状态,是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响到系统的整体可用性,即允许系统在不同节点的数据备份之间进行数据同步的过程中存在延时。3、最终一致性最终一致性,其本质是需要系统保证最终数据能够达到一致,而不需要实时系统数据的强一致性。参考资料

《从Paxos到ZooKeeper 分布式一致性原理与实践》

《大规模分布式存储系统 原理解析与架构实战》

百度百科(关于CAP与BASE原理的定义)

CSDN 博客

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180426G1132X00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券