一定要了解的分布式一致性原理

分手后的思念是犯贱 2022-06-09 12:28 234阅读 0赞

## 一、概述 ##

分布式系统是一个硬件或者软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

## 二、分布式系统的特点 ##

**分布性**  
分布式系统中的多台计算机都会在空间上随意分布，同时，机器的分布情况也会随时变动。  
**对等性**  
分布式系统中的计算机没有主从之分，组成分布式系统的所有计算机节点都是对等的。副本是分布式系统最常见的概念之一，指的是分布式系统对数据和服务提供的一种冗余方式。  
**并发性**  
在一个计算机网络中，程序运行中的并发操作是常见的，可能会并发操作一些共享资源，如数据库或者分布式存储等，如何高效的协调分布式并发操作也是分布式系统架构与设计中最大挑战之一。  
**缺乏全局时钟**  
因为分布式系统是由一系列在空间上随意分布的多个进程组成的，具有明显的分布性，这些进程之间通过交换消息来通信。因为缺乏全局时钟，因此很难界定两个事件发生的先后顺序。所以在设计阶段考虑的异常情况，一定会在系统实际运行中发生，并且，在系统运行过程中还会遇到很多在设计时未能考虑到的异常故障，所以在系统设计中不要放过任何异常情况。

## 三、分布式系统中常见的问题 ##

**通信异常**  
分布式系统需要在各个节点之间进行通信，因此每次网络通信都会伴随着网络不可用的风险（光纤、路由、DNS等硬件设备的不可用）。  
**网络分区**  
由于网络发生异常情况，导致分布式系统中部分节点之间的网络延迟不断增大，最终导致组成分布式系统中只有部分节点能够进行正常通信，这种情况为网络分区，俗称“脑裂”。当出现网络分区时，分布式系统就会出现局部小集群，在极端情况下，这些小集群会独立完成原本需要整个分布式系统才能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战。  
**三态**  
因为网络的问题，所以分布式系统每次请求与响应存在特有的“三态”概念，即成功、失败和超时。由于网络部可靠性，虽然绝大部分情况下，网络通信能够接受到成功失败响应，但网络异常下，就会出现超时现象，通常有以下两种情况：

1.  由于网络原因，请求并没有被成功的发送到接收方，而是在发送过程就发生了丢失现象。
2.  该请求成功的被接收方处理后，但在响应反馈给发送方过程中，发生丢失现场。

## 四、分布式事物 ##

> 对于分布式事物想必大家都是耳熟能详的，毕竟所有的分布式系统都会遇到这个问题。一般一个分布式事物可以看作是由多个分布式的操作序列组成的，通常把这一系列分布式的操作成为子事物。因此，分布式事物也可以被定义为一种嵌套型的事物，同时也就具备了ACID的事物特性。但是由于分布式事物中，各个子系统事物的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事务处理系统就格外的复杂了。所以就出现了诸如CAP和BASE这样的分布式经典理论。  
> \#\#CAP  
> CAP理论告诉我们，一个分布式系统不可能同时满足一致性（c:consistency）、可用性（A:Availability）和分区容错性（P:Partition tolerance）这三个基本需求，最多只能同时满足其中的两项。

**一致性**  
在分布式环境中，一致性是指在多个副本之间是否能够保持一致的特性。对于数据副本分布在不同节点的系统来说，如果一个节点数据更新了，却没有使第二个节点数据相应的更新，那如果此时读到第二个节点的时候获取的就是老数据，这就是典型的数据不一致。如果能做到一个数据更新，所有用户任何节点读到的都是新的数据，那么系统就被认为具有强一致性。  
**可用性**  
就是指服务必须一直处于可用状态，对于用户每个操作请求总是能够在有限的时间内返回结果。重点是“有限的时间内” 和“返回结果”。在不同业务场景下下“有限时间”是不同的。而“返回结果”指的是明确的处理结果，即成功或失败。  
**分区容错性**  
在分布式系统遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非整个挂掉了。

附赠CAP关系图：

![CAP关系图][CAP]

**CAP定理应用**

<table> 
 <thead> 
  <tr> 
   <th>放弃C.A.P</th> 
   <th>解读</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>放弃P</td> 
   <td>如果放弃P后想避免出现分区容错问题，简单做法是将所有的数据（或仅仅与事物有关系的数据）都放在一个分布式节点。但需要注意的是放弃P，就代表放弃了系统的扩展性。</td> 
  </tr> 
  <tr> 
   <td>放弃A</td> 
   <td>放弃A一旦出现网络分区或者其他故障，那么受影响的服务需要等待恢复，并在此期间不能对外提供服务</td> 
  </tr> 
  <tr> 
   <td>放弃C</td> 
   <td>这里说的放弃一致性，不是完全放弃，而是放弃数据强一致性，只保留数据最终一致性。具体多久能够达到数据一致，取决于系统设计，主要包括数据副本在不同节点之间复制时间的长短。</td> 
  </tr> 
 </tbody> 
</table>

其实从设计角度来看，分布式系统不可能满足强一致性、可用性、分区容错性这三个需求。对于分布式系统来说，分区容错是基本属性，因此系统架构师往往把精力放在如何根据业务特点在C （一致性）和 A（可用性）直接寻求平衡。

## BASE理论 ##

> BASE 是由eBay架构师提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。下面看下BASE中的三要素。

**基本可用**  
是指分布式系统出现不可预知的故障时候，允许损失部分可用性，请注意，这绝不是等价于系统不可用。以下两种典型例子：

1.  响应时间上的损失：正常情况下一个搜索引擎需要0.5秒返回查询结果，但由于故障（如系统机房断网或者失火），查询结果响应时间增加到2秒。
2.  服务降级：在秒杀抢购等模式中，限制用户的请求比例，保证系统的稳定性。

**弱状态**  
也称为软状态，和硬状态比，是指允许系统中数据存在中间状态，并认为中间状态不会影响系统的整体可用性，即允许系统在不同几点的数据副本之间进行数据同步的过程存在延时。

**最终一致性**  
系统中所有的数据副本，在经过一段时间同步后，最终能够达到一个一致的状态。不需要实时保证数据强一致。

> 亚马逊首席技术官，发表过一篇对最终一致性详细介绍的文章。他认为最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够获取到最新值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟、系统负载和数据复制方案设计等因素。

#### 在实践中，最终一致性有五类变种： ####

**因果一致性( causal consistency)**  
因果一致性指的是，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据进行更新操作的话，务必基于进程A更新后的最新值，不能发生丢失更新情况。与此同时，与进程A无关系的进程C数据访问无限制

**读已知所写（read your write）**  
指的是，进程A更新数据后，它总是能够访问到更新过的最新值。也就是说，我自己读到的数据一定不会比我上次写入的数据旧。

**会话一致性 （session consistency）**  
就是系统能够保证在同一个有效会话中实现“读已知所写”的一致性，也就是说，在更新操作后，在同一个会话中始终能获取到最新值。

**单调读一致性（monotonic read consistency）**  
指的是如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

**单调写一致性**  
一个系统需要能够保证来自同一个进程的写操作被顺序执行。

> 以上就是五类系统架构中常用到的一致性变种，可以相互结合设计一个具有最终一致性的分布式系统。总体来说BASE理论面向的是大型高可用可扩展的分布式系统，和传统ACID特性相反，不同于ACID的强一致性模型，提出通过牺牲强一致性来获得可用性，并允许数据段时间内的不一致，但是最终达到一致状态。同时，在实际分布式场景中，不同业务对数据的一致性要求不一样，因此在设计中，ACID和BASE理论往往又会结合使用。

## 小结 ##

本文围绕分布式架构发展中碰到的问题，结合CAP、BASE等分布式事物与一致性方面的经典理论，简单的介绍了下分布式系统。下面会逐步分析分布式系统面临的问题和解决方案。

--------------------

关注公众号获取更多视频资料：

> 原创不易，专注于分享技术干货文章的地方，可关注我获取更多神秘资料、视频资料，wx搜索:架构技术专栏

> 专注于分享技术干货文章的地方，内容涵盖java基础、中间件、分布式、apm监控方案、异常问题定位等技术栈。多年基础架构经验，擅长基础组件研发，分布式监控系统，热爱技术，热爱分享  
> ![狍狍的日常生活][format_png]

[CAP]: /images/20220609/a8f2eff6f0394f1cb81f1bf0fee45481.png
[format_png]: /images/20220609/2ff13c692c8c4a97ab85af7844a56d21.png