分布式--分布式架构

不念不忘少年蓝@ 2022-12-30 08:20 60阅读 0赞

原文网址：[分布式--分布式架构\_IT利刃出鞘的博客-CSDN博客][--_IT_-CSDN]

# 其他网址 #

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

# 简介 #

## **CAP定理** ##

**CAP定理**

> 一个分布式系统不可能同时满足一致性（C:Consistency)、可用性(A:Availability)和分区容错性（P:Partitiontolerance)这三个基本需求，最多只能同时满足其中的两项。
> 
> 1.  一致性(Consistency) ： 在分布式系统中数据一旦更新，所有数据变动都是同步的（同一数据的各个副本是同步的）。
> 2.  可用性(Availability) ： 好的响应性能：每个操作都必须有预期的响应结束。
> 3.  分区容错性(Partition tolerance) ： 在网络分区的情况下，即使出现单个节点无法可用，系统依然正常对外提供服务。
> 
> 在分布式系统中，在任何数据库设计中，一个Web应用**至多只能同时支持上面的两个属**性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。
> 
> 对于一个业务系统来说，**可用性和分区容错性是必须要满足的两个条件**，并且这两者是相辅相成的。业务系统之所以使用分布式系统，主要原因有两个：
> 
>  *  提升整体性能 ：当业务量猛增，单个服务器已经无法满足我们的业务需求的时候，就需要使用分布式系统，使用多个节点提供相同的功能，从而整体上提升系统的性能，这就是使用分布式系统的第一个原因。
>  *  实现分区容错性 ：单一节点 或 多个节点处于相同的网络环境下，那么会存在一定的风险，万一该机房断电、该地区发生自然灾害，那么业务系统就全面瘫痪了。为了防止这一问题，采用分布式系统，将多个子系统分布在不同的地域、不同的机房中，从而保证系统高可用性。
> 
> 这说明分区容错性是分布式系统的根本，如果分区容错性不能满足，那使用分布式系统将失去意义。

**数据一致性的基础理论**

>  *  **强一致：**当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。
>  *  **弱一致性：**系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。
>  *  **最终一致性：**弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。

## **BASE理论** ##

对于业务系统而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里要指出的是，所谓的“牺牲一致性”并不是完全放弃数据一致性，而是牺牲**强一致性**换取**弱一致性**。

Base理论：基本可用（**B**asically **A**vailable），软状态（**S**oft State），最终一致性（**E**ventually Consistent）

**Basic Available**

假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言有以下处损失：

*  响应时间上的损失：示例：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
 *  功能上的损失：示例：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

**Soft State**

硬状态：相对于原子性而言，要求多个节点的数据副本都是一致的。

软状态：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

**Eventually Consistent**

上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

在实际工程实践中，最终一致性分为5种：

<table> 
 <tbody> 
  <tr> 
   <td><strong>项</strong></td> 
   <td><strong>说明</strong></td> 
  </tr> 
  <tr> 
   <td>因果一致性（Causal consistency）</td> 
   <td>如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。与此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。</td> 
  </tr> 
  <tr> 
   <td>读己之所写（Read your writes）</td> 
   <td>节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。</td> 
  </tr> 
  <tr> 
   <td>会话一致性（Session consistency）</td> 
   <td>会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。</td> 
  </tr> 
  <tr> 
   <td>单调读一致性（Monotonic read consistency）</td> 
   <td>如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。</td> 
  </tr> 
  <tr> 
   <td>单调写一致性（Monotonic write consistency）</td> 
   <td>一个系统要能够保证来自同一个节点的写操作被顺序的执行。</td> 
  </tr> 
 </tbody> 
</table>

在实际的实践中，这5种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。

实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。

ACID能够保证事务的强一致性，即数据是实时一致的。这在本地事务中是没有问题的，在分布式事务中，强一致性会极大影响分布式系统的性能，因此分布式系统中遵循BASE理论即可。  
分布式系统的不同业务场景对一致性的要求也不同。如交易场景下，就要求强一致性，此时就需要遵循ACID理论，而在注册成功后发送短信验证码等场景下，并不需要实时一致，因此遵循BASE理论即可。

**要根据具体业务场景，在ACID和BASE之间寻求平衡**。

[--_IT_-CSDN]: https://knife.blog.csdn.net/article/details/111644139