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

📚📚👉👉👉   https://gitee.com/xiaoshuai112/Backend/blob/master/Spring/SpringCloud服务端高级框架/note.md 🍅🍅

✨ 本教程项目亮点

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

🎯🎯🎯全教程总章节

🚀🚀🚀本篇主要内容

微服务保护

1.初识Sentinel

1.1.雪崩问题及解决方案

1.1.1.雪崩问题

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。

如图，如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。

但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。

那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：

1.1.2.超时处理

解决雪崩问题的常见方式有四种：

•超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待

1.1.3.仓壁模式

方案2：仓壁模式

仓壁模式来源于船舱的设计：

船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。

于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。

1.1.4.断路器

断路器模式：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

断路器会统计访问某个服务的请求数量，异常比例：

当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断：

1.1.5.限流

流量控制：限制业务访问的QPS，避免服务因流量的突增而故障。

1.1.6.总结

什么是雪崩问题？

• 微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。

MyBatis-Spring 集成

可以认为：

限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。

超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。

1.2.服务保护技术对比

在SpringCloud当中支持多种服务保护技术：

• Netfix Hystrix
• Sentinel
• Resilience4J

早期比较流行的是Hystrix框架，但目前国内实用最广泛的还是阿里巴巴的Sentinel框架，这里我们做下对比：

1.3.Sentinel介绍和安装

2.流量控制

雪崩问题虽然有四种方案，但是限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。我们先学习这种模式。

2.1.簇点链路

当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。

默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，也就是controller中的方法），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。

例如，我们刚才访问的order-service中的OrderController中的端点：/order/{orderId}

流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

• 流控：流量控制
• 降级：降级熔断
• 热点：热点参数限流，是限流的一种
• 授权：请求的权限控制

2.1.快速入门

2.1.1.示例

点击资源/order/{orderId}后面的流控按钮，就可以弹出表单。

表单中可以填写限流规则，如下：

其含义是限制 /order/{orderId}这个资源的单机QPS为1，即每秒只允许1次请求，超出的请求会被拦截并报错。

2.1.2.练习：

需求：给 /order/{orderId}这个资源设置流控规则，QPS不能超过 5，然后测试。

1）首先在sentinel控制台添加限流规则

2）利用jmeter测试

如果没有用过jmeter，可以参考课前资料提供的文档《Jmeter快速入门.md》

课前资料提供了编写好的Jmeter测试样例：

打开jmeter，导入课前资料提供的测试样例：

选择：

20个用户，2秒内运行完，QPS是10，超过了5.

选中流控入门，QPS<5右键运行：

注意，不要点击菜单中的执行按钮来运行。

结果：

可以看到，成功的请求每次只有5个

2.2.流控模式

在添加限流规则时，点击高级选项，可以选择三种流控模式：

Spring Data Redis 文档

• 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
• 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
• 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

快速入门测试的就是直接模式。

2.2.1.关联模式

关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

配置规则：

语法说明：当/write资源访问量触发阈值时，就会对/read资源限流，避免影响/write资源。

使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

需求说明：

• 在OrderController新建两个端点：/order/query和/order/update，无需实现业务

• 配置流控规则，当/order/ update资源被访问的QPS超过5时，对/order/query请求限流

1）定义/order/query端点，模拟订单查询

@GetMapping("/query")
public String queryOrder() {
    return "查询订单成功";
}

2）定义/order/update端点，模拟订单更新

@GetMapping("/update")
public String updateOrder() {
    return "更新订单成功";
}

重启服务，查看sentinel控制台的簇点链路：

3）配置流控规则

对哪个端点限流，就点击哪个端点后面的按钮。我们是对订单查询/order/query限流，因此点击它后面的按钮：

Lettuce Redis 客户端

在表单中填写流控规则：