黑马微服务课程1

一、GateWay

二、服务调用OpenFeign

三、Sentinel

1. 流量控制（限流规则）

2. 隔离和降级

2.1 FeignClient整合Sentinel

2.2 线程隔离（舱壁模式）

2.3 熔断降级

3. 授权规则

3.1 授权规则

3.2 自定义异常结果

4. 规则持久化

四、分布式事务seata

4.1 理论基础

1. CAP定理

2. BASE理论

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

4.2 初识Seata

1. Seata基础知识

2. 部署TC服务

3. 微服务集成seata

4.3 Seata的四种事务模式详解

1. XA模式

1）Seata的XA模型

2）XA模式优缺点

3）实现XA模式

2. AT模式★★★

2）AT与XA的区别

3）脏写问题即解决方案

4）优缺点

5）代码实现

3. TCC模式★★★

1）TCC模式原理

2）优缺点

3）事务悬挂和空回滚

4）代码实现TCC模式

4. Saga 模式

四种模式对比★★★

4.4 高可用

五、分布式缓存Redis

5.1 Redis持久化

1. RDB持久化

1）执行时机

2）RDB原理

3）小结

2. AOF持久化

3. RDB与AOF对比

5.2 Redis主从

1. 搭建主从架构

2. 主从数据同步原理

2.1 全量同步

2.2 增量同步

2.3 主从同步优化

2.4 小结

5.3 Redis哨兵

1 哨兵原理

1）哨兵的结构和作用

2）集群监控原理

3）集群故障恢复原理

4）小结

2. 搭建哨兵集群

3. RedisTemplate

5.4 Redis分片集群

六、多级缓存

七、rabbitmq的高级特性（真清晰）

7.1 消息可靠性

7.2 死信交换机

1）私信交换机

2）TTL

3）延迟队列

7.3 惰性队列

1）消息堆积问题

2）惰性队列

7.4 MQ集群

八、面试篇★★★

8.1 微服务常见面试题

8.2 Nacos源码分析

1. 服务发现

2. 服务心跳

3. 服务发现

8.3 Sentinel源码分析

1. Sentinel的线程隔离与Hystix的线程隔离有什么差别? （略）

2. Sentinel的限流与Gateway的限流有什么差别？

3. Sentinel源码分析

4. Sentinel官网地址：

课程名称：SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务
课程地址：微服务技术栈导学1_哔哩哔哩_bilibili

微服务其实是分布式架构的最佳实践方案，国内最知名是SpringCloud和阿里巴巴的Dubbo。

一、GateWay

微服务内部有相互调用关系时，使用Feign组件；外部有用户访问时，直接发请求到微服务。但为了安全，需要使用GateWay网关进行身份认证。网关功能：

身份认证和权限校验
服务路由、负载均衡
请求限流

服务调用 | RuoYi

基本介绍

Feign

Feign 是Spring Cloud Netflix组件中的一量级Restful的 HTTP 服务客户端，实现了负载均衡和 Rest 调用的开源框架，封装了Ribbon和RestTemplate, 实现了WebService的面向接口编程，进一步降低了项目的耦合度。

什么是服务调用

顾名思义，就是服务之间的接口互相调用，在微服务架构中很多功能都需要调用多个服务才能完成某一项功能。

为什么要使用Feign

Feign 旨在使编写 JAVA HTTP 客户端变得更加简单，Feign 简化了RestTemplate代码，实现了Ribbon负载均衡，使代码变得更加简洁，也少了客户端调用的代码，使用 Feign 实现负载均衡是首选方案，只需要你创建一个接口，然后在上面添加注解即可。
Feign 是声明式服务调用组件，其核心就是：像调用本地方法一样调用远程方法，无感知远程 HTTP 请求。让开发者调用远程接口就跟调用本地方法一样的体验，开发者完全无感知这是远程方法，无需关注与远程的交互细节，更无需关注分布式环境开发。

Feign vs OpenFeign

Feign 内置了Ribbon，用来做客户端负载均衡调用服务注册中心的服务。
Feign 支持的注解和用法参考官方文档：https://github.com/OpenFeign/feign官方文档，使用 Feign 的注解定义接口，然后调用这个接口，就可以调用服务注册中心的服务。

Feign本身并不支持Spring MVC的注解，它有一套自己的注解，为了更方便的使用Spring Cloud孵化了OpenFeign。并且支持了Spring MVC的注解，如@RequestMapping，@PathVariable等等。
OpenFeign的@FeignClient可以解析Spring MVC的@RequestMapping注解下的接口，并通过动态代理方式产生实现类，实现类中做负载均衡调用服务。

二、服务调用OpenFeign

服务网关 | RuoYi

分布式搜索

以下为【高级篇】知识点

三、Sentinel

1. 流量控制（限流规则）

限流是对服务故障的一种预防措施。线程隔离和熔断降级是故障发生后的应对。

热点参数限流，是一种更细粒度的流量控制。

2. 隔离和降级

限流是对服务故障的一种预防措施，但是一旦服务出现故障，就很容易把这些故障传递给其他依赖于它的服务，这样很容易就产生了雪崩。所以，就要靠线程隔离（舱壁模式）和熔断降级手段避免雪崩。

线程隔离之前讲到过：调用者在调用服务提供者时，给每个调用的请求分配独立线程池，出现故障时，最多消耗这个线程池内资源，避免把调用者的所有资源耗尽。

熔断降级：是在调用方这边加入断路器，统计对服务提供者的调用，如果调用的失败比例过高，则熔断该业务，不允许访问该服务的提供者了。

可以看到，不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护，需要在调用方 发起远程调用时做线程隔离、或者服务熔断。而我们的微服务远程调用都是基于Feign来完成的，因此我们需要将Feign与Sentinel整合，在Feign里面实现线程隔离和服务熔断。

2.1 FeignClient整合Sentinel

2.2 线程隔离（舱壁模式）

线程隔离有两种方式实现：

线程池隔离
信号量隔离（Sentinel默认采用）

信号量隔离的特点是？

基于计数器模式，简单，开销小

线程池隔离的特点是？

基于线程池模式，有额外开销，但隔离控制更强

2.3 熔断降级

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

断路器控制熔断和放行是通过状态机来完成的：

状态机包括三个状态：

closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态5秒后会进入half-open状态
half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
- 请求成功：则切换到closed状态
- 请求失败：则切换到open状态

断路器熔断策略有三种：慢调用、异常比例、异常数。

3. 授权规则

3.1 授权规则

授权规则是对请求者的身份进行判断。疑问：前面不是讲了所有请求都要经过GateWay网关路由到微服务嘛，这个时候网关当然可以对请求做身份认证，但万一公司出了内鬼把微服务地址泄露给别人，这个时候他们就可以绕过网关直接访问微服务了，那你网关做的再严密也没用了，微服务赤裸裸的暴露在别人面前，于是，Sentinel的授权规则可以解决这个问题：

如果是从网关过来的请求，让你通过；
如果是从其他地方（浏览器）过来的，则进行拦截。

具体实现可以这样做：

对于经过GateWay网关的请求，在其请求头设置一个值，这样就可以将从网关和浏览器来的请求区分开，从而实现身份的判断。

效果如下：

说明：如果不设置授权规则时，上图中直接访问微服务的请求就不会被拦截哦。自己搭建项目的时候记得验证一下哦。
记住添加请求头时实现的那个接口名称。

3.2 自定义异常结果

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。异常结果都是flow limmiting（限流）。这样不够友好，无法得知是限流还是降级还是授权拦截。

而如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口。

4. 规则持久化

四、分布式事务seata

4.1 理论基础

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

1. CAP定理

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

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

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

视频147的18分钟，老师真正讲清楚了要么CP，要么AP的原因了。

2. BASE理论

在分布式系统下，因为分区不可避免，所以不得不在CP/AP之间作出选择，但是一致性和可用性都非常重要，我一个都不想放弃，那怎么办？BASE理论就是解决这个问题的。

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

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

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

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

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

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

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

4.2 初识Seata

优先官网学习：Seata 是什么？ | Apache Seata

分布式事务 Seata 及其三种模式详解 | Apache Seata

1. Seata基础知识

Seata 中有三大模块，分别是 TM、RM 和 TC。其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。

在 Seata 中，分布式事务的执行流程：

TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态）；
TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
TC 汇总事务信息，决定分布式事务是提交还是回滚；
TC 通知所有 RM 提交/回滚资源，事务二阶段结束；

Seata提供了四种不同的分布式事务解决方案：

XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
TCC模式：最终一致的分阶段事务模式，有业务侵入
AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
SAGA模式：长事务模式，有业务侵入

分布式事务 Seata 及其三种模式详解 | Apache Seata

2. 部署TC服务

TC：维护全局和分支事务的状态，协调全局事务提交或回滚。

配置文件registry.conf修改后内容如下：

registry {# tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等type = "nacos"nacos {# seata tc 服务注册到 nacos的服务名称，可以自定义application = "seata-tc-server"serverAddr = "127.0.0.1:8848"group = "DEFAULT_GROUP"namespace = ""cluster = "SH"username = "nacos"password = "nacos"}
}config {# 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置type = "nacos"# 配置nacos地址等信息nacos {serverAddr = "127.0.0.1:8848"namespace = ""group = "SEATA_GROUP"username = "nacos"password = "nacos"dataId = "seataServer.properties"}
}

3. 微服务集成seata

第一步：在微服务中引入seata依赖：

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-seata</artifactId><exclusions><!--版本较低，1.3.0，因此排除--><exclusion><artifactId>seata-spring-boot-starter</artifactId><groupId>io.seata</groupId></exclusion></exclusions>
</dependency>
<!--seata starter 采用1.4.2版本-->
<dependency><groupId>io.seata</groupId><artifactId>seata-spring-boot-starter</artifactId><version>${seata.version}</version>
</dependency>

第二步如下：

seata:registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址# 参考tc服务自己的registry.conf中的配置type: nacosnacos: # tcserver-addr: 127.0.0.1:8848namespace: ""group: DEFAULT_GROUPapplication: seata-tc-server # tc服务在nacos中的服务名称cluster: SHtx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称service:vgroup-mapping: # 事务组与TC服务cluster的映射关系seata-demo: SH

这两步，每个微服务项目都需要做哦。

总结：

4.3 Seata的四种事务模式详解

1. XA模式

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对XA 规范提供了支持。

XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

一阶段：

事务协调者通知每个事物参与者执行本地事务

本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

事务协调者基于一阶段的报告来判断下一步操作

如果一阶段都成功，则通知所有事务参与者，提交事务

如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

1）Seata的XA模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

2）XA模式优缺点

优点：

事务的强一致性，满足ACID原则。
常用数据库都支持，实现简单，并且没有代码侵入

缺点：

因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
依赖关系型数据库实现事务

3）实现XA模式

Seata的starter已经完成了XA模式的自动装配，实现非常简单，步骤如下：

第一步：修改application.yml文件（每个参与事务的微服务），开启XA模式：

seata:data-source-proxy-mode: XA

第二步：给发起全局事务的入口方法添加@GlobalTransactional注解。

2. AT模式★★★

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

1）AT模式原理

2）AT与XA的区别

简述AT模式与XA模式最大的区别是什么？

XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
XA模式强一致；AT模式最终一致。

3）脏写问题即解决方案

脏写问题，归根结底是没有隔离的原因。

解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。（全局锁是由TC管理的，比数据库DB锁粒度更细，所以比XA模式效率高）

4）优缺点

AT模式的优点：

一阶段完成直接提交事务，释放数据库资源，性能比较好
利用全局锁实现读写隔离
没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

两阶段之间属于软状态，属于最终一致
框架的快照功能会影响性能，但比XA模式要好很多

5）代码实现

AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。只不过，AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。

AT模式是默认的模式。

3. TCC模式★★★

前面学的XA模式、AT模式都能实现一致性和隔离性。XA模式是强一致，AT是最终一致；隔离性上XA是一阶段不提交，基于事务本身的特性来完成隔离，而AT模式是加了全局锁，锁定资源去隔离事务。本质上看，这两种都是通过加锁来实现的。只要加锁，就会有性能损耗，如果要追求极致的性能，就需要学习其他模式。TCC模式就不需要加锁。

1）TCC模式原理

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

Try：资源的检测和预留；
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。

2）优缺点

TCC模式的每个阶段是做什么的？

Try：资源检查和预留
Confirm：业务执行和提交
Cancel：预留资源的释放

TCC的优点是什么？

一阶段完成直接提交事务，释放数据库资源，性能好
相比AT模型，无需生成快照，无需使用全局锁，性能最强
不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

TCC的缺点是什么？

有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
软状态，事务是最终一致
需要考虑Confirm和Cancel的失败情况，做好幂等处理

3）事务悬挂和空回滚

4）代码实现TCC模式

在视频149的57分钟处，老师说，为什么我们只改造一个服务？因为并不是所有的服务都适合TCC模式。比如我们这三个微服务，分别是下单、扣余额、扣库存，“下单”是新增订单的业务逻辑，因此是不需要Try（资源检查和预留）的；“扣库存”是可以用TCC模式实现的，不过这里我们只演示“扣余额”这个服务。那一个分布式事务中，既有AT模式，又有TCC模式，最终能行吗？答案是可以的，它们都属于Seata内部的实现，而且都是分阶段提交，一阶段是直接提交，二阶段做回滚等操作。

4. Saga 模式

四种模式对比★★★

4.4 高可用

1. 高可用集群结构

2. 实现高可用集群

五、分布式缓存Redis

5.1 Redis持久化

1. RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

1）执行时机

RDB持久化在四种情况下会执行：

执行save命令
执行bgsave命令
Redis停机时
触发RDB条件时

save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。
bgsave命令会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。
Redis停机时会执行一次save命令，实现RDB持久化。
Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

2）RDB原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术：

当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据，执行写操作。

3）小结

RDB方式bgsave的基本流程？

fork主进程得到一个子进程，共享内存空间
子进程读取内存数据并写入新的RDB文件
用新RDB文件替换旧的RDB文件

RDB会在什么时候执行？save 60 1000代表什么含义？

默认是服务停止时
代表60秒内至少执行1000次修改则触发RDB

RDB的缺点？

RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
fork子进程、压缩、写出RDB文件都比较耗时

2. AOF持久化

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

3. RDB与AOF对比

5.2 Redis主从

1. 搭建主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

2. 主从数据同步原理

2.1 全量同步

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，流程：

完整流程描述：

slave节点请求增量同步
master节点判断replid，发现不一致，拒绝增量同步
master将完整内存数据生成RDB，发送RDB到slave
slave清空本地数据，加载master的RDB
master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
slave执行接收到的命令，保持与master之间的同步

2.2 增量同步

master怎么知道slave与自己的数据差异在哪里呢?

这就要说到全量同步时的repl_baklog文件了。这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset。slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

2.3 主从同步优化

主从同步可以保证主从数据的一致性，非常重要。

可以从以下几个方面来优化Redis主从就集群：

在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

主从从架构图：

2.4 小结

简述全量同步和增量同步区别？

全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

slave节点第一次连接master节点时
slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

slave节点断开又恢复，并且在repl_baklog中能找到offset时

5.3 Redis哨兵

slave节点宕机恢复后可以找master节点同步数据，那master节点宕机怎么办？Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。

1 哨兵原理

1）哨兵的结构和作用

2）集群监控原理

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

3）集群故障恢复原理

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
最后是判断slave节点的运行id大小，越小优先级越高。

当选出一个新的master后，该如何实现切换呢？

流程如下：

sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
sentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

4）小结

Sentinel的三个作用是什么？

监控
故障转移
通知

Sentinel如何判断一个redis实例是否健康？

每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线
如果大多数sentinel都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

首先选定一个slave作为新的master，执行slaveof no one
然后让所有节点都执行slaveof 新master
修改故障节点配置，添加slaveof 新master

2. 搭建哨兵集群

3. RedisTemplate

在Sentinel集群监管下的Redis主从集群，其节点会因为自动故障转移而发生变化，Redis的客户端必须感知这种变化，及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换。

下面，我们通过一个测试来实现RedisTemplate集成哨兵机制。

第一步：引入课前资料提供的Demo工程，并添加依赖：

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

第二步：在配置文件application.yml中指定redis的sentinel相关信息：

spring:redis:sentinel:master: mymasternodes:- 192.168.150.101:27001- 192.168.150.101:27002- 192.168.150.101:27003

第三步：配置读写分离；

在项目的启动类中，添加一个新的bean：

@Bean
public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
}

这个bean中配置的就是读写策略，包括四种：

MASTER：从主节点读取
MASTER_PREFERRED：优先从master节点读取，master不可用才读取replica
REPLICA：从slave（replica）节点读取
REPLICA _PREFERRED：优先从slave（replica）节点读取，所有的slave都不可用才读取master

5.4 Redis分片集群

分片集群不再需要哨兵了，节点之间会自动路由，具有哨兵机制所有的功能。

更多内容详见讲义。

搭建分片集群
散列插槽
集群伸缩
故障转移
RedisTemplate访问分片集群

六、多级缓存

6.1 传统缓存存在的问题

传统的缓存策略一般是请求到达Tomcat后，先查询Redis，如果未命中则查询数据库，如图：

存在下面的问题：

请求要经过Tomcat处理，Tomcat的性能成为整个系统的瓶颈
Redis缓存失效时，会对数据库产生冲击

6.2 多级缓存

多级缓存就是充分利用请求处理的每个环节，分别添加缓存，减轻Tomcat压力，提升服务性能：

浏览器访问静态资源时，优先读取浏览器本地缓存
访问非静态资源（ajax查询数据）时，访问服务端
请求到达Nginx后，优先读取Nginx本地缓存
如果Nginx本地缓存未命中，则去直接查询Redis（不经过Tomcat）
如果Redis查询未命中，则查询Tomcat
请求进入Tomcat后，优先查询JVM进程缓存
如果JVM进程缓存未命中，则查询数据库

本讲内容，详见讲义：

JVM进程缓存
Lua语法入门
实现多级缓存
缓存同步

七、rabbitmq的高级特性（真清晰）

消息队列在使用过程中，面临着很多实际问题需要思考：

7.1 消息可靠性

消息从发送，到消费者接收，会经理多个过程：

其中的每一步都可能导致消息丢失，常见的丢失原因包括：

发送时丢失：
- 生产者发送的消息未送达exchange
- 消息到达exchange后未到达queue
MQ宕机，queue将消息丢失
consumer接收到消息后未消费就宕机

针对这些问题，RabbitMQ分别给出了解决方案：

生产者确认机制
mq持久化
消费者确认机制
失败重试机制

总结：

如何确保RabbitMQ消息的可靠性？

开启生产者确认机制，确保生产者的消息能到达队列

开启持久化功能，确保消息未消费前在队列中不会丢失

开启消费者确认机制为auto，由spring确认消息处理成功后完成ack

开启消费者失败重试机制，并设置MessageRecoverer，多次重试失败后将消息投递到异常交换机，交由人工处理

7.2 死信交换机

1）私信交换机

什么是死信？

当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：

消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false
消息是一个过期消息，超时无人消费
要投递的队列消息满了，无法投递

如果这个包含死信的队列配置了dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，检查DLX）。

总结

什么样的消息会成为死信？

消息被消费者reject或者返回nack

消息超时未消费

队列满了

死信交换机的使用场景是什么？

如果队列绑定了死信交换机，死信会投递到死信交换机；

可以利用死信交换机收集所有消费者处理失败的消息（死信），交由人工处理，进一步提高消息队列的可靠性。

2）TTL

消息超时的两种方式是？

给队列设置ttl属性，进入队列后超过ttl时间的消息变为死信
给消息设置ttl属性，队列接收到消息超过ttl时间后变为死信

如何实现发送一个消息20秒后消费者才收到消息？

给消息的目标队列指定死信交换机
将消费者监听的队列绑定到死信交换机
发送消息时给消息设置超时时间为20秒

3）延迟队列

利用TTL结合死信交换机，我们实现了消息发出后，消费者延迟收到消息的效果。这种消息模式就称为延迟队列（Delay Queue）模式。

延迟队列的使用场景包括：

延迟发送短信
用户下单，如果用户在15 分钟内未支付，则自动取消
预约工作会议，20分钟后自动通知所有参会人员

因为延迟队列的需求非常多，所以RabbitMQ的官方也推出了一个插件，原生支持延迟队列效果。这个插件就是DelayExchange插件。参考RabbitMQ的插件列表页面：Community Plugins | RabbitMQ

DelayExchange原理

DelayExchange需要将一个交换机声明为delayed类型。当我们发送消息到delayExchange时，流程如下：

接收消息

判断消息是否具备x-delay属性

如果有x-delay属性，说明是延迟消息，持久化到硬盘，读取x-delay值，作为延迟时间

返回routing not found结果给消息发送者

x-delay时间到期后，重新投递消息到指定队列

7.3 惰性队列

1）消息堆积问题

当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。

解决消息堆积有两种思路：

增加更多消费者，提高消费速度。也就是我们之前说的work queue模式
扩大队列容积，提高堆积上限

要提升队列容积，把消息保存在内存中显然是不行的。

2）惰性队列

从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下：

接收到消息后直接存入磁盘而非内存
消费者要消费消息时才会从磁盘中读取并加载到内存
支持数百万条的消息存储

总结

消息堆积问题的解决方案？

队列上绑定多个消费者，提高消费速度

使用惰性队列，可以再mq中保存更多消息

惰性队列的优点有哪些？

基于磁盘存储，消息上限高

没有间歇性的page-out，性能比较稳定

惰性队列的缺点有哪些？

基于磁盘存储，消息时效性会降低

性能受限于磁盘的IO

7.4 MQ集群

RabbitMQ的是基于Erlang语言编写，而Erlang又是一个面向并发的语言，天然支持集群模式。RabbitMQ的集群有两种模式：

普通集群：是一种分布式集群，将队列分散到集群的各个节点，从而提高整个集群的并发能力。
镜像集群：是一种主从集群，普通集群的基础上，添加了主从备份功能，提高集群的数据可用性。

镜像集群虽然支持主从，但主从同步并不是强一致的，某些情况下可能有数据丢失的风险。因此在RabbitMQ的3.8版本以后，推出了新的功能：仲裁队列来代替镜像集群，底层采用Raft协议确保主从的数据一致性。

八、面试篇★★★

8.1 微服务常见面试题

分为微服务篇，RabbitMQ篇，Redis篇。

8.2 Nacos源码分析

分为三大块：服务注册、服务心跳、服务发现。

1. 服务发现

Nacos的注册表结构是什么样的？

答：Nacos是多级存储模型，最外层通过namespace来实现环境隔离，然后是group分组，分组下就是服务，一个服务有可以分为不同的集群，集群中包含多个实例。因此其注册表结构为一个Map，类型是：

Map<String, Map<String, Service>>，

外层key是namespace_id，内层key是group+serviceName.

Service内部维护一个Map，结构是：Map<String,Cluster>，key是clusterName，值是集群信息

Cluster内部维护一个Set集合，元素是Instance类型，代表集群中的多个实例。

Nacos如何保证并发写的安全性？

答：首先，在注册实例时，会对service加锁，不同service之间本身就不存在并发写问题，互不影响。相同service时通过锁来互斥。并且，在更新实例列表时，是基于异步的线程池来完成，而线程池的线程数量为1.

Nacos如何避免并发读写的冲突？

答：Nacos在更新实例列表时，会采用CopyOnWrite技术，首先将Old实例列表拷贝一份，然后更新拷贝的实例列表，再用更新后的实例列表来覆盖旧的实例列表。

Nacos如何应对阿里内部数十万服务的并发写请求？

答：Nacos内部会将服务注册的任务放入阻塞队列，采用线程池异步来完成实例更新，从而提高并发写能力。

2. 服务心跳

Nacos的实例分为临时实例和永久实例两种，可以通过在yaml 文件配置：

spring:application:name: order-servicecloud:nacos:discovery:ephemeral: false # 设置实例为永久实例。true：临时; false：永久server-addr: 192.168.150.1:8845

临时实例基于心跳方式做健康检测，而永久实例则是由Nacos主动探测实例状态。

Nacos的健康检测有两种模式：

临时实例：
- 采用客户端心跳检测模式，心跳周期5秒
- 心跳间隔超过15秒则标记为不健康
- 心跳间隔超过30秒则从服务列表删除
永久实例：
- 采用服务端主动健康检测方式
- 周期为2000 + 5000毫秒内的随机数
- 检测异常只会标记为不健康，不会删除

那么为什么Nacos有临时和永久两种实例呢？

以淘宝为例，双十一大促期间，流量会比平常高出很多，此时服务肯定需要增加更多实例来应对高并发，而这些实例在双十一之后就无需继续使用了，采用临时实例比较合适。而对于服务的一些常备实例，则使用永久实例更合适。

与eureka相比，Nacos与Eureka在临时实例上都是基于心跳模式实现，差别不大，主要是心跳周期不同，eureka是30秒，Nacos是5秒。

另外，Nacos支持永久实例，而Eureka不支持，Eureka只提供了心跳模式的健康监测，而没有主动检测功能。

3. 服务发现

Nacos的服务发现分为两种模式：

模式一：主动拉取模式，消费者定期主动从Nacos拉取服务列表并缓存起来，再服务调用时优先读取本地缓存中的服务列表。
模式二：订阅模式，消费者订阅Nacos中的服务列表，并基于UDP协议来接收服务变更通知。当Nacos中的服务列表更新时，会发送UDP广播给所有订阅者。

与Eureka相比，Nacos的订阅模式服务状态更新更及时，消费者更容易及时发现服务列表的变化，剔除故障服务。

8.3 Sentinel源码分析

1. Sentinel的线程隔离与Hystix的线程隔离有什么差别? （略）

2. Sentinel的限流与Gateway的限流有什么差别？

3. Sentinel源码分析

Sentinel实现限流、隔离、降级、熔断等功能，本质要做的就是两件事情：

统计数据：统计某个资源的访问数据（QPS、RT等信息）
规则判断：判断限流规则、隔离规则、降级规则、熔断规则是否满足

这里的资源就是希望被Sentinel保护的业务，例如项目中定义的controller方法就是默认被Sentinel保护的资源。

实现上述功能的核心骨架是一个叫做ProcessorSlotChain的类。这个类基于责任链模式来设计，将不同的功能（限流、降级、系统保护）封装为一个个的Slot，请求进入后逐个执行即可。

其工作流如图：

责任链中的Slot也分为两大类：

统计数据构建部分（statistic）
- NodeSelectorSlot：负责构建簇点链路中的节点（DefaultNode），将这些节点形成链路树
- ClusterBuilderSlot：负责构建某个资源的ClusterNode，ClusterNode可以保存资源的运行信息（响应时间、QPS、block 数目、线程数、异常数等）以及来源信息（origin名称）
- StatisticSlot：负责统计实时调用数据，包括运行信息、来源信息等
规则判断部分（rule checking）
- AuthoritySlot：负责授权规则（来源控制）
- SystemSlot：负责系统保护规则
- ParamFlowSlot：负责热点参数限流规则
- FlowSlot：负责限流规则
- DegradeSlot：负责降级规则

4. Sentinel官网地址：

basic-implementation | Sentinel

Sentinel工作主流程 · alibaba/Sentinel Wiki · GitHub