《分布式事务系列教程-第二章-分布式事务理论》

我会带着你远行 2022-09-04 11:41 207阅读 0赞

# 《分布式事务系列教程-第二章-分布式事务理论》 #

# 一、分布式事务理论 #

## 1.1 CAP理论 ##

**CAP**：是一致性（**C**onsistency）、可用性（**A**vailability）和分区容错性（**P**artition tolerance）三个单词的缩写，在一个分布式系统中最多只能保证其中三项中的两项，三个特性是不可能同时满足的，这个结论叫CAP理论。

那什么CAP分别代表的含义是什么呢？

### 1.1.1 一致性（Consistency） ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center]

一致性指的是数据的**强一致性**，每次读取到的数据都是最新数据，当master数据库进行写入时，有新的请求读取slave数据库都必须是最新的数据，哪怕需要等待。如果master写入失败，那么slave读取的则是旧数据。一致性强调的是一致，master和slave的数据必须要保证一致。

**一致性实现方案：**

master写入数据后，向slave同步数据，期间将slave数据锁定，不对外提供任何操作，直至数据库同步完成。**在高并发下性能极其低下。**

### 1.1.2 可用性（Availability） ###

可用性强调的是服务的可用性，每个请求都能在合理的时间响应结果，不允许存在超时或者错误的响应。不管数据是否是最新的（大不了过一会再查一次）。

**可用性实现方案：**

处理请求时，立即响应请求的数据，即使数据还没有及时同步过来，可以先返回旧数据，或者默认数据，来保证服务的可用性。

### 1.1.3 分区容错性（Partition tolerance） ###

分区容错性是指在网络节点分区时（多台机器），不可避免的会出现网络延迟、故障等情况，此时系统任然可以正常运行，不会因为网络问题各节点通信失败，而停止对外界的服务。**分区容错性是分布式系统的一个基本要求**

> **数据分布的节点越多，容忍性就越高，如果此时越是保证数据的一致性，那么可用性就势必越低；**

**分区容错性实现方案：**

当master与slave同步数据失败后整体仍能对外界提供服务，其中一个节点宕机不影响另一个节点的正常工作，可以搭建数据库集群、数据分片、分区、建立副本等。如果有某台服务器宕机，还有备用服务器来提供服务。

## 1.2 CAP组合方式 ##

### 1.2.1 CP： ###

即放弃可用性，保证一致性和分区容错性。假设你在支付宝提现，支付宝扣款，然后远程调用银行系统发起加钱操作，期间用户查询支付宝的余额时，必须是最新的数据（扣款后的数据），查询银行余额时也必须是最新的数据（加钱后的数据）。

### 1.2.2 AP： ###

放弃强一致性，保证可用性和分区容错性。假设你在支付宝提现，支付包扣款，银行余额增加，但是不是立即增加，当再次访问银行余额时发现并没有增加，可能需要过几天数据才会增加上来。（保证了最终一致性）

### 1.2.3 CA： ###

放弃分区容错性，保证一致性和可用性，不进行网络分区，使用单机版可以使用数据的一致性和可用性，但此时的系统已经不是一个标准的分布式系统了，单台MySQL就满足了CA关系。

## 1.3 BASE理论 ##

我们刚刚了解过了CAP理论，在一个分布式系统中想要同时满足CAP是不可能的，我们在选择上必定有所舍取，在系统设计时，我们通常采用AP，保证可用性和分区容错性，舍取一致性，但在实际开发中，一致性通常也需要保证，因此我们采用的是**最终一致性**，不是立刻一致，但最终是一致的。就比如我们上面提到的支付宝转账案例，不是立刻查询到，而是过两天查询到，这样就保证了最终一致性，在CAP中的“C”强调的是**强一致性**，在任何时候每个数据节点都需要数据一致。

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩 写。BASE理论是对CAP中AP的一个扩展。舍去**强一致性**（C），保证可用性和分区容错性。但达到数据的**最终一致性。这种事务，对于满足BASE理论的事务，我们将其称为柔性事务。**

### 1.3.1 基本可用： ###

在分布式系统出现故障时，保证核心功能可用，运行损失部分功能，比如电商系统在做促销活动时，在大流量访问时，服务器压力大，为了保证整体的系统可以，会暂时进行流量限流、降级等操作（让一部分用户等待、或者跳转到一个页面让其刷新重试），而不是继续加重我服务器的负载，导致最后的内存泄漏、宕机等。

### 1.3.2 软状态： ###

BASE理论不强调**强一致性**，**保证最终一致性**。当数据出现改动时，各个节点同步数据时需要靠网络传递，这个过程需要时间，此时这个状态为中间状态，也就是**软状态**。就比如支付宝在提现时，会提示，2天后钱才会转到银行卡。

### 1.3.3 最终一致： ###

软状态指的是数据的中间状态（正在同步数据），最终一致是指不管怎么样，数据最终是要保持一致性的，即使转账失败，数据也要回滚到初始状态（即你支付宝没有扣款，银行也没有加钱）。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center]: /images/20220829/c1aae827ac9c4728aa66b0ddac6a1e2f.png