文章目录
- 一，285、商城业务-分布式事务-分布式CAP&Raft原理
-
- 1，CAP简介
- 2，三种常见的组合
-
- [2.1 CA 模型 - 一致性 + 可用性](#2.1 CA 模型 - 一致性 + 可用性)
- [2.2 CP 模型 - 一致性 + 分区容忍性](#2.2 CP 模型 - 一致性 + 分区容忍性)
- [2.3 AP 模型 - 可用性 + 分区容忍性](#2.3 AP 模型 - 可用性 + 分区容忍性)
- 3，CAP最小必要知识
- 4，Raft算法资料
- 二，286、商城业务-分布式事务-BASE
- 三，287、商城业务-分布式事务-分布式事务常见解决方案
- 四，288、商城业务-分布式事务-Seata&环境准备
-
- [1. 性能开销](#1. 性能开销)
- [2. 数据库压力](#2. 数据库压力)
- [3. 复杂性和维护成本](#3. 复杂性和维护成本)
- [4. 非阻塞需求](#4. 非阻塞需求)
- [5. 最终一致性](#5. 最终一致性)
- [6. 分布式系统的特点](#6. 分布式系统的特点)
- 五，290、商城业务-分布式事务-最终一致性库存解锁逻辑
- 动画资料
包含从285~290的内容，不详细，可忽略。
一，285、商城业务-分布式事务-分布式CAP&Raft原理
1，CAP简介
CAP定理，由加州大学伯克利分校的教授埃里克·布鲁尔（Erich Brewer）提出，并由塞思·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）证明，是分布式系统设计中的一个基础理论。
这个理论指出，在一个分布式系统中，不可能同时实现一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三个特性。
因此，分布式系统必须在这三个特性中做出权衡。
在实际应用中，根据系统的具体需求，通常会选择满足其中的两个特性而牺牲第三个。
2，三种常见的组合
2.1 CA 模型 - 一致性 + 可用性
这种模型下，当网络分区发生时，系统将停止工作，即无法保证分区容忍性。在没有网络分区的情况下，CA系统能够提供强一致性和高可用性。
例子 ：
数据库事务处理系统，这类系统需要确保数据的一致性，因此在网络出现问题时，它可能会拒绝服务来保持一致性。
2.2 CP 模型 - 一致性 + 分区容忍性
在这种情况下，系统可以容忍网络分区，并且在分区发生时仍能保持数据的一致性。但是，这可能意味着某些请求不会立即得到响应，即牺牲了可用性。
例子 ：
银行转账系统，为了保证资金转移的一致性，即使在网络不稳定时，系统也可能延迟操作直到确认数据的一致性。
2.3 AP 模型 - 可用性 + 分区容忍性
AP系统选择在任何情况下都提供服务，即使这意味着在分区期间返回的可能是陈旧的数据，即牺牲了一致性。
例子 ：
大型的Web应用程序或缓存系统，如亚马逊的商品详情页面，即使部分数据没有立即更新，用户仍然可以访问到大部分功能和服务。
3，CAP最小必要知识
- 讨论的对象是单一的分布式部署的存储服务
- 一般情况下，必须要保证分区容错性
4，Raft算法资料
二，286、商城业务-分布式事务-BASE
BASE理论是对 CAP 理论的延伸，思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但可以采用适当的采取弱一致性，即最终一致性，保证服务可用。
BASE 是指：
- 基本可用（Basically Available）
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。
响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1~2 秒。
功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。
- 软状态（ Soft State）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。
- 最终一致性（ Eventual Consistency）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
三，287、商城业务-分布式事务-分布式事务常见解决方案
1，2PC-两阶段提交
2，柔性事务
3，柔性事务-最大努力通知型方案
4，柔性事务-可靠消息+最终一致性方案（异步确保型）
四，288、商城业务-分布式事务-Seata&环境准备
在商城服务中，使用 Seata 这种基于两阶段提交（2PC）协议的分布式事务管理方案并不是最佳选择，原因有以下几个方面：
1. 性能开销
Seata 或任何基于 2PC 的方案都会引入额外的网络延迟和计算开销。对于高并发的商城系统来说，每次请求都需要经过额外的事务协调步骤，这会显著增加系统的响应时间，降低吞吐量。
2. 数据库压力
在高并发场景下，频繁地使用全局事务可能会导致数据库锁竞争加剧，尤其是在涉及多个表或者多个数据库的情况下。这会导致更多的等待时间，从而影响整体性能。
3. 复杂性和维护成本
实现全局事务需要对应用程序进行改造，使其能够支持 Seata 的逻辑，例如在业务代码中加入必要的事务控制逻辑。此外，还需要维护额外的 Seata 组件，如 TC（事务协调器），这增加了系统的复杂度和运维成本。
4. 非阻塞需求
现代微服务架构倾向于无阻塞的异步编程模型，而 2PC 是一种阻塞式的协议，在事务未最终提交或回滚之前，参与节点必须保持锁定资源，这对于追求快速响应的应用来说不是一个理想的选择。
5. 最终一致性
对于很多商城服务来说，事务的一致性要求可能并不需要严格的强一致性，而是可以接受最终一致性。在这种情况下，可以采用更轻量级的解决方案，比如补偿事务（TCC）、Saga 模式或者事件驱动架构等，这些方法可以在不牺牲性能的前提下达到业务所需的最终一致性。
6. 分布式系统的特点
在分布式系统中，CAP 定理告诉我们无法同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）。对于高可用和高并发的商城系统，通常会选择牺牲一定程度的一致性来换取更高的可用性和扩展性。