🏆🏆🏆教程全知识点简介：微服务保护、服务异步通信、消息中间件部署、分布式事务、搜索引擎、缓存、数据同步以及相关组件的安装配置等技术要点。在微服务保护方面，介绍了 Sentinel 的基础知识，包括雪崩问题、超时处理、舱壁模式、断路器机制，以及不同服务保护技术的对比；讲解了流量控制（簇点链路、流控模式、热点参数限流）、隔离与降级（FeignClient 整合 Sentinel、线程隔离）、授权规则（自定义异常结果）及规则持久化（规则管理模式与 pull 模式），并演示了基于 Nacos 的规则持久化改造。服务异步通信部分探讨了消息可靠性（生产者消息确认、Return 回调、ConfirmCallback）、死信交换机、TTL 队列等高级应用。RabbitMQ 部署指南涵盖了单机部署、DelayExchange 插件安装、集群部署、镜像模式等内容。分布式事务部分介绍了 CAP 定理、BASE 理论、常见解决方案，Seata 的基础与部署（TC 服务部署、Nacos 配置、数据库表创建）、多种事务模式（XA 模式及优缺点、四种模式对比）和高可用架构。分布式搜索引擎章节讲解了 Elasticsearch 的原理（ELK 技术栈、倒排索引）、索引库与文档操作、RestAPI 与 RestClient 的使用、排序与高亮、酒店搜索案例（分页、竞价排名、ad标记、算分函数）、自动补全、数据同步（同步调用、监听 binlog）、集群搭建与脑裂问题、分片存储测试，以及单点 ES、Kibana、IK 分词器安装。缓存部分介绍了 Redis 持久化（RDB 与 AOF 对比）、单机安装 Redis、Redis 集群、多级缓存（JVM 进程缓存、Caffeine）、请求参数处理、Tomcat 查询、HTTP 工具与 CJSON 工具类、Redis 缓存查询。数据同步与网关部分包括 Canal 安装（开启 MySQL 主从、设置权限）、OpenResty 安装（开发库、目录结构、环境变量配置）及运行流程。

📚📚👉👉👉本站这篇博客：   https://bbs.huaweicloud.com/blogs/459783    中查看

📚📚👉👉👉本站这篇博客：   https://bbs.huaweicloud.com/blogs/459783    中查看

📚📚👉👉👉本站这篇博客：   https://bbs.huaweicloud.com/blogs/459519    中查看

✨ 本教程项目亮点

🧠 知识体系完整：覆盖从基础原理、核心方法到高阶应用的全流程内容
💻 全技术链覆盖：完整前后端技术栈，涵盖开发必备技能
🚀 从零到实战：适合 0 基础入门到提升，循序渐进掌握核心能力
📚 丰富文档与代码示例：涵盖多种场景，可运行、可复用
🛠 工作与学习双参考：不仅适合系统化学习，更可作为日常开发中的查阅手册
🧩 模块化知识结构：按知识点分章节，便于快速定位和复习
📈 长期可用的技术积累：不止一次学习，而是能伴随工作与项目长期参考

🎯🎯🎯全教程总章节

🚀🚀🚀本篇主要内容

分布式事务

0.学习目标

1.分布式事务问题

1.1.本地事务

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

1.2.分布式事务

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

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

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

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

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

订order单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。

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

此时ACID难以满足，这是分布式事务要解决的问题

1.3.演示分布式事务问题

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

1）创建数据库，名为seata_demo，然后导入课前资料提供的SQL文件：

2）导入课前资料提供的微服务：

微服务结构如下：

其中：

seata-demo：父工程，负责管理项目依赖

• account-service：账户服务，负责管理用户的资金账户。提供扣减余额的接口
• storage-service：库存服务，负责管理产品库存。提供扣减库存的接口
• order-service：订order单服务，负责管理订order单。创建订order单时，需要调用account-service和storage-service

3）启动nacos、所有微服务

4）测试下单功能，发出Post请求：

请求如下：

curl --location --request POST '

如图：

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

2.理论基础

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

2.1.CAP定理

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

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

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

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

2.1.1.一致性

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

比如现在包含两个节点，其中的初始数据是一致的：

当 修改其中一个节点的数据时，两者的数据产生了差异：

要想保住一致性，就必须实现node01 到 node02的数据 同步：

2.1.2.可用性

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

如图，有三个节点的集群，访问任何一个都可以及时得到响应：

当有部分节点因为网络故障或其它原因无法访问时，代表节点不可用：

2.1.3.分区容错

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

2.1.4.矛盾

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。

[Spring AMQP 文档]

当节点接收到新的数据变更时，就会出现问题了：

如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。

如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。

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

2.2.BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

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

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

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

• AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。

• CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

3.初识Seata

[Programiz Java]

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。

官网地址：

3.1.Seata的架构

Seata事务管理中有三个重要的角色：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

• TM (Transaction Manager) - **事务管