---

前言

一、微服务篇-01-微服务-课程介绍

微服务篇-02-springcloud-常见组件有哪些

详情看我的飞书文档有详细笔记！

微服务篇-03-springcloud-注册中心eureka、nacos

就是可以把配置放到nacos里面统一管理，比如user微服务 配置文件在nacos管理 本地只有bootstrap

微服务篇-04-springcloud-ribbon负载均衡，负载均衡策略，自定义负载均衡

微服务篇-05-spring cloud-服务雪崩、熔断降级

 它们如何协同工作

在实际系统中，熔断和降级常常是协同工作的，形成一个立体的防护体系

1. 1.

   ​​第一道防线（熔断）​​：当某个​​下游服务​​（如支付服务）故障率突然升高，熔断器会快速介入，切断对其的调用，防止线程被大量占用和资源耗尽。

2. 2.

   ​​第二道防线（降级）​​：当熔断发生时，或系统​​自身压力过大​​时，降级策略会启动。对于被熔断的服务，降级提供友好的错误提示或默认数据；对于系统自身的非核心功能，降级会选择暂时关闭或简化其流程（如关闭商品评论功能）。

3. 3.

   ​​第三道防线（限流）​​：通常还会配合​​限流​​（Rate Limiting），从入口就控制流量，避免过多请求压垮系统。

• •

  ​​正常情况​​：用户下单时，系统会调用​​订单服务​​（核心）、​​库存服务​​（核心）、​​积分服务​​（非核心）和​​推荐服务​​（非核心）。

• •

  ​​积分服务挂了​​：此时，​​熔断器​​检测到积分服务调用连续失败，触发熔断。后续所有下单请求都不会再尝试调用积分服务，而是直接执行其​​降级逻辑​​（如记录日志“积分服务暂不可用，稍后补算”）。订单和库存服务这些核心流程不受影响，订单依然能成功创建。这就是​​熔断触发的降级​​。

• •

  ​​双十一大促​​：系统流量激增，CPU吃紧。此时，即使所有服务都正常，系统也可能​​主动开启降级​​，比如暂时关闭推荐服务，或者让积分服务返回一个“活动期间积分加倍计算暂缓”的静态页面，以节省资源确保下单、支付等核心链路的顺畅。这就是​​基于资源情况的降级​​，它不一定需要熔断来触发。

• 

微服务篇-06-spring-cloud-微服务的监控-skywalking

第一个功能太简单， 第二个搭建复杂  ， 第三个和代码有耦合。 只推荐使用第四个

可以看到加载时间很长，他有问题。定位代码：

还可以查看SQL

有时间可以自己搭建一下试试！

-----------------------------------

分篇

微服务篇-07-业务问题-微服务限流（漏桶算法、令牌桶算法）

1.2.3.4

1.tomcat

只适合单体项目

2.1nginx控制速率 不用记住参数 简单描述即可

2.2nginx控制并发

网管要配置redis连接才能用

微服务篇-08-分布式系统理论-CAP和BASE

微服务篇-09-业务问题-分布式事务解决方案

上面是大体思路，下面是三种模式

异步 性能高 ，一致性差。有小概率发生问题

微服务篇-10-业务问题-分布式服务的接口幂等性如何设计

幂等概念

微服务篇-11-业务问题-你们项目中使用了什么分布式任务调度-xxl-job

xxljob是一个轻量级分布式任务调度平台，核心设计目标是简化任务调度与分布式协调，支持动态调度、分片执行、故障转移等功能。

分片广播：花呗通知所有人还款

记住红色的

下面是启动方法：

快速入门示例

1. 部署调度中心：下载Release包并启动，访问http://localhost:8080/xxl-job-admin。
2. 集成执行器：在项目中添加依赖，配置执行器信息：

   <dependency>
       <groupId>com.xuxueli</groupId>
       <artifactId>xxl-job-core</artifactId>
       <version>2.3.0</version>
   </dependency>

3. 定义任务：通过@XxlJob注解编写任务方法：

   @XxlJob("demoJobHandler")
   public void execute() {
       System.out.println("XXL-JOB Hello World.");
   }
   
   功能作用

4. 任务注册
   框架扫描到该注解后，会自动将方法注册到执行器任务列表中，供调度中心调用。

5. 任务绑定
   调度中心通过 JobHandler 名称关联具体执行逻辑，实现任务触发与执行的解耦。

6. 动态调度支持
   支持通过调度中心动态控制任务触发时机（如定时、手动、API触发等）。

消息中间件篇-01-消息中间件-课程介绍

提供了系统间的异步调用实现了服务与服务之间的解耦

消息中间件篇-02-RabbitMQ-如何保证消息不丢失

如何防止丢失

如果队列那里丢失呢？

消息中间件篇-03-RabbitMQ-消息的重复消费问题如何解决的

都是通用的

根据业务来上锁，只有拿到这个业务锁的线程才能消费 其他都快速失败了

消息中间件篇-04-RabbitMQ-中死信交换机 (RabbitMQ延迟队列有了解过嘛)

  

可以绑定到新的交换机去消费·。

消息中间件篇-05-RabbitMQ-如果有100万消息堆积在MQ , 如何解决(消息堆积怎么解决)

消息中间件篇-06-RabbitMQ的高可用机制有了解过嘛

queue1挂了消息就没了

缺点：还未来得及同步的时候就宕机了，导致数据再次丢失

改进：使用仲裁队列。他的raft协议可以保证数据强一致性

Raft是一种分布式一致性算法，核心目标是通过选举领导者和日志复制机制，确保分布式系统中的节点达成一致状态。Raft将问题分解为领导者选举、日志复制和安全性三个子问题，并通过强领导者模型降低复杂性。

 

消息中间件篇-07-Kafka是如何保证消息不丢

同步发送会造成阻塞

至少设置1，all效率低

同步会阻塞，异步会不准确，所以两种结合

消息中间件篇-08-Kafka是如何保证消费的顺序性

消息中间件篇-09-Kafka的高可用机制有了解过嘛

​​Replication（副本）​​

消息中间件篇-10-Kafka数据清理机制了解过嘛

消息中间件篇-11-Kafka实现高性能的设计有了解过嘛

不是零次