分布式事务理论基础：CAP定理与BASE理论

分布式事务理论基础：CAP定理与BASE理论

引用

CSDN

1.

https://m.blog.csdn.net/weixin_44374928/article/details/145101984

分布式事务是分布式系统中一个重要的概念，它涉及到多个服务和数据库之间的数据一致性问题。本文将从分布式事务的基本概念出发，介绍CAP定理和BASE理论，以及解决分布式事务的思路。

1. 分布式事务介绍

1.1. 本地事务

本地事务是传统的单机事务。在传统数据库事务中，必须要满足四个原则ACID：

1.2. 分布式事务

分布式事务是指不是在单个服务或单个数据库架构下，产生的事务，例如：

• 跨数据源的分布式事务
• 跨服务的分布式事务
• 综合情况

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为：

• 创建新订单
• 扣减商品库存
• 从用户账户余额扣除金额

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。

但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。此时ACID难以满足，这是分布式事务要解决的问题。

1.3. 演示分布式事务问题

我们通过一个案例来演示分布式事务的问题：

1. 创建数据库，名为seata_demo，然后导入课前资料提供的SQL文件
2. 导入课前资料提供的微服务(seata-demo)
3. 启动nacos所有微服务
4. 测试下单功能，发出Post请求：
5. 数据库结果：
6. 再次尝试，创建10个订单，但是库存中只有 8 个商品了
7. 数据库结果：

测试发现，当库存不足时，会扣减余额而不扣减库存。此时不会回滚，出现了分布式事务问题。

2. 分布式事务理论基础（CAP定理 和 BASE理论）

解决分布式事务问题，需要一些分布式系统的基础知识作为理论指导：

• CAP定理
• BASE理论

2.1. CAP定理

2.1.1. CAP 定理简介

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：

• Consistency（一致性）
• Availability（可用性）
• Partition tolerance （分区容错性）

它们的第一个字母分别是 C、A、P

Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

1. 一致性 Consistency

Consistency：用户访问分布式系统中的任意节点，得到的数据必须一致

1. 可用性 Availability

Availability ：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝

1. 分区容错 Partition Tolerance

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，某些节点之间不连通了，会形成独立分区；Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

2.1.2. 矛盾的问题

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance(分区容错)不可避免，也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。当已经分区的节点接收到新的数据变更时，就会出现问题了：因此分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构

• 如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用（CP）
• 如果此时要保证可用性，就不能等待网络恢复，那 node01、node02与node03之间就会出现数据不一致（AP）

也就是说，在P一定会出现的情况下，A和C之间只能实现一个

另外，需要补充说明的一点是：如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证

总结：

1. 简述CAP定理内容?

• 分布式系统节点通过网络连接，一定会出现分区
• 当分区出现时，系统的一致性和可用性就无法同时满足
• CP：ZooKeeper，HBase，Nacos（全都是非临时实例）
• AP：Redis，Eureka，Nacos（存在临时实例），Cassandra

1. Elasticsearch集群 是C(一致性)P还是A(可用性)P?
   CP；ES集群出现分区时，故障节点会被剔除集群，数据分片会重新分配到其它节点，保证数据一致。因此是低可用性,高一致性，属于CP

2.2. BASE理论

BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。BASE理论是对CAP的一种解决思路，包含三个思想：

• Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态
• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致

2.2.1. BASE 理论的核心思想

即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。为什么这样说呢？AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。（BASE 理论的延伸）

2.2.2. 基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是这绝不等价于系统不可用。什么叫允许损失部分可用性呢？

• 响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s
• 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用

2.2.3. 软状态

软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为 该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

2.2.4. 最终一致性

因此，最终一致性的本质是需要系统保证最终所有的数据能够达到一致，而不需要实时保证系统数据的强一致性

分布式一致性的 3 种级别：

1. 强一致性：系统写入了什么，读出来的就是什么
2. 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态
3. 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态

那实现最终一致性的具体方式是什么呢？

• 读时修复: 在读取数据时，检测数据的不一致，进行修复
• 写时修复: 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致性
• 异步修复: 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复

比较推荐写时修复，这种方式对性能消耗比较低

3. 解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

• AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致（允许结果不一致，再进行补救）
• CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者（TC）；这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务