《后端开发/外卖/黑马》—常见面试整理

IDEA

• 第一步：首先得在IDEA中创建一个Project（工程、也叫项目），后面统称为工程。
• 第二步：需要在Project中创建Module（模块），一个工程中可以包含多个模块
• 第三步：需要在Module中新建Package（包），一个模块中可以有多个包
• 第四步：需要在Package中新建Class（类），一个包中可以包含多个类

JAVA

什么是面向对象

面向对象的特征（封装、继承、多态、抽象）

什么是字节码？采用字节码的好处？

equal与==的区别

equals() 方法用于比较对象的内容是否相等，而 == 运算符用于比较对象引用是否相同。通常情况下，我们会使用 equals() 方法来判断对象的相等性。

常见的设计模型

https://www.bilibili.com/video/BV1Np4y1z7BU?p=22&vd_source=2a2fe9b853da988c75fe77c1564ca13d

• 单例模式

• 工厂方法模式

• 代理模式

• 观察者模式

在问Spring的时候可能会问到这样一个问题：在Spring框架中都用到了哪些设计模式，并举例说明？

• 工厂设计模式 : Spring使用工厂模式通过 BeanFactory、ApplicationContext 创建 bean 对象。
• 代理设计模式 : Spring AOP 功能的实现。
• 单例设计模式: Spring 中的 Bean 默认都是单例的。
• 包装器设计模式 : 我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。
• 观察者模式: Spring 事件驱动模型就是观察者模式很经典的一个应用。
• 适配器模式:Spring AOP 的增强或通知(Advice)使用到了适配器模式、spring MVC 中也是用到了适配器模式适配Controller。

怎么解决哈希冲突

散列冲突-链表法（拉链）

在散列表中，数组的每个下标位置我们可以称之为桶（bucket）或者槽 （slot），每个桶(槽)会对应一条链表，所有散列值相同的元素都放到相同槽位对应的链表中。

如果有多个key最终的hash值是一样的，就会存入数组的同一个下标中，下标中挂一个链表存入多个数据。

散列时间表复杂度

• 插入操作，通过散列函数计算出对应的散列槽位，将其插入到对应链表中即可，插入的时间复杂度是 O(1)
• 当查找、删除一个元素时，我们同样通过散列函数计算出对应的槽，然后遍历链表查找或者删除 平均情况下基于链表法解决冲突时查询的时间复杂度是O(1) 散列表可能会退化为链表,查询的时间复杂度就从 O(1) 退化为 O(n)
• 将链表法中的链表改造为其他高效的动态数据结构，比如红黑树，查询的时间复杂度是 O(logn)

框架篇

Spring MVC 是 Spring 中的一个很重要的模块，主要赋予 Spring 快速构建 MVC 架构的 Web 程序的能力。MVC 是模型(Model)、视图(View)、控制器(Controller)的简写，其核心思想是通过将业务逻辑、数据、显示分离来组织代码。

1. Spring refresh 流程

4. Spring 事务

Spring中的事务如何实现

spring实现的事务本质就是aop完成，对方法前后进行拦截，在执行方法之前开启事务，在执行完目标方法之后根据执行情况提交或者回滚事务。

Spring中事务失效的场景

嗯！这个在项目中之前遇到过

• 第一，如果方法上异常捕获处理，自己处理了异常，没有抛出，就会导致事务失效，所以一般处理了异常以后，别忘了抛出去就行

• 第二，如果方法抛出检查异常，如果报错也会导致事务失效，最后在 spring事务的注解上，就是@Transactional上配置rollbackFor属性为 Exception，这样别管是什么异常，都会回滚事务

  

• 第三，如果方法上不是public修饰的，也会导致事务失效

5. Spring MVC 执行流程

6. Spring 注解

第一类是：声明bean，有@Component、@Service、@Repository、 @Controller

第二类是：依赖注入相关的，有@Autowired、@Qualifier、@Resourse

第三类是：设置作用域 @Scope

第四类是：spring配置相关的，比如@Configuration，@ComponentScan 和 @Bean

第五类是：跟aop相关做增强的注解 @Aspect，@Before，@After， @Around，@Pointcut

Spring注解

SpringMVC注解

SpringBoot注解

SpringBoot 起步依赖

目的：解决spring框架当中依赖配置繁琐的问题。

依靠：maven的依赖传递。举个例子，如果a依赖b，b依赖c，则引入a时，bc也被引入进来。

7. SpringBoot 自动配置原理

SpringBoot的自动配置：是当spring容器启动后，一些配置类、bean对象就自动存入到了IOC容器中，不需要我们手动去声明，

从而简化了开发，省去了繁琐的配置操作。

简化bean的声明和bean的配置。

方案一：@ComponentScan 组件扫描

@ComponentScan({"com.example","com.itheima","com.google","org.springframework","org.mybatis",...})
@SpringBootApplication
 public class SpringbootWebConfig2Application {

}

使用繁琐、性能低

方案二：@Import 导入。

使用@Import导入的类会被Spring加载到IOC容器中，导入形式主要有以下几种：

• 导入 普通类
• 导入 配置类 @configuration
• 导入 ImportSelector 接口实现类
• @EnableXxxx注解，封装@Import注解 (方便，优雅)

@Import({TokenParser.class, HeaderConfig.class})
@SpringBootApplication
public class SpringbootWebConfig2Application {
}

1. 在Spring Boot项目中的引导类上有一个注解@SpringBootApplication，这个 注解是对三个注解进行了封装，分别是

• @SpringBootConfiguration ：该注解与 @Configuration 注解作用相同，用来声明当前也是一个配置类。
• @EnableAutoConfiguration：SpringBoot实现自动化配置的核心注解。
• @ComponentScan ：组件扫描，默认扫描当前引导类所在包及其子包。

2. 其中 @EnableAutoConfiguration 是实现自动化配置的核心注解。

​ 该注解通过 @Import 注解导入对应的配置选择器。关键的是内部就是读取了 该项目和该项目引用的Jar包的的classpath路径下METAINF/spring.factories文件中的所配置的类的全类名。 在这些配置类中所定义的Bean会根据条件注解所指定的条件来决定是否需要将其导入到Spring容器中。

3. 一般条件判断会有像 @ConditionalOnClass 注解，判断是否有对应的 class文件，如果有则加载该类，把这个配置类的所有的Bean放入spring容器中使用。

@ConditionalOnClass 注解

作用：按照一定的条件进行判断，在满足给定条件后才会注册对应的bean对象到Spring IOC容器中。

位置：方法、类

**@Conditional **

SpringBoot会根据@Conditional注解进行条件装配

本身是一个父注解，派生出大量的子注解：

@ConditionalOnClass：判断环境中是否有对应字节码文件，才注册bean到IOC容器。

@ConditionalOnMissingBean：判断环境中没有对应的bean（类型或名称），才注册bean到IOC容器。

@ConditionalOnProperty：判断配置文件中有对应属性和值，才注册bean到IOC容器。

@Bean
@ConditionalOnClass(name = "io.jsonwebtoken.Jwts") //当前环境存在指定的这个类时，才声明该bean ,才会将该bean加入IoC容器中
public HeaderParser headerParser(){...}

@Bean
@ConditionalOnMissingBean //当不存在当前类型的bean时，才声明该bean 
public HeaderParser headerParser(){...}

@Bean
@ConditionalOnProperty(name = "name",havingValue = "itheima") //application.yml
//配置文件中存在对应的属性和值，才注册bean到IOC容器。
public HeaderParser headerParser(){...}

自定义starter

依赖管理功能

自动配置功能

需求：自定义aliyun-oss-spring-boot-starter（仅进行依赖管理，没有任何代码），完成阿里云OSS操作工具类 AliyunOSSUtils 的自动配置。

目标：引入起步依赖引入之后，要想使用阿里云OSS，注入 AliyunOSSUtils直接使用即可。

1. 创建 aliyun-oss-spring-boot-starter 模块
2. 创建 aliyun-oss-spring-boot-autoconfigure 模块，在starter中引入该模块
3. 在 aliyun-oss-spring-boot-autoconfigure 模块中的定义自动配置功能，并定义自动配置文件 META-INF/spring/xxxx.imports

Spring IOC

IOC控制反转：（Inversion of Control）

是一种设计思想，而不是一个具体的技术实现。

指的是将对象创建的控制权由应用程序自身交给外部容器，这个容器呢就是我们常说的ioc容器或spring容器。

例如：现有类 A 依赖于类 B

- **传统的开发方式** ：往往是在类 A 中手动通过 new 关键字来 new 一个 B 的对象出来
- **使用 IoC 思想的开发方式** ：不通过 new 关键字来创建对象，而是通过 IoC 容器(Spring 框架) 来帮助我们实例化对象。我们需要哪个对象，直接从 IoC 容器里面去取即可。

IOC解决了什么问题

IoC 的思想就是两方之间不互相依赖，由第三方容器来管理相关资源。这样有什么好处呢？

1. 对象之间的耦合度或者说依赖程度降低；
2. 资源变的容易管理；比如你用 Spring 容器提供的话很容易就可以实现一个单例。

为什么叫控制反转？

• 控制：指的是对象创建（实例化、管理）的权力
• 反转：控制权交给外部环境（Spring 框架、IoC 容器）

声明为spring容器当中的bean对象。

DI依赖注入

Dependency Injection

指的是容器为程序提供运行时所需要的资源。

IoC 最常见以及最合理的实现方式叫做依赖注入。

Spring Bean

Bean 代指的是那些被 IoC 容器所管理的对象。

将类声明为 Bean 的注解

• @Component：通用的注解，可标注任意类为 Spring 组件。如果一个 Bean 不知道属于哪个层，可以使用@Component 注解标注。
• @Repository : 对应持久层即 Dao 层，主要用于数据库相关操作。
• @Service : 对应服务层，主要涉及一些复杂的逻辑，需要用到 Dao 层。
• @Controller : 对应 Spring MVC 控制层，主要用于接受用户请求并调用 Service 层返回数据给前端页面。

@Component 和 @Bean 的区别

• @Component 注解作用于类，而@Bean注解作用于方法。

注入 Bean 的注解有哪些

Spring 内置的 @Autowired 以及 JDK 内置的 @Resource 和 @Inject 都可以用于注入 Bean。

@Autowired 和 @Resource 的区别

Autowired 属于 Spring 内置的注解，默认的注入方式为byType（根据类型进行匹配），也就是说会优先根据接口类型去匹配并注入 Bean （接口的实现类）。

但当一个接口存在多个实现类的话，byType这种方式就无法正确注入对象。这种情况下，注入方式会变为 byName（根据名称进行匹配），这个名称通常就是类名（首字母小写）。比如说下面代码中的 smsService 就是我这里所说的名称。

// smsService 就是我们上面所说的名称
@Autowired
private SmsService smsService;

举个例子，SmsService 接口有两个实现类: SmsServiceImpl1和 SmsServiceImpl2，且它们都已经被 Spring 容器所管理。

// 报错，byName 和 byType 都无法匹配到 bean
@Autowired
private SmsService smsService;
// 正确注入 SmsServiceImpl1 对象对应的 bean
@Autowired
private SmsService smsServiceImpl1;
// 正确注入  SmsServiceImpl1 对象对应的 bean
// smsServiceImpl1 就是我们上面所说的名称
@Autowired
@Qualifier(value = "smsServiceImpl1")// 指定了要注入的bean的名称（即"smsServiceImpl1"）
private SmsService smsService;

@Resource属于 JDK 提供的注解，默认注入方式为 byName。如果无法通过名称匹配到对应的 Bean 的话，注入方式会变为byType。

@Resource 有两个比较重要且日常开发常用的属性：name（名称）、type（类型）。

SmsServiceImpl1和 SmsServiceImpl2是类名，默认情况下，Spring 会使用类名（首字母小写）作为 bean 名称。

// 报错，byName 和 byType 都无法匹配到 bean
@Resource
private SmsService smsService;
// 正确注入 SmsServiceImpl1 对象对应的 bean
@Resource
private SmsService smsServiceImpl1;
// 正确注入 SmsServiceImpl1 对象对应的 bean（比较推荐这种方式）
@Resource(name = "smsServiceImpl1")
private SmsService smsService;

总结一下：

• @Autowired 是 Spring 提供的注解，@Resource 是 JDK 提供的注解。
• Autowired 默认的注入方式为byType（根据类型进行匹配），@Resource默认注入方式为 byName（根据名称进行匹配）。
• 当一个接口存在多个实现类的情况下，@Autowired 和@Resource都需要通过名称才能正确匹配到对应的 Bean。Autowired 可以通过 @Qualifier 注解来显式指定名称，@Resource可以通过 name 属性来显式指定名称。
• @Autowired 支持在构造函数、方法、字段和参数上使用。@Resource 主要用于字段和方法上的注入，不支持在构造函数或参数上使用。

bean生命周期

首先会通过一个非常重要的类，叫做BeanDefinition获取bean的定义信息， 这里面就封装了bean的所有信息，比如，类的全路径，是否是延迟加载，是否是单例等等这些信息

1. 在创建bean的时候，第一步是调用构造函数实例化bean
2. 第二步是bean的依赖注入，比如一些set方法注入，像平时开发用的 @Autowire都是这一步完成
3. 第三步是处理Aware接口，如果某一个bean实现了Aware接口就会重写方法 执行
4. 第四步是bean的后置处理器BeanPostProcessor
5. 第五步是初始化方法，比如实现了接口InitializingBean或者自定义方法 init-method标签或@PostContruct
6. 第六步是执行了bean的后置处理器BeanPostProcessor，主要是对bean进行增强，有可能在这里产生代理对象
7. 销毁bean

Bean 的作用域有哪些

Spring 中 Bean 的作用域通常有下面几种：

• singleton : IoC 容器中只有唯一的 bean 实例。Spring 中的 bean 默认都是单例的，是对单例设计模式的应用。
• prototype : 每次获取都会创建一个新的 bean 实例。也就是说，连续 getBean() 两次，得到的是不同的 Bean 实例。

Spring框架中的单例bean是线程安全的吗？

不是线程安全的，当多用户同时请求一个服务时，容器会给每一个请求分配一个线程，这是多个线程会并发执行该请求对应的业务逻辑（成员方法），如果该处理逻辑中有对该单列状态的修改（体现为该单例的成员属性），则必须考虑线程同步问题。

比如：

• 我们通常在项目中使用的Spring bean都是不可可变的状态(比如 Service类和DAO类)，所以在某种程度上说Spring的单例bean是线程安全的。
• 如果你的bean有多种状态的话（比如 View Model对象），就需要自行保证 程安全。最浅显的解决办法就是将多态bean的作用由“singleton”变更为 “prototype”。

Spring框架中有一个@Scope注解，默认的值就是singleton，单例的。
因为一般在spring的bean的中都是注入无状态的对象，没有线程安全问题，如果在bean中定义了可修改的成员变量，是要考虑线程安全问题的，可以使用多例或者加锁来解决。

Spring 框架中的 Bean 是否线程安全，取决于其作用域和状态。

我们这里以最常用的两种作用域 prototype 和 singleton 为例介绍。

几乎所有场景的 Bean 作用域都是使用默认的 singleton ，重点关注 singleton 作用域即可。

• prototype 作用域下，每次获取都会创建一个新的 bean 实例，不存在资源竞争问题，所以不存在线程安全问题。
• singleton 作用域下，IoC 容器中只有唯一的 bean 实例，可能会存在资源竞争问题（取决于 Bean 是否有状态）。如果这个 bean 是有状态的话，那就存在线程安全问题（有状态 Bean 是指包含可变的成员变量的对象）。

不过，大部分 Bean 实际都是无状态（没有定义可变的成员变量）的（比如 Dao、Service），这种情况下， Bean 是线程安全的。

对于有状态单例 Bean 的线程安全问题，常见的有两种解决办法：

1. 在 Bean 中尽量避免定义可变的成员变量。
2. 在类中定义一个 ThreadLocal 成员变量，将需要的可变成员变量保存在 ThreadLocal 中（推荐的一种方式）。

Spring bean 循环依赖

Spring中的循环引用

在创建A对象的时候同时需要使用的B对象，而在创建B对象的同时需要使用到A对象。

循环依赖其实就是循环引用,是两个或两个以上的bean互相持有对方,最终形成闭环。比如A依赖于B,B依赖于A 。

循环依赖在spring中是允许存在，spring框架依据三级缓存已经解决了大部分的循环依赖。

Spring 创建 Bean 的流程：

1. 先去 一级缓存 singletonObjects 中获取，存在就返回；
2. 如果不存在或者对象正在创建中，于是去 二级缓存 earlySingletonObjects 中获取；
3. 如果还没有获取到，就去 三级缓存 singletonFactories 中获取，通过执行 ObjectFacotry 的 getObject() 就可以获取该对象，获取成功之后，从三级缓存移除，并将该对象加入到二级缓存中。

①一级缓存（singletonObjects）：单例池，缓存已经经历了完整的生命周期，已经初始化完成的 bean对象

②二级缓存（earlySingletonObjects）：缓存早期的bean对象（生命周期还没走完，也就是三级缓存中ObjectFactory产生的对象，不能解决代理对象）

③三级缓存（singletonFactories）：缓存的是ObjectFactory，表示对象工厂，用来创建某个对象的，可以生成原始 Bean 对象或者代理对象。

具体解决流程清

第一，先实例A对象，同时会创建ObjectFactory对象存入三级缓存 singletonFactories

第二，A在初始化的时候需要B对象，这个走B的创建的逻辑

第三，B实例化完成，也会创建ObjectFactory对象存入三级缓存 singletonFactories

第四，B需要注入A，通过三级缓存中获取ObjectFactory来生成一个A的对象 同时存入二级缓存，这个是有两种情况，一个是可能是A的普通对象，另外 一个是A的代理对象，都可以让ObjectFactory来生产对应的对象，这也是三 级缓存的关键

第五，B通过从通过二级缓存earlySingletonObjects 获得到A的对象后可以正 常注入，B创建成功，存入一级缓存singletonObjects

第六，回到A对象初始化，因为B对象已经创建完成，则可以直接注入B，A 创建成功存入一次缓存singletonObjects

第七，二级缓存中的临时对象A清除

构造方法出现循环依赖怎么解决？

由于bean的生命周期中构造函数是第一个执行的，spring框架并不能解决构造函数的的依赖注入。

可以在代码形参中使用@Lazy懒加载，什么时候需要对象再进行 bean对象的创建。

Spring AoP

AOP(Aspect-Oriented Programming:面向切面编程)

能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任（例如事务处理、日志管理、权限控制等）封装起来，

便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。

你们项目中有没有使用到AOP

候选人： 我们当时在后台管理系统中，就是使用aop来记录了系统的操作日志

主要思路是这样的，使用aop中的环绕通知+切点表达式(找到记录日志的方法)，这个表达式就是要 找到要记录日志的方法，然后通过环绕通知的参数获取请求方法的参数，比 如类信息、方法信息、注解、请求方式等，获取到这些参数以后，保存到数据库。

	以日志记录为例进行介绍，假如我们需要对某些方法进行统一格式的日志记录，没有使用 AOP 技术之前，我们需要挨个写日志记录的逻辑代码，全是重复的的逻辑。
	使用 AOP 技术之后，我们可以将日志记录的逻辑封装成一个切面，然后通过切入点和通知来指定在哪些方法需要执行日志记录的操作。

Spring MVC

MVC 是模型(Model)、视图(View)、控制器(Controller)的简写，其核心思想是通过将业务逻辑、数据、显示分离来组织代码。

Spring 框架的设计模式

Spring事物

MyBatis

Mybatis是持久层框架

MyBatis执行流程

①读取MyBatis配置文件：**mybatis-config.xml加载运行环境和映射文件 **（连接哪个数据库，加载mapper文件）

②构造会话工厂SqlSessionFactory，一个项目只需要一个，单例的，一般由 spring进行管理

③会话工厂创建SqlSession对象，这里面就含了执行SQL语句的所有方法

④真正执行数据库操作接口，Executor执行器，也负责查询缓存的维护

⑤Executor接口的执行方法中有一个MappedStatement类型的参数，封装了 映射信息

⑥输入参数映射 java参数类型 --> 转换为 数据库支持的类型

⑦输出结果映射 数据库支持的类型 --> 转换为 java参数类型

Mybatis是否支持延迟加载？

是支持的~

延迟加载：就是在需要用到数据时才进行加载，不需要用到数据时就不加载数据。

Mybatis支持一对一关联对象和一对多关联集合对象的延迟加载

在Mybatis配置文件中，可以配置是否启用延迟加载 lazyLoadingEnabled=true|false，默认是关闭的

延迟加载的底层原理

延迟加载在底层主要使用的CGLIB动态代理完成的

第一是，使用CGLIB创建目标对象的代理对象，这里的目标对象就是开启了 延迟加载的mapper

第二个是当调用目标方法时，进入拦截器invoke方法，发现目标方法是null 值，再执行sql查询

第三个是获取数据以后，调用set方法设置属性值，再继续查询目标方法，就有值了

Mybatis的一级、二级缓存用过吗？

mybatis的一级缓存: 基于 PerpetualCache 的 HashMap 本地缓存，其存储作用域为 SQL Session，当Session进行flush或close之后，该Session中的所有Cache 就将清空，默认打开一级缓存

二级缓存是基于namespace和mapper的作用域起作用的，不是依赖于SQL session，默认也是采用 PerpetualCache，HashMap 存储。 如果想要开启二级缓存需要在全局配置文件和映射文件中开启配置才行。

二级缓存什么时候会清理缓存中的数据

当某一个作用域(一级缓存 Session/二级缓存Namespaces)的进行了新增、修改、删除操作后，默认该作用域下所有 select 中的缓存将被 clear

MySQL

基础篇

MySQL 执行一条 SQL 查询语句的流程，也从图中可以看到 MySQL 内部架构里的各个功能模块。

MySQL 的架构共分为两层：Server 层和存储引擎层。

• Server 层负责建立连接、分析和执行 SQL。MySQL 大多数的核心功能模块都在这实现，主要包括连接器，查询缓存、解析器、预处理器、优化器、执行器等。另外，所有的内置函数（如日期、时间、数学和加密函数等）和所有跨存储引擎的功能（如存储过程、触发器、视图等。）都在 Server 层实现。
• 存储引擎层负责数据的存储和提取。支持 InnoDB、MyISAM、Memory 等多个存储引擎，不同的存储引擎共用一个 Server 层。现在最常用的存储引擎是 InnoDB，从 MySQL 5.5 版本开始， InnoDB 成为了 MySQL 的默认存储引擎。我们常说的索引数据结构，就是由存储引擎层实现的，不同的存储引擎支持的索引类型也不相同，比如 InnoDB 支持索引类型是 B+树 ，且是默认使用，也就是说在数据表中创建的主键索引和二级索引默认使用的是 B+ 树索引。

总结：

• 连接器：建立连接，管理连接、校验用户身份；

• 查询缓存：查询语句如果命中查询缓存则直接返回，否则继续往下执行。MySQL 8.0 已删除该模块；

• 解析 SQL，通过解析器对 SQL 查询语句进行词法分析、语法分析，然后构建语法树，方便后续模块读取表名、字段、语句类型；

• 执行 SQL：执行 SQL 共有三个阶段：

  • 预处理阶段：检查表或字段是否存在；将 select * 中的 * 符号扩展为表上的所有列。
  • 优化阶段：基于查询成本的考虑， 选择查询成本最小的执行计划；
  • 执行阶段：根据执行计划执行 SQL 查询语句，从存储引擎读取记录，返回给客户端；

⼀条SQL查询语句是如何执行的

select * from product where id = 1;

• 1连接器：建立连接，管理连接、校验用户身份；

如果你在 Linux 操作系统里要使用 MySQL，那你第一步肯定是要先连接 MySQL 服务，然后才能执行 SQL 语句，普遍我们都是使用下面这条命令进行连接：

# -h 指定 MySQL 服务得 IP 地址，如果是连接本地的 MySQL服务，可以不用这个参数；
# -u 指定用户名，管理员角色名为 root；
# -p 指定密码，如果命令行中不填写密码（为了密码安全，建议不要在命令行写密码），就需要在交互对话里面输入密码
mysql -h$ip -u$user -p

连接的过程需要先经过 TCP 三次握手，因为 MySQL 是基于 TCP 协议进行传输的，如果 MySQL 服务并没有启动，则会收到如下的报错：

如果 MySQL 服务正常运行，完成 TCP 连接的建立后，连接器就要开始验证你的用户名和密码，如果用户名或密码不对，就收到一个"Access denied for user"的错误，然后客户端程序结束执行。

如果用户密码都没有问题，连接器就会获取该用户的权限，然后保存起来，后续该用户在此连接里的任何操作，都会基于连接开始时读到的权限进行权限逻辑的判断。

所以，如果一个用户已经建立了连接，即使管理员中途修改了该用户的权限，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。

如何查看 MySQL 服务被多少个客户端连接了？

如果你想知道当前 MySQL 服务被多少个客户端连接了，你可以执行 show processlist 命令进行查看。

比如上图的显示结果，共有两个用户名为 root 的用户连接了 MySQL 服务，其中 id 为 6 的用户的 Command 列的状态为 Sleep ，这意味着该用户连接完 MySQL 服务就没有再执行过任何命令，也就是说这是一个空闲的连接，并且空闲的时长是 736 秒（ Time 列）。

空闲连接会一直占用着吗？

当然不是了，MySQL 定义了空闲连接的最大空闲时长，由 wait_timeout 参数控制的，默认值是 8 小时（28880秒），如果空闲连接超过了这个时间，连接器就会自动将它断开。

mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.00 sec)

当然，我们自己也可以手动断开空闲的连接，使用的是 kill connection + id 的命令。

mysql> kill connection +6;
Query OK, 0 rows affected (0.00 sec)

一个处于空闲状态的连接被服务端主动断开后，这个客户端并不会马上知道，等到客户端在发起下一个请求的时候，才会收到这样的报错“ERROR 2013 (HY000): Lost connection to MySQL server during query”。

MySQL 的连接数有限制吗？

MySQL 服务支持的最大连接数由 max_connections 参数控制，比如我的 MySQL 服务默认是 151 个,超过这个值，系统就会拒绝接下来的连接请求，并报错提示“Too many connections”。

mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.00 sec)

MySQL 的连接也跟 HTTP 一样，有短连接和长连接的概念，它们的区别如下：

// 短连接
连接 mysql 服务（TCP 三次握手）
执行sql
断开 mysql 服务（TCP 四次挥手）

// 长连接
连接 mysql 服务（TCP 三次握手）
执行sql
执行sql
执行sql
....
断开 mysql 服务（TCP 四次挥手）

可以看到，使用长连接的好处就是可以减少建立连接和断开连接的过程，所以一般是推荐使用长连接。

但是，使用长连接后可能会占用内存增多，因为 MySQL 在执行查询过程中临时使用内存管理连接对象，这些连接对象资源只有在连接断开时才会释放。如果长连接累计很多，将导致 MySQL 服务占用内存太大，有可能会被系统强制杀掉，这样会发生 MySQL 服务异常重启的现象。

怎么解决长连接占用内存的问题？

有两种解决方式。

第一种，定期断开长连接。既然断开连接后就会释放连接占用的内存资源，那么我们可以定期断开长连接。

第二种，客户端主动重置连接。MySQL 5.7 版本实现了 mysql_reset_connection() 函数的接口，注意这是接口函数不是命令，那么当客户端执行了一个很大的操作后，在代码里调用 mysql_reset_connection 函数来重置连接，达到释放内存的效果。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

至此，连接器的工作做完了，简单总结一下：

• 与客户端进行 TCP 三次握手建立连接；

• 校验客户端的用户名和密码，如果用户名或密码不对，则会报错；

• 如果用户名和密码都对了，会读取该用户的权限，然后后面的权限逻辑判断都基于此时读取到的权限；

• 2查询缓存：查询语句如果命中查询缓存则直接返回，否则继续往下执行。MySQL 8.0 已删除该模块；

连接器得工作完成后，客户端就可以向 MySQL 服务发送 SQL 语句了，MySQL 服务收到 SQL 语句后，就会解析出 SQL 语句的第一个字段，看看是什么类型的语句。

如果 SQL 是查询语句（select 语句），MySQL 就会先去查询缓存（ Query Cache ）里查找缓存数据，看看之前有没有执行过这一条命令，这个查询缓存是以 key-value 形式保存在内存中的，key 为 SQL 查询语句，value 为 SQL 语句查询的结果。

如果查询的语句命中查询缓存，那么就会直接返回 value 给客户端。如果查询的语句没有命中查询缓存中，那么就要往下继续执行，等执行完后，查询的结果就会被存入查询缓存中。

这么看，查询缓存还挺有用，但是其实查询缓存挺鸡肋的。

对于更新比较频繁的表，查询缓存的命中率很低的，因为只要一个表有更新操作，那么这个表的查询缓存就会被清空。如果刚缓存了一个查询结果很大的数据，还没被使用的时候，刚好这个表有更新操作，查询缓冲就被清空了，相当于缓存了个寂寞。

所以，MySQL 8.0 版本直接将查询缓存删掉了，也就是说 MySQL 8.0 开始，执行一条 SQL 查询语句，不会再走到查询缓存这个阶段了。

对于 MySQL 8.0 之前的版本，如果想关闭查询缓存，我们可以通过将参数 query_cache_type 设置成 DEMAND。

TIP

这里说的查询缓存是 server 层的，也就是 MySQL 8.0 版本移除的是 server 层的查询缓存，并不是 Innodb 存储引擎中的 buffer pool。

• 3解析 SQL，通过解析器对 SQL 查询语句进行词法分析、语法分析，然后构建语法树，方便后续模块读取表名、字段、语句类型；

解析器

解析器会做如下两件事情。

第一件事情，词法分析。MySQL 会根据你输入的字符串识别出关键字出来，例如，SQL语句 select username from userinfo，在分析之后，会得到4个Token，其中有2个Keyword，分别为select和from：

关键字	非关键字	关键字	非关键字
select	username	from	userinfo

第二件事情，语法分析。根据词法分析的结果，语法解析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法，如果没问题就会构建出 SQL 语法树，这样方便后面模块获取 SQL 类型、表名、字段名、 where 条件等等。

如果我们输入的 SQL 语句语法不对，就会在解析器这个阶段报错。比如，我下面这条查询语句，把 from 写成了 form，这时 MySQL 解析器就会给报错。

但是注意，表不存在或者字段不存在，并不是在解析器里做的，《MySQL 45 讲》说是在解析器做的，但是经过我和朋友看 MySQL 源码（5.7和8.0）得出结论是解析器只负责检查语法和构建语法树，但是不会去查表或者字段存不存在。

那到底谁来做检测表和字段是否存在的工作呢？别急，接下来就是了。

• 4执行 SQL：执行 SQL 共有三个阶段：

  • 预处理阶段：检查表或字段是否存在；将 select * 中的 * 符号扩展为表上的所有列。

  我们先来说说预处理阶段做了什么事情。

  • 检查 SQL 查询语句中的表或者字段是否存在；
  • 将 select * 中的 * 符号，扩展为表上的所有列；

  我下面这条查询语句，test 这张表是不存在的，这时 MySQL 就会在执行 SQL 查询语句的 prepare 阶段中报错。

  mysql> select * from test;
  ERROR 1146 (42S02): Table 'mysql.test' doesn't exist
  

  • 优化阶段：基于查询成本的考虑， 选择查询成本最小的执行计划；

  经过预处理阶段后，还需要为 SQL 查询语句先制定一个执行计划，这个工作交由「优化器」来完成的。

  优化器主要负责将 SQL 查询语句的执行方案确定下来，比如在表里面有多个索引的时候，优化器会基于查询成本的考虑，来决定选择使用哪个索引。

  当然，我们本次的查询语句（select * from product where id = 1）很简单，就是选择使用主键索引。

  要想知道优化器选择了哪个索引，我们可以在查询语句最前面加个 explain 命令，这样就会输出这条 SQL 语句的执行计划，然后执行计划中的 key 就表示执行过程中使用了哪个索引，比如下图的 key 为 PRIMARY 就是使用了主键索引。

  

  如果查询语句的执行计划里的 key 为 null 说明没有使用索引，那就会全表扫描（type = ALL），这种查询扫描的方式是效率最低档次的，如下图：

  

  这张 product 表只有一个索引就是主键，现在我在表中将 name 设置为普通索引（二级索引）。

  

  这时 product 表就有主键索引（id）和普通索引（name）。假设执行了这条查询语句：

  select id from product where id > 1  and name like 'i%';
  

  这条查询语句的结果既可以使用主键索引，也可以使用普通索引，但是执行的效率会不同。这时，就需要优化器来决定使用哪个索引了。

  很显然这条查询语句是覆盖索引，直接在二级索引就能查找到结果（因为二级索引的 B+ 树的叶子节点的数据存储的是主键值），就没必要在主键索引查找了，因为查询主键索引的 B+ 树的成本会比查询二级索引的 B+ 的成本大，优化器基于查询成本的考虑，会选择查询代价小的普通索引。

  在下图中执行计划，我们可以看到，执行过程中使用了普通索引（name），Exta 为 Using index，这就是表明使用了覆盖索引优化。

  

  • 执行阶段：根据执行计划执行 SQL 查询语句，从存储引擎读取记录，返回给客户端；

经历完优化器后，就确定了执行方案，接下来 MySQL 就真正开始执行语句了，这个工作是由「执行器」完成的。在执行的过程中，执行器就会和存储引擎交互了，交互是以记录为单位的。

接下来，用三种方式执行过程，跟大家说一下执行器和存储引擎的交互过程（PS ：为了写好这一部分，特地去看 MySQL 源码，也是第一次看哈哈）。

• 主键索引查询
• 全表扫描
• 索引下推

主键索引查询

以本文开头查询语句为例，看看执行器是怎么工作的。

select * from product where id = 1;

这条查询语句的查询条件用到了主键索引，而且是等值查询，同时主键 id 是唯一，不会有 id 相同的记录，所以优化器决定选用访问类型为 const 进行查询，也就是使用主键索引查询一条记录，那么执行器与存储引擎的执行流程是这样的：

• 执行器第一次查询，会调用 read_first_record 函数指针指向的函数，因为优化器选择的访问类型为 const，这个函数指针被指向为 InnoDB 引擎索引查询的接口，把条件 id = 1 交给存储引擎，让存储引擎定位符合条件的第一条记录。
• 存储引擎通过主键索引的 B+ 树结构定位到 id = 1的第一条记录，如果记录是不存在的，就会向执行器上报记录找不到的错误，然后查询结束。如果记录是存在的，就会将记录返回给执行器；
• 执行器从存储引擎读到记录后，接着判断记录是否符合查询条件，如果符合则发送给客户端，如果不符合则跳过该记录。
• 执行器查询的过程是一个 while 循环，所以还会再查一次，但是这次因为不是第一次查询了，所以会调用 read_record 函数指针指向的函数，因为优化器选择的访问类型为 const，这个函数指针被指向为一个永远返回 - 1 的函数，所以当调用该函数的时候，执行器就退出循环，也就是结束查询了。

至此，这个语句就执行完成了。

全表扫描

举个全表扫描的例子：

select * from product where name = 'iphone';

这条查询语句的查询条件没有用到索引，所以优化器决定选用访问类型为 ALL 进行查询，也就是全表扫描的方式查询，那么这时执行器与存储引擎的执行流程是这样的：

• 执行器第一次查询，会调用 read_first_record 函数指针指向的函数，因为优化器选择的访问类型为 all，这个函数指针被指向为 InnoDB 引擎全扫描的接口，让存储引擎读取表中的第一条记录；
• 执行器会判断读到的这条记录的 name 是不是 iphone，如果不是则跳过；如果是则将记录发给客户的（是的没错，Server 层每从存储引擎读到一条记录就会发送给客户端，之所以客户端显示的时候是直接显示所有记录的，是因为客户端是等查询语句查询完成后，才会显示出所有的记录）。
• 执行器查询的过程是一个 while 循环，所以还会再查一次，会调用 read_record 函数指针指向的函数，因为优化器选择的访问类型为 all，read_record 函数指针指向的还是 InnoDB 引擎全扫描的接口，所以接着向存储引擎层要求继续读刚才那条记录的下一条记录，存储引擎把下一条记录取出后就将其返回给执行器（Server层），执行器继续判断条件，不符合查询条件即跳过该记录，否则发送到客户端；
• 一直重复上述过程，直到存储引擎把表中的所有记录读完，然后向执行器（Server层） 返回了读取完毕的信息；
• 执行器收到存储引擎报告的查询完毕的信息，退出循环，停止查询。

至此，这个语句就执行完成了。

索引下推

在这部分非常适合讲索引下推（MySQL 5.6 推出的查询优化策略），这样大家能清楚的知道，「下推」这个动作，下推到了哪里。

索引下推能够减少二级索引在查询时的回表操作，提高查询的效率，因为它将 Server 层部分负责的事情，交给存储引擎层去处理了。

举一个具体的例子，方便大家理解，这里一张用户表如下，我对 age 和 reward 字段建立了联合索引（age，reward）：

现在有下面这条查询语句：

select * from t_user  where age > 20 and reward = 100000;

联合索引当遇到范围查询 (>、<) 就会停止匹配，也就是 age 字段能用到联合索引，但是 reward 字段则无法利用到索引。

那么，不使用索引下推（MySQL 5.6 之前的版本）时，执行器与存储引擎的执行流程是这样的：

• Server 层首先调用存储引擎的接口定位到满足查询条件的第一条二级索引记录，也就是定位到 age > 20 的第一条记录；
• 存储引擎根据二级索引的 B+ 树快速定位到这条记录后，获取主键值，然后进行回表操作，将完整的记录返回给 Server 层；
• Server 层在判断该记录的 reward 是否等于 100000，如果成立则将其发送给客户端；否则跳过该记录；
• 接着，继续向存储引擎索要下一条记录，存储引擎在二级索引定位到记录后，获取主键值，然后回表操作，将完整的记录返回给 Server 层；
• 如此往复，直到存储引擎把表中的所有记录读完。

可以看到，没有索引下推的时候，每查询到一条二级索引记录，都要进行回表操作，然后将记录返回给 Server，接着 Server 再判断该记录的 reward 是否等于 100000。

而使用索引下推后，判断记录的 reward 是否等于 100000 的工作交给了存储引擎层，过程如下 ：

• Server 层首先调用存储引擎的接口定位到满足查询条件的第一条二级索引记录，也就是定位到 age > 20 的第一条记录；
• 存储引擎定位到二级索引后，先不执行回表操作，而是先判断一下该索引中包含的列（reward列）的条件（reward 是否等于 100000）是否成立。如果条件不成立，则直接跳过该二级索引。如果成立，则执行回表操作，将完成记录返回给 Server 层。
• Server 层在判断其他的查询条件（本次查询没有其他条件）是否成立，如果成立则将其发送给客户端；否则跳过该记录，然后向存储引擎索要下一条记录。
• 如此往复，直到存储引擎把表中的所有记录读完。

可以看到，使用了索引下推后，虽然 reward 列无法使用到联合索引，但是因为它包含在联合索引（age，reward）里，所以直接在存储引擎过滤出满足 reward = 100000 的记录后，才去执行回表操作获取整个记录。相比于没有使用索引下推，节省了很多回表操作。

当你发现执行计划里的 Extr 部分显示了 “Using index condition”，说明使用了索引下推。

MySQL 一行记录是怎么存储的？

• MySQL 的 NULL 值会占用空间吗？
• MySQL 怎么知道 varchar(n) 实际占用数据的大小？
• varchar(n) 中 n 最大取值为多少？
• 行溢出后，MySQL 是怎么处理的？

MySQL 的数据存放在哪个文件？

InnoDB 是我们常用的存储引擎，也是 MySQL 默认的存储引擎。所以，本文主要以 InnoDB 存储引擎展开讨论。

先来看看 MySQL 数据库的文件存放在哪个目录？

mysql> SHOW VARIABLES LIKE 'datadir';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)

我们每创建一个 database（数据库） 都会在 /var/lib/mysql/ 目录里面创建一个以 database 为名的目录，然后保存表结构和表数据的文件都会存放在这个目录里。

比如，我这里有一个名为 my_test 的 database，该 database 里有一张名为 t_order 数据库表。

然后，我们进入 /var/lib/mysql/my_test 目录，看看里面有什么文件？

[root@xiaolin ~]#ls /var/lib/mysql/my_test
db.opt  
t_order.frm  
t_order.ibd

可以看到，共有三个文件，这三个文件分别代表着：

• db.opt，用来存储当前数据库的默认字符集和字符校验规则。
• t_order.frm ，t_order 的表结构会保存在这个文件。在 MySQL 中建立一张表都会生成一个.frm 文件，该文件是用来保存每个表的元数据信息的，主要包含表结构定义。
• t_order.ibd，t_order 的表数据会保存在这个文件。表数据既可以存在共享表空间文件（文件名：ibdata1）里，也可以存放在独占表空间文件（文件名：表名字.ibd）。这个行为是由参数 innodb_file_per_table 控制的，若设置了参数 innodb_file_per_table 为 1，则会将存储的数据、索引等信息单独存储在一个独占表空间，从 MySQL 5.6.6 版本开始，它的默认值就是 1 了，因此从这个版本之后， MySQL 中每一张表的数据都存放在一个独立的 .ibd 文件。

一张数据库表的数据是保存在「 表名字.ibd 」的文件里的，这个文件也称为独占表空间文件。

表空间文件的结构是怎么样的？

表空间由段（segment）、区（extent）、页（page）、行（row）组成，InnoDB存储引擎的逻辑存储结构大致如下图：

1、行（row）

**数据库表中的记录都是按行（row）进行存放的**，每行记录根据不同的行格式，有不同的存储结构。

后面我们详细介绍 InnoDB 存储引擎的行格式，也是本文重点介绍的内容。

2、页（page）

记录是按照行来存储的，但是数据库的读取并不以「行」为单位，否则一次读取（也就是一次 I/O 操作）只能处理一行数据，效率会非常低。

因此，InnoDB 的数据是按「页」为单位来读写的，也就是说，当需要读一条记录的时候，并不是将这个行记录从磁盘读出来，而是以页为单位，将其整体读入内存。

默认每个页的大小为 16KB，也就是最多能保证 16KB 的连续存储空间。

页是 InnoDB 存储引擎磁盘管理的最小单元，意味着数据库每次读写都是以 16KB 为单位的，一次最少从磁盘中读取 16K 的内容到内存中，一次最少把内存中的 16K 内容刷新到磁盘中。

页的类型有很多，常见的有数据页、undo 日志页、溢出页等等。数据表中的行记录是用「数据页」来管理的。

总之知道表中的记录存储在「数据页」里面就行。

3、区（extent）

我们知道 InnoDB 存储引擎是用 B+ 树来组织数据的。

B+ 树中每一层都是通过双向链表连接起来的，如果是以页为单位来分配存储空间，那么链表中相邻的两个页之间的物理位置并不是连续的，可能离得非常远，那么磁盘查询时就会有大量的随机I/O，随机 I/O 是非常慢的。

解决这个问题也很简单，就是让链表中相邻的页的物理位置也相邻，这样就可以使用顺序 I/O 了，那么在范围查询（扫描叶子节点）的时候性能就会很高。

那具体怎么解决呢？

在表中数据量大的时候，为某个索引分配空间的时候就不再按照页为单位分配了，而是按照区（extent）为单位分配。每个区的大小为 1MB，对于 16KB 的页来说，连续的 64 个页会被划为一个区，这样就使得链表中相邻的页的物理位置也相邻，就能使用顺序 I/O 了。

4、段（segment）

表空间是由各个段（segment）组成的，段是由多个区（extent）组成的。段一般分为数据段、索引段和回滚段等。

• 索引段：存放 B + 树的非叶子节点的区的集合；
• 数据段：存放 B + 树的叶子节点的区的集合；
• 回滚段：存放的是回滚数据的区的集合，之前讲的时候就介绍到了 MVCC 利用了回滚段实现了多版本查询数据。

InnoDB 行格式有哪些

行格式（row_format），就是一条记录的存储结构。

InnoDB 提供了 4 种行格式，分别是 Redundant、Compact、Dynamic和 Compressed 行格式。

• Redundant 是很古老的行格式了， MySQL 5.0 版本之前用的行格式，现在基本没人用了。
• 由于 Redundant 不是一种紧凑的行格式，所以 MySQL 5.0 之后引入了 Compact 行记录存储方式，Compact 是一种紧凑的行格式，设计的初衷就是为了让一个数据页中可以存放更多的行记录，从 MySQL 5.1 版本之后，行格式默认设置成 Compact。
• Dynamic 和 Compressed 两个都是紧凑的行格式，它们的行格式都和 Compact 差不多，因为都是基于 Compact 改进一点东西。从 MySQL5.7 版本之后，默认使用 Dynamic 行格式。

Redundant 行格式我这里就不讲了，因为现在基本没人用了，这次重点介绍 Compact 行格式，因为 Dynamic 和 Compressed 这两个行格式跟 Compact 非常像。

COMPACT 行格式长什么样？

可以看到，一条完整的记录分为「记录的额外信息」和「记录的真实数据」两个部分。

记录的额外信息

记录的额外信息包含 3 个部分：变长字段长度列表、NULL 值列表、记录头信息。

1. 变长字段长度列表

varchar(n) 和 char(n) 的区别是什么，相信大家都非常清楚，char 是定长的，varchar 是变长的，变长字段实际存储的数据的长度（大小）不固定的。

所以，在存储数据的时候，也要把数据占用的大小存起来，存到「变长字段长度列表」里面，读取数据的时候才能根据这个「变长字段长度列表」去读取对应长度的数据。其他 TEXT、BLOB 等变长字段也是这么实现的。

为了展示「变长字段长度列表」具体是怎么保存「变长字段的真实数据占用的字节数」，我们先创建这样一张表，字符集是 ascii（所以每一个字符占用的 1 字节），行格式是 Compact，t_user 表中 name 和 phone 字段都是变长字段：

CREATE TABLE `t_user` (
  `id` int(11) NOT NULL,
  `name` VARCHAR(20) DEFAULT NULL,
  `phone` VARCHAR(20) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB DEFAULT CHARACTER SET = ascii ROW_FORMAT = COMPACT;

现在 t_user 表里有这三条记录：

先来看第一条记录：

• name 列的值为 a，真实数据占用的字节数是 1 字节，十六进制 0x01；
• phone 列的值为 123，真实数据占用的字节数是 3 字节，十六进制 0x03；
• age 列和 id 列不是变长字段，所以这里不用管。

这些变长字段的真实数据占用的字节数会按照列的顺序逆序存放（等下会说为什么要这么设计），所以「变长字段长度列表」里的内容是「 03 01」，而不是 「01 03」。

同样的道理，我们也可以得出第二条记录的行格式中，「变长字段长度列表」里的内容是「 04 02」，如下图：

第三条记录中 phone 列的值是 NULL，NULL 是不会存放在行格式中记录的真实数据部分里的，所以「变长字段长度列表」里不需要保存值为 NULL 的变长字段的长度。

为什么「变长字段长度列表」的信息要按照逆序存放？

这个设计是有想法的，主要是因为「 记录头信息」中指向下一个记录的指针，指向的是下一条记录的「记录头信息」和「真实数据」之间的位置，这样的好处是向左读就是记录头信息，向右读就是真实数据，比较方便。

「变长字段长度列表」中的信息之所以要逆序存放，是因为这样可以使得位置靠前的记录的真实数据和数据对应的字段长度信息可以同时在一个 CPU Cache Line 中，这样就可以提高 CPU Cache 的命中率。

同样的道理， NULL 值列表的信息也需要逆序存放=。

每个数据库表的行格式都有「变长字段字节数列表」吗？

其实变长字段字节数列表不是必须的。

当数据表没有变长字段的时候，比如全部都是 int 类型的字段，这时候表里的行格式就不会有「变长字段长度列表」了，因为没必要，不如去掉以节省空间。

所以「变长字段长度列表」只出现在数据表有变长字段的时候。

2. NULL 值列表

表中的某些列可能会存储 NULL 值，如果把这些 NULL 值都放到记录的真实数据中会比较浪费空间，所以 Compact 行格式把这些值为 NULL 的列存储到 NULL值列表中。

如果存在允许 NULL 值的列，则每个列对应一个二进制位（bit），二进制位按照列的顺序逆序排列。

• 二进制位的值为1时，代表该列的值为NULL。
• 二进制位的值为0时，代表该列的值不为NULL。

另外，NULL 值列表必须用整数个字节的位表示（1字节8位），如果使用的二进制位个数不足整数个字节，则在字节的高位补 0。

还是以 t_user 表的这三条记录作为例子：

接下来，我们看看看看这三条记录的行格式中的 NULL 值列表是怎样存储的。

先来看第一条记录，第一条记录所有列都有值，不存在 NULL 值，所以用二进制来表示是酱紫的：

但是 InnoDB 是用整数字节的二进制位来表示 NULL 值列表的，现在不足 8 位，所以要在高位补 0，最终用二进制来表示是酱紫的：

所以，对于第一条数据，NULL 值列表用十六进制表示是 0x00。

接下来看第二条记录，第二条记录 age 列是 NULL 值，所以，对于第二条数据，NULL值列表用十六进制表示是 0x04。

最后第三条记录，第三条记录 phone 列 和 age 列是 NULL 值，所以，对于第三条数据，NULL 值列表用十六进制表示是 0x06。

我们把三条记录的 NULL 值列表都填充完毕后，它们的行格式是这样的：

每个数据库表的行格式都有「NULL 值列表」吗？

NULL 值列表也不是必须的。

当数据表的字段都定义成 NOT NULL 的时候，这时候表里的行格式就不会有 NULL 值列表了。

所以在设计数据库表的时候，通常都是建议将字段设置为 NOT NULL，这样可以至少节省 1 字节的空间（NULL 值列表至少占用 1 字节空间）。

「NULL 值列表」是固定 1 字节空间吗？如果这样的话，一条记录有 9 个字段值都是 NULL，这时候怎么表示？

「NULL 值列表」的空间不是固定 1 字节的。

当一条记录有 9 个字段值都是 NULL，那么就会创建 2 字节空间的「NULL 值列表」，以此类推。

3. 记录头信息

记录头信息中包含的内容很多，我就不一一列举了，这里说几个比较重要的：

• delete_mask ：标识此条数据是否被删除。从这里可以知道，我们执行 detele 删除记录的时候，并不会真正的删除记录，只是将这个记录的 delete_mask 标记为 1。
• next_record：下一条记录的位置。从这里可以知道，记录与记录之间是通过链表组织的。在前面我也提到了，指向的是下一条记录的「记录头信息」和「真实数据」之间的位置，这样的好处是向左读就是记录头信息，向右读就是真实数据，比较方便。
• record_type：表示当前记录的类型，0表示普通记录，1表示B+树非叶子节点记录，2表示最小记录，3表示最大记录

记录的真实数据

记录真实数据部分除了我们定义的字段，还有三个隐藏字段，分别为：row_id、trx_id、roll_pointer，我们来看下这三个字段是什么。

• row_id

建表的时候指定了主键或者唯一约束列，那么就没有 row_id 隐藏字段了。

如果既没有指定主键，又没有唯一约束，那么 InnoDB 就会为记录添加 row_id 隐藏字段。row_id不是必需的，占用 6 个字节。

• trx_id

事务id，表示这个数据是由哪个事务生成的。 trx_id是必需的，占用 6 个字节。

• roll_pointer

这条记录上一个版本的指针。roll_pointer 是必需的，占用 7 个字节。

熟悉 MVCC 机制，你应该就清楚 trx_id 和 roll_pointer 的作用

varchar(n) 中 n 最大取值为多少？

MySQL 规定除了 TEXT、BLOBs 这种大对象类型之外，其他所有的列（不包括隐藏列和记录头信息）占用的字节长度加起来不能超过 65535 个字节。

一行记录除了 TEXT、BLOBs 类型的列，限制最大为 65535 字节，注意是一行的总长度，不是一列。

varchar(n) 字段类型的 n 代表的是最多存储的字符数量，并不是字节大小哦。

要算 varchar(n) 最大能允许存储的字节数，还要看数据库表的字符集，因为字符集代表着，1个字符要占用多少字节，比如 ascii 字符集， 1 个字符占用 1 字节，那么 varchar(100) 意味着最大能允许存储 100 字节的数据。

本次案例中，「NULL 值列表」所占用的字节数是多少？

前面我创建表的时候，字段是允许为 NULL 的，所以会用 1 字节来表示「NULL 值列表」。

本次案例中，「变长字段长度列表」所占用的字节数是多少？

「变长字段长度列表」所占用的字节数 = 所有「变长字段长度」占用的字节数之和。

所以，我们要先知道每个变长字段的「变长字段长度」需要用多少字节表示？具体情况分为：

• 条件一：如果变长字段允许存储的最大字节数小于等于 255 字节，就会用 1 字节表示「变长字段长度」；
• 条件二：如果变长字段允许存储的最大字节数大于 255 字节，就会用 2 字节表示「变长字段长度」；

我们这里字段类型是 varchar(65535) ，字符集是 ascii，所以代表着变长字段允许存储的最大字节数是 65535，符合条件二，所以会用 2 字节来表示「变长字段长度」。

因为我们这个案例是只有 1 个变长字段，所以「变长字段长度列表」= 1 个「变长字段长度」占用的字节数，也就是 2 字节。

因为我们在算 varchar(n) 中 n 最大值时，需要减去 「变长字段长度列表」和 「NULL 值列表」所占用的字节数的。所以，在数据库表只有一个 varchar(n) 字段且字符集是 ascii 的情况下，varchar(n) 中 n 最大值 = 65535 - 2 - 1 = 65532。

我们先来测试看看 varchar(65533) 是否可行？

可以看到，还是不行，接下来看看 varchar(65532) 是否可行？

可以看到，创建成功了。说明我们的推论是正确的，在算 varchar(n) 中 n 最大值时，需要减去 「变长字段长度列表」和 「NULL 值列表」所占用的字节数的。

当然，我上面这个例子是针对字符集为 ascii 情况，如果采用的是 UTF-8，varchar(n) 最多能存储的数据计算方式就不一样了：

• 在 UTF-8 字符集下，一个字符最多需要三个字节，varchar(n) 的 n 最大取值就是 65532/3 = 21844。

上面所说的只是针对于一个字段的计算方式。

单字段的情况

一行记录最大只能存储 65535 字节的数据。

那假设数据库表只有一个 varchar(n) 类型的列且字符集是 ascii，在这种情况下， varchar(n) 中 n 最大取值是 65535 吗？

不着急说结论，我们先来做个实验验证一下。

我们定义一个 varchar(65535) 类型的字段，字符集为 ascii 的数据库表。

CREATE TABLE test ( 
`name` VARCHAR(65535)  NULL
) ENGINE = InnoDB DEFAULT CHARACTER SET = ascii ROW_FORMAT = COMPACT;

看能不能成功创建一张表：

可以看到，创建失败了。

从报错信息就可以知道一行数据的最大字节数是 65535（不包含 TEXT、BLOBs 这种大对象类型），其中包含了 storage overhead。

storage overhead 是什么呢？其实就是「变长字段长度列表」和 「NULL 值列表」，也就是说一行数据的最大字节数 65535，其实是包含「变长字段长度列表」和 「NULL 值列表」所占用的字节数的。

在算 varchar(n) 中 n 最大值时，需要减去 storage overhead 占用的字节数。

这是因为我们存储字段类型为 varchar(n) 的数据时，其实分成了三个部分来存储：

• 真实数据
• 真实数据占用的字节数
• NULL 标识，如果不允许为NULL，这部分不需要

多字段的情况

如果有多个字段的话，要保证所有字段的长度 + 变长字段字节数列表所占用的字节数 + NULL值列表所占用的字节数 <= 65535。

行溢出后,MySQL是怎么处理的?

MySQL 中磁盘和内存交互的基本单位是页，一个页的大小一般是 16KB，也就是 16384字节，而一个 varchar(n) 类型的列最多可以存储 65532字节，一些大对象如 TEXT、BLOB 可能存储更多的数据，这时一个页可能就存不了一条记录。这个时候就会发生行溢出，多的数据就会存到另外的「溢出页」中。

如果一个数据页存不了一条记录，InnoDB 存储引擎会自动将溢出的数据存放到「溢出页」中。

在一般情况下，InnoDB 的数据都是存放在 「数据页」中。但是当发生行溢出时，溢出的数据会存放到「溢出页」中。

当发生行溢出时，在记录的真实数据处只会保存该列的一部分数据，而把剩余的数据放在「溢出页」中，然后真实数据处用 20 字节存储指向溢出页的地址，从而可以找到剩余数据所在的页。大致如下图所示。

上面这个是 Compact 行格式在发生行溢出后的处理。

Compressed 和 Dynamic 这两个行格式和 Compact 非常类似，主要的区别在于处理行溢出数据时有些区别。

这两种格式采用完全的行溢出方式，记录的真实数据处不会存储该列的一部分数据，只存储 20 个字节的指针来指向溢出页。而实际的数据都存储在溢出页中，看起来就像下面这样：

总结:

MySQL 的 NULL 值是怎么存放的？

MySQL 的 Compact 行格式中会用「NULL值列表」来标记值为 NULL 的列，NULL 值并不会存储在行格式中的真实数据部分。

NULL值列表会占用 1 字节空间，当表中所有字段都定义成 NOT NULL，行格式中就不会有 NULL值列表，这样可节省 1 字节的空间。

MySQL 怎么知道 varchar(n) 实际占用数据的大小？

MySQL 的 Compact 行格式中会用「变长字段长度列表」存储变长字段实际占用的数据大小。

varchar(n) 中 n 最大取值为多少？

一行记录最大能存储 65535 字节的数据，但是这个是包含「变长字段字节数列表所占用的字节数」和「NULL值列表所占用的字节数」。所以， 我们在算 varchar(n) 中 n 最大值时，需要减去这两个列表所占用的字节数。

如果一张表只有一个 varchar(n) 字段，且允许为 NULL，字符集为 ascii。varchar(n) 中 n 最大取值为 65532。

计算公式：65535 - 变长字段字节数列表所占用的字节数 - NULL值列表所占用的字节数 = 65535 - 2 - 1 = 65532。

如果有多个字段的话，要保证所有字段的长度 + 变长字段字节数列表所占用的字节数 + NULL值列表所占用的字节数 <= 65535。

行溢出后，MySQL 是怎么处理的？

如果一个数据页存不了一条记录，InnoDB 存储引擎会自动将溢出的数据存放到「溢出页」中。

Compact 行格式针对行溢出的处理是这样的：当发生行溢出时，在记录的真实数据处只会保存该列的一部分数据，而把剩余的数据放在「溢出页」中，然后真实数据处用 20 字节存储指向溢出页的地址，从而可以找到剩余数据所在的页。

Compressed 和 Dynamic 这两种格式采用完全的行溢出方式，记录的真实数据处不会存储该列的一部分数据，只存储 20 个字节的指针来指向溢出页。而实际的数据都存储在溢出页中。

索引篇

• 索引底层使用了什么数据结构和算法？
• 为什么 MySQL InnoDB 选择 B+tree 作为索引的数据结构？
• 什么时候适用索引？
• 什么时候不需要创建索引？
• 什么情况下索引会失效？
• 有什么优化索引的方法？

什么是索引？

书中的目录，就是充当索引的角色，方便我们快速查找书中的内容，所以索引是以空间换时间的设计思想。

数据库中，索引的定义就是帮助存储引擎快速获取数据的一种数据结构，形象的说就是索引是数据的目录。

索引种类

• 按「数据结构」分类：B+tree索引、Hash索引、Full-text索引
• 按「物理存储」分类：聚簇索引（主键索引）、二级索引（辅助索引）
• 按「字段特性」分类：主键索引、唯一索引、普通索引、前缀索引
• 按「字段个数」分类：单列索引、联合索引

按数据结构分类

InnoDB 是在 MySQL 5.5 之后成为默认的 MySQL 存储引擎，B+Tree 索引类型也是 MySQL 存储引擎采用最多的索引类型。

在创建表时，InnoDB 存储引擎会根据不同的场景选择不同的列作为索引：

• 如果有主键，默认会使用主键作为聚簇索引的索引键（key）；
• 如果没有主键，就选择第一个不包含 NULL 值的唯一列作为聚簇索引的索引键（key）；
• 在上面两个都没有的情况下，InnoDB 将自动生成一个隐式自增 id 列作为聚簇索引的索引键（key）；

其它索引都属于辅助索引（Secondary Index），也被称为二级索引或非聚簇索引。

创建的主键索引和二级索引默认使用的是 B+Tree 索引。

B+Tree 是一种多叉树，叶子节点才存放数据，非叶子节点只存放索引，而且每个节点里的数据是按主键顺序存放的。

每一层父节点的索引值都会出现在下层子节点的索引值中，因此在叶子节点中，包括了所有的索引值信息，并且每一个叶子节点都有两个指针，分别指向下一个叶子节点和上一个叶子节点，形成一个双向链表。

先创建一张商品表，id 为主键，如下：

CREATE TABLE `product`  (
  `id` int(11) NOT NULL,
  `product_no` varchar(20)  DEFAULT NULL,
  `name` varchar(255) DEFAULT NULL,
  `price` decimal(10, 2) DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;

主键索引的 B+Tree 如图所示

通过主键查询商品数据的过程

比如，我们执行了下面这条查询语句：

select * from product where id= 5;

这条语句使用了主键索引查询 id 号为 5 的商品。查询过程是这样的，B+Tree 会自顶向下逐层进行查找：

• 将 5 与根节点的索引数据 (1，10，20) 比较，5 在 1 和 10 之间，所以根据 B+Tree的搜索逻辑，找到第二层的索引数据 (1，4，7)；
• 在第二层的索引数据 (1，4，7)中进行查找，因为 5 在 4 和 7 之间，所以找到第三层的索引数据（4，5，6）；
• 在叶子节点的索引数据（4，5，6）中进行查找，然后我们找到了索引值为 5 的行数据。

数据库的索引和数据都是存储在硬盘的，我们可以把读取一个节点当作一次磁盘 I/O 操作。那么上面的整个查询过程一共经历了 3 个节点，也就是进行了 3 次 I/O 操作。

B+Tree 存储千万级的数据只需要 3-4 层高度就可以满足，这意味着从千万级的表查询目标数据最多需要 3-4 次磁盘 I/O，所以B+Tree 相比于 B 树和二叉树来说，最大的优势在于查询效率很高，因为即使在数据量很大的情况，查询一个数据的磁盘 I/O 依然维持在 3-4次。

通过二级索引查询商品数据的过程

主键索引的 B+Tree 和二级索引的 B+Tree 区别如下：

• 主键索引的 B+Tree 的叶子节点存放的是实际数据，所有完整的用户记录都存放在主键索引的 B+Tree 的叶子节点里；
• 二级索引的 B+Tree 的叶子节点存放的是主键值，而不是实际数据。

我这里将前面的商品表中的 product_no （商品编码）字段设置为二级索引，那么二级索引的 B+Tree 如下图（图中叶子节点之间我画了单向链表，但是实际上是双向链表）。

其中非叶子的 key 值是 product_no（图中橙色部分），叶子节点存储的数据是主键值（图中绿色部分）。

如果我用 product_no 二级索引查询商品，如下查询语句：

select * from product where product_no = '0002';

会先检二级索引中的 B+Tree 的索引值（商品编码，product_no），找到对应的叶子节点，然后获取主键值，然后再通过主键索引中的 B+Tree 树查询到对应的叶子节点，然后获取整行数据。这个过程叫「回表」，也就是说要查两个 B+Tree 才能查到数据：

不过，当查询的数据是能在二级索引的 B+Tree 的叶子节点里查询到，这时就不用再查主键索引查，比如下面这条查询语句：

select id from product where product_no = '0002';

这种在二级索引的 B+Tree 就能查询到结果的过程就叫作「覆盖索引」，也就是只需要查一个 B+Tree 就能找到数据。

按物理存储分类

从物理存储的角度来看，索引分为聚簇索引（主键索引）、二级索引（辅助索引）。

这两个区别在前面也提到了：

• 主键索引的 B+Tree 的叶子节点存放的是实际数据，所有完整的用户记录都存放在主键索引的 B+Tree 的叶子节点里；
• 二级索引的 B+Tree 的叶子节点存放的是主键值，而不是实际数据。

按字段特性分类

从字段特性的角度来看，索引分为主键索引、唯一索引、普通索引、前缀索引。

主键索引

主键索引就是建立在主键字段上的索引，通常在创建表的时候一起创建，一张表最多只有一个主键索引，索引列的值不允许有空值。

在创建表时，创建主键索引的方式如下：

CREATE TABLE table_name  (
  ....
  PRIMARY KEY (index_column_1) USING BTREE
);

唯一索引

唯一索引建立在 UNIQUE 字段上的索引，一张表可以有多个唯一索引，索引列的值必须唯一，但是允许有空值。

在创建表时，创建唯一索引的方式如下：

CREATE TABLE table_name  (
  ....
  UNIQUE KEY(index_column_1,index_column_2,...) 
);

建表后，如果要创建唯一索引，可以使用这面这条命令：

CREATE UNIQUE INDEX index_name
ON table_name(index_column_1,index_column_2,...); 

普通索引

普通索引就是建立在普通字段上的索引，既不要求字段为主键，也不要求字段为 UNIQUE。

在创建表时，创建普通索引的方式如下：

CREATE TABLE table_name  (
  ....
  INDEX(index_column_1,index_column_2,...) 
);

建表后，如果要创建普通索引，可以使用这面这条命令：

CREATE INDEX index_name
ON table_name(index_column_1,index_column_2,...); 

前缀索引

前缀索引是指对字符类型字段的前几个字符建立的索引，而不是在整个字段上建立的索引，前缀索引可以建立在字段类型为 char、 varchar、binary、varbinary 的列上。

使用前缀索引的目的是为了减少索引占用的存储空间，提升查询效率。

在创建表时，创建前缀索引的方式如下：

CREATE TABLE table_name(
    column_list,
    INDEX(column_name(length))
); 

建表后，如果要创建前缀索引，可以使用这面这条命令：

CREATE INDEX index_name
ON table_name(column_name(length)); 

按字段个数分类

从字段个数的角度来看，索引分为单列索引、联合索引（复合索引）。

• 建立在单列上的索引称为单列索引，比如主键索引；
• 建立在多列上的索引称为联合索引；

联合索引

比如，将商品表中的 product_no 和 name 字段组合成联合索引(product_no, name)，创建联合索引的方式如下：

CREATE INDEX index_product_no_name ON product(product_no, name);

联合索引(product_no, name) 的 B+Tree 示意图如下

可联合索引的非叶子节点用两个字段的值作为 B+Tree 的 key 值。当在联合索引查询数据时，先按 product_no 字段比较，在 product_no 相同的情况下再按 name 字段比较。

联合索引查询的 B+Tree 是先按 product_no 进行排序，然后再 product_no 相同的情况再按 name 字段排序。

因此，使用联合索引时，存在最左匹配原则，也就是按照最左优先的方式进行索引的匹配。在使用联合索引进行查询的时候，如果不遵循「最左匹配原则」，联合索引会失效，这样就无法利用到索引快速查询的特性了。

比如，如果创建了一个 (a, b, c) 联合索引，如果查询条件是以下这几种，就可以匹配上联合索引：

• where a=1；
• where a=1 and b=2 and c=3；
• where a=1 and b=2；

需要注意的是，因为有查询优化器，所以 a 字段在 where 子句的顺序并不重要。

但是，如果查询条件是以下这几种，因为不符合最左匹配原则，所以就无法匹配上联合索引，联合索引就会失效:

• where b=2；
• where c=3；
• where b=2 and c=3；

上面这些查询条件之所以会失效，是因为(a, b, c) 联合索引，是先按 a 排序，在 a 相同的情况再按 b 排序，在 b 相同的情况再按 c 排序。所以，b 和 c 是全局无序，局部相对有序的，这样在没有遵循最左匹配原则的情况下，是无法利用到索引的。

可以看到，a 是全局有序的（1, 2, 2, 3, 4, 5, 6, 7 ,8），而 b 是全局是无序的（12，7，8，2，3，8，10，5，2）。因此，直接执行where b = 2这种查询条件没有办法利用联合索引的。利用索引的前提是索引里的 key 是有序的。

只有在 a 相同的情况才，b 才是有序的，比如 a 等于 2 的时候，b 的值为（7，8），这时就是有序的，这个有序状态是局部的，因此，执行where a = 2 and b = 7是 a 和 b 字段能用到联合索引的，也就是联合索引生效了。

什么时候需要 / 不需要创建索引？

索引最大的好处是提高查询速度，

索引缺点：

• 需要占用物理空间，数量越大，占用空间越大；
• 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增大；
• 会降低表的增删改的效率，因为每次增删改索引，B+ 树为了维护索引有序性，都需要进行动态维护。

创建索引的原则

• 创建索引的时候都是使用复合索引来创建，一条sql的返回值，尽量使用覆盖索引，如果字段的区分度不高的话，我们也会把它放在 组合索引后面的字段。

  -- 假设我们有一个用户表 users，包含以下字段：id, username, email, age, gender，并且我们经常有如下查询：
  SELECT username, email 
  FROM users 
  WHERE age = 30 AND gender = 'M' 
  ORDER BY username;
  
  -- age 的区分度相对较高（通常有很多不同的年龄值）。
  -- gender 的区分度较低（只有两个值：'M' 和 'F'）。
  
  -- 为了实现覆盖索引，索引应该包含查询中涉及的所有字段。
  -- 由于 age 的区分度较高，应将其放在复合索引的前面。
  -- 由于 gender 的区分度较低，应将其放在后面。
  -- 添加 username 和 email 以实现覆盖索引。
  -- 索引创建语句
  CREATE INDEX idx_users_age_gender_username_email 
  ON users(age, gender, username, email);
  -- 字段顺序：age 在前，因为它的区分度较高，gender 在后，因为它的区分度较低，然后是 username 和 email，用于实现覆盖索引。
  
  

• 表中的数据要超过10万以上，才会创建索引，并且添加索引的字段是查询比较频繁的字 段，一般也是像作为查询条件，排序字段或分组的字段这些。

• 如果某一个字段的内容较长，我们会考虑使用前缀索引来使用，当然并不是 所有的字段都要添加索引，这个索引的数量也要控制，因为添加索引也会导致新增改的速度变慢。

什么时候适用索引？

• 字段有唯一性限制的，比如商品编码；
• 经常用于 WHERE 查询条件的字段，这样能够提高整个表的查询速度，如果查询条件不是一个字段，可以建立联合索引。
• 经常用于 GROUP BY 和 ORDER BY 的字段，这样在查询的时候就不需要再去做一次排序了，因为我们都已经知道了建立索引之后在 B+Tree 中的记录都是排序好的。

什么时候不需要创建索引？

• WHERE 条件，GROUP BY，ORDER BY 里用不到的字段，索引的价值是快速定位，如果起不到定位的字段通常是不需要创建索引的，因为索引是会占用物理空间的。
• 字段中存在大量重复数据，不需要创建索引，比如性别字段，只有男女，如果数据库表中，男女的记录分布均匀，那么无论搜索哪个值都可能得到一半的数据。在这些情况下，还不如不要索引，因为 MySQL 还有一个查询优化器，查询优化器发现某个值出现在表的数据行中的百分比很高的时候，它一般会忽略索引，进行全表扫描。
• 表数据太少的时候，不需要创建索引；就是表中的数据要超过10万以上，我们才会创建索引，并且添加索引的字段是查询比较频繁的字 段，
• 经常更新的字段不用创建索引，比如不要对电商项目的用户余额建立索引，因为索引字段频繁修改，由于要维护 B+Tree的有序性，那么就需要频繁的重建索引，这个过程是会影响数据库性能的。

有什么优化索引的方法？

这里说一下几种常见优化索引的方法：

• 前缀索引优化；
• 覆盖索引优化；
• 主键索引最好是自增的；
• 防止索引失效；

前缀索引优化；

前缀索引顾名思义就是使用某个字段中字符串的前几个字符建立索引，使用前缀索引是为了减小索引字段大小，可以增加一个索引页中存储的索引值，有效提高索引的查询速度。在一些大字符串的字段作为索引时，使用前缀索引可以帮助我们减小索引项的大小。

不过，前缀索引有一定的局限性，例如：

• order by 就无法使用前缀索引；
• 无法把前缀索引用作覆盖索引；

覆盖索引优化；

覆盖索引是指 SQL 中 query 的所有字段，在索引 B+Tree 的叶子节点上都能找得到的那些索引，从二级索引中查询得到记录，而不需要通过聚簇索引查询获得，可以避免回表的操作。

假设我们只需要查询商品的名称、价格，有什么方式可以避免回表呢？

我们可以建立一个联合索引，即「商品ID、名称、价格」作为一个联合索引。如果索引中存在这些数据，查询将不会再次检索主键索引，从而避免回表。

所以，使用覆盖索引的好处就是，不需要查询出包含整行记录的所有信息，也就减少了大量的 I/O 操作。

主键索引最好是自增的；

我们在建表的时候，都会默认将主键索引设置为自增的，具体为什么要这样做呢？又什么好处？

InnoDB 创建主键索引默认为聚簇索引，数据被存放在了 B+Tree 的叶子节点上。也就是说，同一个叶子节点内的各个数据是按主键顺序存放的，因此，每当有一条新的数据插入时，数据库会根据主键将其插入到对应的叶子节点中。

如果我们使用自增主键，那么每次插入的新数据就会按顺序添加到当前索引节点的位置，不需要移动已有的数据，当页面写满，就会自动开辟一个新页面。因为每次插入一条新记录，都是追加操作，不需要重新移动数据，因此这种插入数据的方法效率非常高。

如果我们使用非自增主键，由于每次插入主键的索引值都是随机的，因此每次插入新的数据时，就可能会插入到现有数据页中间的某个位置，这将不得不移动其它数据来满足新数据的插入，甚至需要从一个页面复制数据到另外一个页面，我们通常将这种情况称为页分裂。页分裂还有可能会造成大量的内存碎片，导致索引结构不紧凑，从而影响查询效率。

举个例子，假设某个数据页中的数据是1、3、5、9，且数据页满了，现在准备插入一个数据7，则需要把数据页分割为两个数据页：

出现页分裂时，需要将一个页的记录移动到另外一个页，性能会受到影响，同时页空间的利用率下降，造成存储空间的浪费。

而如果记录是顺序插入的，例如插入数据11，则只需开辟新的数据页，也就不会发生页分裂：

因此，在使用 InnoDB 存储引擎时，如果没有特别的业务需求，建议使用自增字段作为主键。

另外，主键字段的长度不要太大，因为主键字段长度越小，意味着二级索引的叶子节点越小（二级索引的叶子节点存放的数据是主键值），这样二级索引占用的空间也就越小。

索引最好设置为 NOT NULL

为了更好的利用索引，索引列要设置为 NOT NULL 约束。有两个原因：

• 第一原因：索引列存在 NULL 就会导致优化器在做索引选择的时候更加复杂，更加难以优化，因为可为 NULL 的列会使索引、索引统计和值比较都更复杂，比如进行索引统计时，count 会省略值为NULL 的行。
• 第二个原因：NULL 值是一个没意义的值，但是它会占用物理空间，所以会带来的存储空间的问题，因为 InnoDB 存储记录的时候，如果表中存在允许为 NULL 的字段，那么行格式 中至少会用 1 字节空间存储 NULL 值列表，如下图的紫色部分：

防止索引失效；

用上了索引并不意味着查询的时候会使用到索引，所以我们心里要清楚有哪些情况会导致索引失效，从而避免写出索引失效的查询语句，否则这样的查询效率是很低的。

这里简单说一下，发生索引失效的情况：

• 当我们使用左或者左右模糊匹配的时候，也就是 like %xx 或者 like %xx%这两种方式都会造成索引失效；
• 当我们在查询条件中对索引列做了计算、函数、类型转换操作，这些情况下都会造成索引失效；
• 联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配，否则就会导致索引失效。
• 在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。

我上面说的是常见的索引失效场景，实际过程中，可能会出现其他的索引失效场景，这时我们就需要查看执行计划，通过执行计划显示的数据判断查询语句是否使用了索引。

如下图，就是一个没有使用索引，并且是一个全表扫描的查询语句。

对于执行计划，参数有：

• possible_keys 字段表示可能用到的索引；
• key 字段表示实际用的索引，如果这一项为 NULL，说明没有使用索引；
• key_len 表示索引的长度；
• rows 表示扫描的数据行数。
• type 表示数据扫描类型，我们需要重点看这个。

type 字段就是描述了找到所需数据时使用的扫描方式是什么，常见扫描类型的执行效率从低到高的顺序为：

• All（全表扫描）；
• index（全索引扫描）；
• range（索引范围扫描）；
• ref（非唯一索引扫描/唯一索引的非唯一性前缀）；
• eq_ref（唯一索引扫描）；
• const（结果只有一条的主键或唯一索引扫描）。

在这些情况里，all 是最坏的情况，因为采用了全表扫描的方式。index 和 all 差不多，只不过 index 对索引表进行全扫描，这样做的好处是不再需要对数据进行排序，但是开销依然很大。所以，要尽量避免全表扫描和全索引扫描。

range 表示采用了索引范围扫描，一般在 where 子句中使用 < 、>、in、between 等关键词，只检索给定范围的行，属于范围查找。从这一级别开始，索引的作用会越来越明显，因此我们需要尽量让 SQL 查询可以使用到 range 这一级别及以上的 type 访问方式。

ref 类型表示采用了非唯一索引，或者是唯一索引的非唯一性前缀，返回数据返回可能是多条。因为虽然使用了索引，但该索引列的值并不唯一，有重复。这样即使使用索引快速查找到了第一条数据，仍然不能停止，要进行目标值附近的小范围扫描。但它的好处是它并不需要扫全表，因为索引是有序的，即便有重复值，也是在一个非常小的范围内扫描。

eq_ref 类型是使用主键或唯一索引时产生的访问方式，通常使用在多表联查中。比如，对两张表进行联查，关联条件是两张表的 user_id 相等，且 user_id 是唯一索引，那么使用 EXPLAIN 进行执行计划查看的时候，type 就会显示 eq_ref。

const 类型表示使用了主键或者唯一索引与常量值进行比较，比如 select name from product where id=1。

需要说明的是 const 类型和 eq_ref 都使用了主键或唯一索引，不过这两个类型有所区别，const 是与常量进行比较，查询效率会更快，而 eq_ref 通常用于多表联查中。

除了关注 type，我们也要关注 extra 显示的结果。

这里说几个重要的参考指标：

• Using filesort ：当查询语句中包含 group by 操作，而且无法利用索引完成排序操作的时候， 这时不得不选择相应的排序算法进行，甚至可能会通过文件排序，效率是很低的，所以要避免这种问题的出现。
• Using temporary：使了用临时表保存中间结果，MySQL 在对查询结果排序时使用临时表，常见于排序 order by 和分组查询 group by。效率低，要避免这种问题的出现。
• Using index：所需数据只需在索引即可全部获得，不须要再到表中取数据，也就是使用了覆盖索引，避免了回表操作，效率不错。

索引的原理、分类和使用总结

MySQL什么使用B+树来作索引，它的优势什么？

MySQL索引的底层数据结构是B+树

MySQL的默认的存储引擎InnoDB采用的B+树的数据结构来存储索 引，选择B+树的主要的原因是：

第一阶数更多，路径更短，

第二个磁盘读写 代价B+树更低，非叶子节点只存储指针，叶子阶段存储数据，

第三是B+树便 于扫库和区间查询，叶子节点是一个双向链表

1、B+Tree vs B Tree

• B+Tree 只在叶子节点存储数据，而 B 树 的非叶子节点也要存储数据，B+树的内部节点因不存储实际数据而能容纳更多的索引信息，导致整体树结构更为扁平化，在相同的磁盘 I/O 次数下，就能查询更多的节点。

• B+Tree 叶子节点采用的是双链表连接，适合 MySQL 中常见的基于范围的顺序查找，而 B 树无法做到这一点。

2、B+Tree vs 二叉树

对于有 N 个叶子节点的 B+Tree，其搜索复杂度为O(logdN)，其中 d 表示节点允许的最大子节点个数为 d 个。

在实际的应用当中， d 值是大于100的，这样就保证了，即使数据达到千万级别时，B+Tree 的高度依然维持在 3~4 层左右，也就是说一次数据查询操作只需要做 3~4 次的磁盘 I/O 操作就能查询到目标数据。

而二叉树的每个父节点的儿子节点个数只能是 2 个，意味着其搜索复杂度为 O(logN)，这已经比 B+Tree 高出不少，因此二叉树检索到目标数据所经历的磁盘 I/O 次数要更多。

3、B+Tree vs Hash

Hash 在做等值查询的时候效率贼快，搜索复杂度为 O(1)。

但是 Hash 表不适合做范围查询，它更适合做等值的查询，这也是 B+Tree 索引要比 Hash 表索引有着更广泛的适用场景的原因。

怎样的索引的数据结构是好的？

MySQL 的数据是持久化的，意味着数据（索引+记录）是保存到磁盘上的，因为这样即使设备断电了，数据也不会丢失。

磁盘是一个慢的离谱的存储设备，有多离谱呢？

人家内存的访问速度是纳秒级别的，而磁盘访问的速度是毫秒级别的，也就是说读取同样大小的数据，磁盘中读取的速度比从内存中读取的速度要慢上万倍，甚至几十万倍。

磁盘读写的最小单位是扇区，扇区的大小只有 512B 大小，操作系统一次会读写多个扇区，所以操作系统的最小读写单位是块（Block）。Linux 中的块大小为 4KB，也就是一次磁盘 I/O 操作会直接读写 8 个扇区。

由于数据库的索引是保存到磁盘上的，因此当我们通过索引查找某行数据的时候，就需要先从磁盘读取索引到内存，再通过索引从磁盘中找到某行数据，然后读入到内存，也就是说查询过程中会发生多次磁盘 I/O，而磁盘 I/O 次数越多，所消耗的时间也就越大。

所以，我们希望索引的数据结构能在尽可能少的磁盘的 I/O 操作中完成查询工作，因为磁盘 I/O 操作越少，所消耗的时间也就越小。

另外，MySQL 是支持范围查找的，所以索引的数据结构不仅要能高效地查询某一个记录，而且也要能高效地执行范围查找。

所以，要设计一个适合 MySQL 索引的数据结构，至少满足以下要求：

• 能在尽可能少的磁盘的 I/O 操作中完成查询工作；
• 要能高效地查询某一个记录，也要能高效地执行范围查找；

什么是 B 树:

为了解决降低树的高度的问题， B 树不再限制一个节点就只能有 2 个子节点，而是允许 M 个子节点 (M>2)，从而降低树的高度。

B 树的每一个节点最多可以包括 M 个子节点，M 称为 B 树的阶，所以 B 树就是一个多叉树。

一棵 3 阶的 B 树在查询叶子节点中的数据时，由于树的高度是 3 ，所以在查询过程中会发生 3 次磁盘 I/O 操作。

而如果同样的节点数量在平衡二叉树的场景下，树的高度就会很高，意味着磁盘 I/O 操作会更多。所以，B 树在数据查询中比平衡二叉树效率要高。

但是 B 树的每个节点都包含数据（索引+记录），而用户的记录数据的大小很有可能远远超过了索引数据，这就需要花费更多的磁盘 I/O 操作次数来读到「有用的索引数据」。

而且，在我们查询位于底层的某个节点（比如 A 记录）过程中，「非 A 记录节点」里的记录数据会从磁盘加载到内存，但是这些记录数据是没用的，我们只是想读取这些节点的索引数据来做比较查询，而「非 A 记录节点」里的记录数据对我们是没用的，这样不仅增多磁盘 I/O 操作次数，也占用内存资源。

另外，如果使用 B 树来做范围查询的话，需要使用中序遍历，这会涉及多个节点的磁盘 I/O 问题，从而导致整体速度下降。

什么是 B+ 树:

B+ 树与 B 树差异的点，主要是以下这几点：

• 叶子节点（最底部的节点）才会存放实际数据（索引+记录），非叶子节点只会存放索引；
• 所有索引都会在叶子节点出现，叶子节点之间构成一个有序链表；
• 非叶子节点的索引也会同时存在在子节点中，并且是在子节点中所有索引的最大（或最小）。
• 非叶子节点中有多少个子节点，就有多少个索引；

1、单点查询

B 树进行单个索引查询时，最快可以在 O(1) 的时间代价内就查到，而从平均时间代价来看，会比 B+ 树稍快一些。

但是 B 树的查询波动会比较大，因为每个节点即存索引又存记录，所以有时候访问到了非叶子节点就可以找到索引，而有时需要访问到叶子节点才能找到索引。

B+ 树的非叶子节点不存放实际的记录数据，仅存放索引，因此数据量相同的情况下，相比存储即存索引又存记录的 B 树，B+树的非叶子节点可以存放更多的索引，因此 B+ 树可以比 B 树更「矮胖」，查询底层节点的磁盘 I/O次数会更少。

2、插入和删除效率

B+ 树有大量的冗余节点，这样使得删除一个节点的时候，可以直接从叶子节点中删除，甚至可以不动非叶子节点，这样删除非常快，

3、范围查询

B 树和 B+ 树等值查询原理基本一致，先从根节点查找，然后对比目标数据的范围，最后递归的进入子节点查找。

因为B+ 树所有叶子节点间还有一个链表进行连接，这种设计对范围查找非常有帮助，比如说我们想知道 12 月 1 日和 12 月 12 日之间的订单，这个时候可以先查找到 12 月 1 日所在的叶子节点，然后利用链表向右遍历，直到找到 12 月12 日的节点，这样就不需要从根节点查询了，进一步节省查询需要的时间。

而 B 树没有将所有叶子节点用链表串联起来的结构，因此只能通过树的遍历来完成范围查询，这会涉及多个节点的磁盘 I/O 操作，范围查询效率不如 B+ 树。

因此，存在大量范围检索的场景，适合使用 B+树，比如数据库。而对于大量的单个索引查询的场景，可以考虑 B 树，比如 nosql 的MongoDB。

MySQL 中的 B+ 树

但是 Innodb 使用的 B+ 树有一些特别的点，比如：

• B+ 树的叶子节点之间是用「双向链表」进行连接，这样的好处是既能向右遍历，也能向左遍历。
• B+ 树点节点内容是数据页，数据页里存放了用户的记录以及各种信息，每个数据页默认大小是 16 KB。

Innodb 根据索引类型不同，分为聚集和二级索引。他们区别在于，聚集索引的叶子节点存放的是实际数据，所有完整的用户记录都存放在聚集索引的叶子节点，而二级索引的叶子节点存放的是主键值，而不是实际数据。

因为表的数据都是存放在聚集索引的叶子节点里，所以 InnoDB 存储引擎一定会为表创建一个聚集索引，且由于数据在物理上只会保存一份，所以聚簇索引只能有一个，而二级索引可以创建多个。

总结：

MySQL 默认的存储引擎 InnoDB 采用的是 B+ 作为索引的数据结构，原因有：

• B+ 树的非叶子节点不存放实际的记录数据，仅存放索引，因此数据量相同的情况下，相比存储即存索引又存记录的 B 树，B+树的非叶子节点可以存放更多的索引，因此 B+ 树可以比 B 树更「矮胖」，查询底层节点的磁盘 I/O次数会更少。
• B+ 树有大量的冗余节点（所有非叶子节点都是冗余索引），这些冗余索引让 B+ 树在插入、删除的效率都更高，比如删除根节点的时候，不会像 B 树那样会发生复杂的树的变化；
• B+ 树叶子节点之间用链表连接了起来，有利于范围查询，而 B 树要实现范围查询，因此只能通过树的遍历来完成范围查询，这会涉及多个节点的磁盘 I/O 操作，范围查询效率不如 B+ 树。

从数据页的角度看 B+ 树

MySQL 里 InnoDB 存储引擎是采用 B+ 树来组织数据的。

InnoDB 是如何存储数据的？

图解下InnoDB 是如何存储数据的。

记录是按照行来存储的，InnoDB 的数据是按「数据页」为单位来读写的。

数据库的 I/O 操作的最小单位是页，InnoDB 数据页的默认大小是 16KB，意味着数据库每次读写都是以 16KB 为单位的，一次最少从磁盘中读取 16K 的内容到内存中，一次最少把内存中的 16K 内容刷新到磁盘中。

数据页包括七个部分，结构如下图：

这 7 个部分的作用如下图：

在 File Header 中有两个指针，分别指向上一个数据页和下一个数据页，连接起来的页相当于一个双向的链表，如下图所示：

采用链表的结构是让数据页之间不需要是物理上的连续的，而是逻辑上的连续。

数据页的主要作用是存储记录，也就是数据库的数据。所以重点说一下数据页中的 User Records 是怎么组织数据的。

数据页中的记录按照「主键」顺序组成单向链表，单向链表的特点就是插入、删除非常方便，但是检索效率不高，最差的情况下需要遍历链表上的所有节点才能完成检索。

因此，数据页中有一个页目录，起到记录的索引作用。

就像我们书那样，针对书中内容的每个章节设立了一个目录，想看某个章节的时候，可以查看目录，快速找到对应的章节的页数，而数据页中的页目录就是为了能快速找到记录。

那 InnoDB 是如何给记录创建页目录的呢？页目录与记录的关系如下图：

页目录创建的过程如下：

1. 将所有的记录划分成几个组，这些记录包括最小记录和最大记录，但不包括标记为“已删除”的记录；
2. 每个记录组的最后一条记录就是组内最大的那条记录，并且最后一条记录的头信息中会存储该组一共有多少条记录，作为 n_owned 字段（上图中粉红色字段）
3. 页目录用来存储每组最后一条记录的地址偏移量，这些地址偏移量会按照先后顺序存储起来，每组的地址偏移量也被称之为槽（slot），每个槽相当于指针指向了不同组的最后一个记录。

从图可以看到，页目录就是由多个槽组成的，槽相当于分组记录的索引。然后，因为记录是按照「主键值」从小到大排序的，所以我们通过槽查找记录时，可以使用二分法快速定位要查询的记录在哪个槽（哪个记录分组），定位到槽后，再遍历槽内的所有记录，找到对应的记录，无需从最小记录开始遍历整个页中的记录链表。

以上面那张图举个例子，5 个槽的编号分别为 0，1，2，3，4，我想查找主键为 11 的用户记录：

• 先二分得出槽中间位是 (0+4)/2=2 ，2号槽里最大的记录为 8。因为 11 > 8，所以需要从 2 号槽后继续搜索记录；
• 再使用二分搜索出 2 号和 4 槽的中间位是 (2+4)/2= 3，3 号槽里最大的记录为 12。因为 11 < 12，所以主键为 11 的记录在 3 号槽里；
• 这里有个问题，「槽对应的值都是这个组的主键最大的记录，如何找到组里最小的记录」？比如槽 3 对应最大主键是 12 的记录，那如何找到最小记录 9。解决办法是：通过槽 3 找到 槽 2 对应的记录，也就是主键为 8 的记录。主键为 8 的记录的下一条记录就是槽 3 当中主键最小的 9 记录，然后开始向下搜索 2 次，定位到主键为 11 的记录，取出该条记录的信息即为我们想要查找的内容。

看到第三步的时候，可能有的同学会疑问，如果某个槽内的记录很多，然后因为记录都是单向链表串起来的，那这样在槽内查找某个记录的时间复杂度不就是 O(n) 了吗？

这点不用担心，InnoDB 对每个分组中的记录条数都是有规定的，槽内的记录就只有几条：

• 第一个分组中的记录只能有 1 条记录；
• 最后一个分组中的记录条数范围只能在 1-8 条之间；
• 剩下的分组中记录条数范围只能在 4-8 条之间。

B+ 树是如何进行查询的？

上面我们都是在说一个数据页中的记录检索，因为一个数据页中的记录是有限的，且主键值是有序的，所以通过对所有记录进行分组，然后将组号（槽号）存储到页目录，使其起到索引作用，通过二分查找的方法快速检索到记录在哪个分组，来降低检索的时间复杂度。

但是，当我们需要存储大量的记录时，就需要多个数据页，这时我们就需要考虑如何建立合适的索引，才能方便定位记录所在的页。

为了解决这个问题，InnoDB 采用了 B+ 树作为索引。磁盘的 I/O 操作次数对索引的使用效率至关重要，因此在构造索引的时候，我们更倾向于采用“矮胖”的 B+ 树数据结构，这样所需要进行的磁盘 I/O 次数更少，而且 B+ 树 更适合进行关键字的范围查询。

InnoDB 里的 B+ 树中的每个节点都是一个数据页，结构示意图如下：

通过上图，我们看出 B+ 树的特点：

• 只有叶子节点（最底层的节点）才存放了数据，非叶子节点（其他上层节）仅用来存放目录项作为索引。
• 非叶子节点分为不同层次，通过分层来降低每一层的搜索量；
• 所有节点按照索引键大小排序，构成一个双向链表，便于范围查询；

我们再看看 B+ 树如何实现快速查找主键为 6 的记录，以上图为例子：

• 从根节点开始，通过二分法快速定位到符合页内范围包含查询值的页，因为查询的主键值为 6，在[1, 7)范围之间，所以到页 30 中查找更详细的目录项；
• 在非叶子节点（页30）中，继续通过二分法快速定位到符合页内范围包含查询值的页，主键值大于 5，所以就到叶子节点（页16）查找记录；
• 接着，在叶子节点（页16）中，通过槽查找记录时，使用二分法快速定位要查询的记录在哪个槽（哪个记录分组），定位到槽后，再遍历槽内的所有记录，找到主键为 6 的记录。

可以看到，在定位记录所在哪一个页时，也是通过二分法快速定位到包含该记录的页。定位到该页后，又会在该页内进行二分法快速定位记录所在的分组（槽号），最后在分组内进行遍历查找。

聚簇索引和二级索引

另外，索引又可以分成聚簇索引和非聚簇索引（二级索引），它们区别就在于叶子节点存放的是什么数据：

• 聚簇索引的叶子节点存放的是实际数据，所有完整的用户记录都存放在聚簇索引的叶子节点；
• 二级索引的叶子节点存放的是主键值，而不是实际数据。

因为表的数据都是存放在聚簇索引的叶子节点里，所以 InnoDB 存储引擎一定会为表创建一个聚簇索引，且由于数据在物理上只会保存一份，所以聚簇索引只能有一个。

InnoDB 在创建聚簇索引时，会根据不同的场景选择不同的列作为索引：

• 如果有主键，默认会使用主键作为聚簇索引的索引键；
• 如果没有主键，就选择第一个不包含 NULL 值的唯一列作为聚簇索引的索引键；
• 在上面两个都没有的情况下，InnoDB 将自动生成一个隐式自增 id 列作为聚簇索引的索引键；

一张表只能有一个聚簇索引，那为了实现非主键字段的快速搜索，就引出了二级索引（非聚簇索引/辅助索引），它也是利用了 B+ 树的数据结构，但是二级索引的叶子节点存放的是主键值，不是实际数据。

二级索引的 B+ 树如下图，数据部分为主键值：

因此，如果某个查询语句使用了二级索引，但是查询的数据不是主键值，这时在二级索引找到主键值后，需要去聚簇索引中获得数据行，这个过程就叫作「回表」，也就是说要查两个 B+ 树才能查到数据。

当查询的数据是主键值时，因为只在二级索引就能查询到，不用再去聚簇索引查，这个过程就叫作「索引覆盖」，也就是只需要查一个 B+ 树就能找到数据。

MySQL 单表不要超过 2000W 行，靠谱吗？

索引失效有哪些？

索引存储结构长什么样？

在创建表时，InnoDB 存储引擎默认会创建一个主键索引，也就是聚簇索引，其它索引都属于二级索引。

在我们使用「主键索引」字段作为条件查询的时候，如果要查询的数据都在「聚簇索引」的叶子节点里，那么就会在「聚簇索引」中的 B+ 树检索到对应的叶子节点，然后直接读取要查询的数据。如下面这条语句：

// id 字段为主键索引
select * from t_user where id=1;

回表

在我们使用「二级索引」字段作为条件查询的时候，如果要查询的数据都在「聚簇索引」的叶子节点里，那么需要检索两颗B+树：

• 先在「二级索引」的 B+ 树找到对应的叶子节点，获取对应的主键值；
• 然后用上一步获取的主键值，在「聚簇索引」中的 B+ 树检索到对应的叶子节点/整行数据，然后获取要查询的数据。

上面这个过程叫做回表，如下面这条语句：

// name 字段为二级索引
select * from t_user where name="林某";

覆盖索引

在我们使用「二级索引」字段作为条件查询的时候，如果要查询的数据在「二级索引」的叶子节点，那么只需要在「二级索引」的 B+ 树找到对应的叶子节点，然后读取要查询的数据，这个过程叫做覆盖索引。如下面这条语句：

// name 字段为二级索引
select id from t_user where name="林某";

上面这些查询语句的条件都用到了索引列，所以在查询过程都用上了索引。

但是并不意味着，查询条件用上了索引列，就查询过程就一定都用上索引.

接下来我们再一起看看哪些情况会导致索引失效，而发生全表扫描。

索引失效

1. 对索引使用左或者左右模糊匹配

当我们使用左或者左右模糊匹配的时候，也就是 like %xx 或者 like %xx% 这两种方式都会造成索引失效。

比如下面的 like 语句，查询 name 后缀为「林」的用户，执行计划中的 type=ALL 就代表了全表扫描，而没有走索引。

// name 字段为二级索引
select * from t_user where name like '%林';

如果是查询 name 前缀为林的用户，那么就会走索引扫描，执行计划中的 type=range 表示走索引扫描，key=index_name 看到实际走了 index_name 索引：

// name 字段为二级索引
select * from t_user where name like '林%';

为什么 like 关键字左或者左右模糊匹配无法走索引呢？

因为索引 B+ 树是按照「索引值」有序排列存储的，只能根据前缀进行比较。

举个例子，下面这张二级索引图（图中叶子节点之间我画了单向链表，但是实际上是双向链表，原图我找不到了，修改不了，偷个懒我不重画了，大家脑补成双向链表就行），是以 name 字段有序排列存储的。

假设我们要查询 name 字段前缀为「林」的数据，也就是 name like '林%'，扫描索引的过程：

• 首节点查询比较：林这个字的拼音大小比首节点的第一个索引值中的陈字大，但是比首节点的第二个索引值中的周字小，所以选择去节点2继续查询；
• 节点 2 查询比较：节点2的第一个索引值中的陈字的拼音大小比林字小，所以继续看下一个索引值，发现节点2有与林字前缀匹配的索引值，于是就往叶子节点查询，即叶子节点4；
• 节点 4 查询比较：节点4的第一个索引值的前缀符合林字，于是就读取该行数据，接着继续往右匹配，直到匹配不到前缀为林的索引值。

如果使用 name like '%林' 方式来查询，因为查询的结果可能是「陈林、张林、周林」等之类的，所以不知道从哪个索引值开始比较，于是就只能通过全表扫描的方式来查询。

2. 对索引使用函数

有时候我们会用一些 MySQL 自带的函数来得到我们想要的结果，这时候要注意了，如果查询条件中对索引字段使用函数，就会导致索引失效。

比如下面这条语句查询条件中对 name 字段使用了 LENGTH 函数，执行计划中的 type=ALL，代表了全表扫描：

// name 为二级索引
select * from t_user where length(name)=6;

为什么对索引使用函数，就无法走索引了呢？

因为索引保存的是索引字段的原始值，而不是经过函数计算后的值，自然就没办法走索引了。

不过，从 MySQL 8.0 开始，索引特性增加了函数索引，即可以针对函数计算后的值建立一个索引，也就是说该索引的值是函数计算后的值，所以就可以通过扫描索引来查询数据。

举个例子，我通过下面这条语句，对 length(name) 的计算结果建立一个名为 idx_name_length 的索引。

alter table t_user add key idx_name_length ((length(name)));

然后我再用下面这条查询语句，这时候就会走索引了。

3. 对索引进行表达式计算

在查询条件中对索引进行表达式计算，也是无法走索引的。

比如，下面这条查询语句，执行计划中 type = ALL，说明是通过全表扫描的方式查询数据的：

explain select * from t_user where id + 1 = 10;

但是，如果把查询语句的条件改成 where id = 10 - 1，这样就不是在索引字段进行表达式计算了，于是就可以走索引查询了。

为什么对索引进行表达式计算，就无法走索引了呢？

原因跟对索引使用函数差不多。

因为索引保存的是索引字段的原始值，而不是 id + 1 表达式计算后的值，所以无法走索引，只能通过把索引字段的取值都取出来，然后依次进行表达式的计算来进行条件判断，因此采用的就是全表扫描的方式。

有的同学可能会说，这种对索引进行简单的表达式计算，在代码特殊处理下，应该是可以做到索引扫描的，比方将 id + 1 = 10 变成 id = 10 - 1。

是的，是能够实现，但是 MySQL 还是偷了这个懒，没有实现。

我的想法是，可能也是因为，表达式计算的情况多种多样，每种都要考虑的话，代码可能会很臃肿，所以干脆将这种索引失效的场景告诉程序员，让程序员自己保证在查询条件中不要对索引进行表达式计算。

4. 对索引隐式类型转换

如果索引字段是字符串类型，但是在条件查询中，输入的参数是整型的话，你会在执行计划的结果发现这条语句会走全表扫描。

我在原本的 t_user 表增加了 phone 字段，是二级索引且类型是 varchar。

然后我在条件查询中，用整型作为输入参数，此时执行计划中 type = ALL，所以是通过全表扫描来查询数据的。

select * from t_user where phone = 1300000001;

但是如果索引字段是整型类型，查询条件中的输入参数即使字符串，是不会导致索引失效，还是可以走索引扫描。

我们再看第二个例子，id 是整型，但是下面这条语句还是走了索引扫描的。

 explain select * from t_user where id = '1';

为什么第一个例子会导致索引失效，而第二例子不会呢？

MySQL 的数据类型转换规则是什么？就是看 MySQL 是会将字符串转成数字处理，还是将数字转换成字符串处理。

通过 select “10” > 9 的结果来知道MySQL 的数据类型转换规则是什么：

• 如果规则是 MySQL 会将自动「字符串」转换成「数字」，就相当于 select 10 > 9，这个就是数字比较，所以结果应该是 1；
• 如果规则是 MySQL 会将自动「数字」转换成「字符串」，就相当于 select "10" > "9"，这个是字符串比较，字符串比较大小是逐位从高位到低位逐个比较（按ascii码） ，那么"10"字符串相当于 “1”和“0”字符的组合，所以先是拿 “1” 字符和 “9” 字符比较，因为 “1” 字符比 “9” 字符小，所以结果应该是 0。

在 MySQL 中，执行的结果如下图：

上面的结果为 1，说明 MySQL 在遇到字符串和数字比较的时候，会自动把字符串转为数字，然后再进行比较。

前面的例子一中的查询语句，我也跟大家说了是会走全表扫描：

//例子一的查询语句
select * from t_user where phone = 1300000001;

这是因为phone 字段为字符串，所以 MySQL 要会自动把字符串转为数字，所以这条语句相当于：

select * from t_user where CAST(phone AS signed int) = 1300000001;

CAST 函数是作用在了 phone 字段，而 phone 字段是索引，也就是对索引使用了函数！

而前面我们也说了，对索引使用函数是会导致索引失效的。

例子二中的查询语句，我跟大家说了是会走索引扫描：

//例子二的查询语句
select * from t_user where id = "1";

这时因为字符串部分是输入参数，也就需要将字符串转为数字，所以这条语句相当于：

select * from t_user where id = CAST("1" AS signed int);

可以看到，索引字段并没有用任何函数，CAST 函数是用在了输入参数，因此是可以走索引扫描的。

5. 联合索引非最左匹配

对主键字段建立的索引叫做聚簇索引，对普通字段建立的索引叫做二级索引。

那么多个普通字段组合在一起创建的索引就叫做联合索引，也叫组合索引。

创建联合索引时，我们需要注意创建时的顺序问题，因为联合索引 (a, b, c) 和 (c, b, a) 在使用的时候会存在差别。

联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配。

比如，如果创建了一个 (a, b, c) 联合索引，如果查询条件是以下这几种，就可以匹配上联合索引：

• where a=1；
• where a=1 and b=2 and c=3；
• where a=1 and b=2；

需要注意的是，因为有查询优化器，所以 a 字段在 where 子句的顺序并不重要。

但是，如果查询条件是以下这几种，因为不符合最左匹配原则，所以就无法匹配上联合索引，联合索引就会失效:

• where b=2；
• where c=3；
• where b=2 and c=3；

有一个比较特殊的查询条件：where a = 1 and c = 3，符合最左匹配吗？

这种其实严格意义上来说是属于索引截断，不同版本处理方式也不一样。

MySQL 5.5 的话，前面 a 会走索引，在联合索引找到主键值后，开始回表，到主键索引读取数据行，Server 层从存储引擎层获取到数据行后，然后在 Server 层再比对 c 字段的值。

从 MySQL 5.6 之后，有一个索引下推功能，可以在存储引擎层进行索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，再返还给 Server 层，从而减少回表次数。

索引下推的大概原理是：截断的字段不会在 Server 层进行条件判断，而是会被下推到「存储引擎层」进行条件判断（因为 c 字段的值是在 (a, b, c) 联合索引里的），然后过滤出符合条件的数据后再返回给 Server 层。由于在引擎层就过滤掉大量的数据，无需再回表读取数据来进行判断，减少回表次数，从而提升了性能。

比如下面这条 where a = 1 and c = 0 语句，我们可以从执行计划中的 Extra=Using index condition 使用了索引下推功能。

为什么联合索引不遵循最左匹配原则就会失效？

原因是，在联合索引的情况下，数据是按照索引第一列排序，第一列数据相同时才会按照第二列排序。

首先按照 a 列的值排序，当 a 列的值相同时，再按照 b 列的值排序，以此类推。这种存储方式确保了数据在物理或逻辑上是有序的。

如果查询条件是 where a=1，数据库可以快速跳到索引中 a=1 的部分；如果条件是 where a=1 and b=2，数据库先定位到 a=1 的区间，然后在这个子区间中进一步定位到 b=2。

比如只有 where b=2 或 where c=3，数据库就不能直接利用索引的有序性质来快速定位数据。这是因为在没有 a 列值的情况下，b 或 c 列的任何特定值都可能分布在索引的多个位置，数据库无法仅通过这些值快速确定数据的位置。因此，它要么退回到全表扫描，要么试图找到其他更合适的索引。

实际例子

假设你有一本按章节（Chapter），段落（Paragraph），句子（Sentence）顺序组织的书的索引。如果你想找到第3章的内容，可以直接翻到索引中标明“第3章”的部分。如果你想找到第3章第2段的内容，你也可以很容易地做到，因为书的索引是首先按章节，然后是段落来组织的。但是，如果你想找到所有包含特定句子的段落而不指定章节，你就需要查阅整本书，因为索引是基于章节和段落顺序创建的，没有直接按照句子内容排序的索引。

也就是说，如果我们想使用联合索引中尽可能多的列，查询条件中的各个列必须是联合索引中从最左边开始连续的列。如果我们仅仅按照第二列搜索，肯定无法走索引。

6. WHERE 子句中的 OR

在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。

举个例子，比如下面的查询语句，id 是主键，age 是普通列，从执行计划的结果看，是走了全表扫描。

select * from t_user where id = 1 or age = 18;

这是因为 OR 的含义就是两个只要满足一个即可，因此只有一个条件列是索引列是没有意义的，只要有条件列不是索引列，就会进行全表扫描。

要解决办法很简单，将 age 字段设置为索引即可。

可以看到 type=index merge， index merge 的意思就是对 id 和 age 分别进行了扫描，然后将这两个结果集进行了合并，这样做的好处就是避免了全表扫描。

索引失效总结：

今天给大家介绍了 6 种会发生索引失效的情况：

• 当我们使用左或者左右模糊匹配的时候，也就是 like %xx 或者 like %xx%这两种方式都会造成索引失效；
• 当我们在查询条件中对索引列使用函数，就会导致索引失效。
• 当我们在查询条件中对索引列进行表达式计算，也是无法走索引的。
• MySQL 在遇到字符串和数字比较的时候，会自动把字符串转为数字，然后再进行比较。如果字符串是索引列，而条件语句中的输入参数是数字的话，那么索引列会发生隐式类型转换，由于隐式类型转换是通过 CAST 函数实现的，等同于对索引列使用了函数，所以就会导致索引失效。
• 联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配，否则就会导致索引失效。
• 在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。

想要判断出这条sql是否有索引失效的情况，可以使用 explain执行计划来分析

MySQL 使用 like “%x“，索引一定会失效吗？

题目1

「题目 1 」的数据库表如下，id 是主键索引，name 是二级索引，其他字段都是非索引字段

一条和第二条都会走索引扫描，而且都是选择扫描二级索引（index_name）

第三和第四条会发生索引失效，执行计划的结果 type= ALL，代表了全表扫描。

题目2

题目 2 的数据库表特别之处在于，只有两个字段，一个是主键索引 id，另外一个是二级索引 name。

针对题目 2 的数据表，第一条和第二条模糊查询语句也是一样可以走索引扫描，第二条查询语句的执行计划如下，Extra 里的 Using index 说明用上了覆盖索引：

我们来看一下第三条查询语句的执行计划（第四条也是一样的结果）：

从执行计划的结果中，可以看到 key=index_name，也就是说用上了二级索引，而且从 Extra 里的 Using index 说明用上了覆盖索引。

这是为什么呢？

首先，这张表的字段没有「非索引」字段，所以 select * 相当于 select id,name，然后这个查询的数据都在二级索引的 B+ 树，因为二级索引的 B+ 树的叶子节点包含「索引值+主键值」，所以查二级索引的 B+ 树就能查到全部结果了，这个就是覆盖索引。

但是执行计划里的 type 是 index，这代表着是通过全扫描二级索引的 B+ 树的方式查询到数据的，也就是遍历了整颗索引树。

而第一和第二条查询语句的执行计划中 type 是 range，表示对索引列进行范围查询，也就是利用了索引树的有序性的特点，通过查询比较的方式，快速定位到了数据行。

所以，type=range 的查询效率会比 type=index 的高一些。

---

从这个思考题我们知道了，使用左模糊匹配（like "%xx"）并不一定会走全表扫描，关键还是看数据表中的字段。

如果数据库表中的字段只有主键+二级索引，那么即使使用了左模糊匹配，也不会走全表扫描（type=all），而是走全扫描二级索引树(type=index)。

count(*) 和 count(1) 有什么区别？哪个性能最好？

总结

事物篇

事务隔离级别是怎么实现的？

事务特性ACID

• 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节，而且事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样，就好比买一件商品，购买成功时，则给商家付了钱，商品到手；购买失败时，则商品在商家手中，消费者的钱也没花出去。
• 一致性（Consistency）：是指事务操作前和操作后，数据满足完整性约束，数据库保持一致性状态。比如，用户 A 和用户 B 在银行分别有 800 元和 600 元，总共 1400 元，用户 A 给用户 B 转账 200 元，分为两个步骤，从 A 的账户扣除 200 元和对 B 的账户增加 200 元。一致性就是要求上述步骤操作后，最后的结果是用户 A 还有 600 元，用户 B 有 800 元，总共 1400 元，而不会出现用户 A 扣除了 200 元，但用户 B 未增加的情况（该情况，用户 A 和 B 均为 600 元，总共 1200 元）。
• 隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致，因为多个事务同时使用相同的数据时，不会相互干扰，每个事务都有一个完整的数据空间，对其他并发事务是隔离的。也就是说，消费者购买商品这个事务，是不影响其他消费者购买的。
• 持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

​

我举个例子： A向B转账500，转账成功，A扣除500元，B增加500元，原子操作体现在要么都成功，要么都失败

在转账的过程中，数据要一致，A扣除了500，B必须增加500

在转账的过程中，隔离性体现在A像B转账，不能受其他事务干扰

在转账的过程中，持久性体现在事务提交后，要把数据持久化（可以说是落 盘操作）

InnoDB 引擎通过什么技术来保证事务四个特性的呢？

• 持久性是通过 redo log （重做日志）来保证的；
• 原子性是通过 undo log（回滚日志） 来保证的；
• 隔离性是通过 MVCC（多版本并发控制） 或锁机制来保证的；
• 一致性则是通过持久性+原子性+隔离性来保证；

只有保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。也就是说 A、I、D 是手段，C 是目的！

并行事务会引发什么问题？

1. 脏读

如果一个事务「读到」了另一个「未提交事务修改过的数据」，就意味着发生了「脏读」现象。

假设有 A 和 B 这两个事务同时在处理，事务 A 先开始从数据库中读取小林的余额数据，然后再执行更新操作，如果此时事务 A 还没有提交事务，而此时正好事务 B 也从数据库中读取小林的余额数据，那么事务 B 读取到的余额数据是刚才事务 A 更新后的数据，即使没有提交事务。

因为事务 A 是还没提交事务的，也就是它随时可能发生回滚操作，如果在上面这种情况事务 A 发生了回滚，那么事务 B 刚才得到的数据就是过期的数据，这种现象就被称为脏读。

2. 不可重复读

在一个事务内多次读取同一个数据，如果出现前后两次读到的数据不一样的情况，就意味着发生了「不可重复读」现象。

假设有 A 和 B 这两个事务同时在处理，事务 A 先开始从数据库中读取小林的余额数据，然后继续执行代码逻辑处理，在这过程中如果事务 B 更新了这条数据，并提交了事务，那么当事务 A 再次读取该数据时，就会发现前后两次读到的数据是不一致的，这种现象就被称为不可重复读。

3. 幻读

在一个事务内多次查询某个符合查询条件的「记录数量」，如果出现前后两次查询到的记录数量不一样的情况，就意味着发生了「幻读」现象。

假设有 A 和 B 这两个事务同时在处理，事务 A 先开始从数据库查询账户余额大于 100 万的记录，发现共有 5 条，然后事务 B 也按相同的搜索条件也是查询出了 5 条记录。

接下来，事务 A 插入了一条余额超过 100 万的账号，并提交了事务，此时数据库超过 100 万余额的账号个数就变为 6。

然后事务 B 再次查询账户余额大于 100 万的记录，此时查询到的记录数量有 6 条，发现和前一次读到的记录数量不一样了，就感觉发生了幻觉一样，这种现象就被称为幻读。

事务的隔离级别有哪些？

• 脏读：读到其他事务未提交的数据；
• 不可重复读：前后读取的数据不一致；
• 幻读：前后读取的记录数量不一致。

严重性依次递减。

SQL 标准提出了四种隔离级别来规避这些现象，隔离级别越高，性能效率就越低，这四个隔离级别如下：

• 读未提交（*read uncommitted*），指一个事务还没提交时，它做的变更就能被其他事务看到；
• 读提交（*read committed*），指一个事务提交之后，它做的变更才能被其他事务看到；
• 可重复读（*repeatable read*），指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，MySQL InnoDB 引擎的默认隔离级别；
• 串行化（*serializable* ）；会对记录加上读写锁，在多个事务对这条记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行；

隔离级别依次增加

针对不同的隔离级别，并发事务时可能发生的现象也会不同。

MySQL 在「可重复读」隔离级别下，可以很大程度上避免幻读现象的发生（注意是很大程度避免，并不是彻底避免），所以 MySQL 并不会使用「串行化」隔离级别来避免幻读现象的发生，因为使用「串行化」隔离级别会影响性能。

接下来，举个具体的例子来说明这四种隔离级别，有一张账户余额表，里面有一条账户余额为 100 万的记录。然后有两个并发的事务，事务 A 只负责查询余额，事务 B 则会将我的余额改成 200 万，下面是按照时间顺序执行两个事务的行为：

在不同隔离级别下，事务 A 执行过程中查询到的余额可能会不同：

• 在「读未提交」隔离级别下，事务 B 修改余额后，虽然没有提交事务，但是此时的余额已经可以被事务 A 看见了，于是事务 A 中余额 V1 查询的值是 200 万，余额 V2、V3 自然也是 200 万了；
• 在「读提交」隔离级别下，事务 B 修改余额后，因为没有提交事务，所以事务 A 中余额 V1 的值还是 100 万，等事务 B 提交完后，最新的余额数据才能被事务 A 看见，因此额 V2、V3 都是 200 万；
• 在「可重复读」隔离级别下，事务 A 只能看见启动事务时的数据，所以余额 V1、余额 V2 的值都是 100 万，当事务 A 提交事务后，就能看见最新的余额数据了，所以余额 V3 的值是 200 万；
• 在「串行化」隔离级别下，事务 B 在执行将余额 100 万修改为 200 万时，由于此前事务 A 执行了读操作，这样就发生了读写冲突，于是就会被锁住，直到事务 A 提交后，事务 B 才可以继续执行，所以从 A 的角度看，余额 V1、V2 的值是 100 万，余额 V3 的值是 200万。

这四种隔离级别具体是如何实现的呢？

• 对于「读未提交」隔离级别的事务来说，因为可以读到未提交事务修改的数据，所以直接读取最新的数据就好了；

• 对于「读提交」和「可重复读」隔离级别的事务来说，它们是通过 Read View *来实现的，它们的区别在于创建 Read View 的时机不同，大家可以把 Read View 理解成一个数据快照，就像相机拍照那样，定格某一时刻的风景。*「读提交」隔离级别是在「每个语句执行前」都会重新生成一个 Read View，而「可重复读」隔离级别是「启动事务时」生成一个 Read View，然后整个事务期间都在用这个 Read View。

• 对于「串行化」隔离级别的事务来说，通过加读写锁的方式来避免并行访问；

注意，执行「开始事务」命令，并不意味着启动了事务。在 MySQL 有两种开启事务的命令，分别是：

• 第一种：begin/start transaction 命令；
• 第二种：start transaction with consistent snapshot 命令；

这两种开启事务的命令，事务的启动时机是不同的：

• 执行了 begin/start transaction 命令后，并不代表事务启动了。只有在执行这个命令后，执行了第一条 select 语句，才是事务真正启动的时机；
• 执行了 start transaction with consistent snapshot 命令，就会马上启动事务。

MVCC

多版本并发控制（Multi-Version Concurrency Control）

MVCC 是一种并发控制机制，用于在多个并发事务同时读写数据库时保持数据的一致性和隔离性。它是通过在每个数据行上维护多个版本的数据来实现的。当一个事务要对数据库中的数据进行修改时，MVCC 会为该事务创建一个数据快照，而不是直接修改实际的数据行。

1、读操作（SELECT）：

当一个事务执行读操作时，它会使用快照读取。快照读取是基于事务开始时数据库中的状态创建的，因此事务不会读取其他事务尚未提交的修改。具体工作情况如下：

• 对于读取操作，事务会查找符合条件的数据行，并选择符合其事务开始时间的数据版本进行读取。
• 如果某个数据行有多个版本，事务会选择不晚于其开始时间的最新版本，确保事务只读取在它开始之前已经存在的数据。
• 事务读取的是快照数据，因此其他并发事务对数据行的修改不会影响当前事务的读取操作。

2、写操作（INSERT、UPDATE、DELETE）：

当一个事务执行写操作时，它会生成一个新的数据版本，并将修改后的数据写入数据库。具体工作情况如下：

• 对于写操作，事务会为要修改的数据行创建一个新的版本，并将修改后的数据写入新版本。
• 新版本的数据会带有当前事务的版本号，以便其他事务能够正确读取相应版本的数据。
• 原始版本的数据仍然存在，供其他事务使用快照读取，这保证了其他事务不受当前事务的写操作影响。

3、事务提交和回滚：

• 当一个事务提交时，它所做的修改将成为数据库的最新版本，并且对其他事务可见。
• 当一个事务回滚时，它所做的修改将被撤销，对其他事务不可见。

4、版本的回收：

为了防止数据库中的版本无限增长，MVCC 会定期进行版本的回收。回收机制会删除已经不再需要的旧版本数据，从而释放空间。

MVCC 通过创建数据的多个版本和使用快照读取来实现并发控制。读操作使用旧版本数据的快照，写操作创建新版本，并确保原始版本仍然可用。这样，不同的事务可以在一定程度上并发执行，而不会相互干扰，从而提高了数据库的并发性能和数据一致性。

Read View 在 MVCC 里如何工作的？

可重复读是如何工作的？

读提交是如何工作的？

事务中的隔离性如何保证/解释MVCC

事务的隔离性是由锁和mvcc实现的。 其中mvcc的意思是多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，它的底层实现主要是分为了三个部分，第一个是隐藏字段， 第二个是undo log日志，第三个是readView读视图

• 隐藏字段是指：在mysql中给每个表都设置了隐藏字段，有一个是trx_id(事 务id)，记录每一次操作的事务id，是自增的；另一个字段是roll_pointer(回滚指针)，指向上一个版本的事务版本记录地址
• undo log主要的作用是记录回滚日志，存储老版本数据，在内部会形成一个 版本链，在多个事务并行操作某一行记录，记录不同事务修改数据的版本， 通过roll_pointer指针形成一个链表
• readView解决的是一个事务查询选择版本的问题，在内部定义了一些匹配规 则和当前的一些事务id判断该访问那个版本的数据，不同的隔离级别快照读 是不一样的，最终的访问的结果不一样。如果是rc隔离级别，每一次执行快 照读时生成ReadView，如果是rr隔离级别仅在事务中第一次执行快照读时生 成ReadView，后续复用

总结

MySQL 可重复读隔离级别，完全解决幻读了吗？

• 针对快照读（普通 select 语句），是通过 MVCC 方式解决了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。
• 针对当前读（select ... for update 等语句），是通过 next-key lock（记录锁+间隙锁）方式解决了幻读，因为当执行 select ... for update 语句的时候，会加上 next-key lock，如果有其他事务在 next-key lock 锁范围内插入了一条记录，那么这个插入语句就会被阻塞，无法成功插入，所以就很好了避免幻读问题。

什么是幻读？

快照读是如何避免幻读的？

当前读是如何避免幻读的？

幻读被完全解决了吗？

第一个发生幻读现象的场景

第二个发生幻读现象的场景

总结

锁篇

MySQL 有哪些锁？

全局锁

全局锁是怎么用的？

要使用全局锁，则要执行这条命令：

flush tables with read lock

执行后，整个数据库就处于只读状态了，这时其他线程执行以下操作，都会被阻塞：

• 对数据的增删改操作，比如 insert、delete、update等语句；
• 对表结构的更改操作，比如 alter table、drop table 等语句。

如果要释放全局锁，则要执行这条命令：

unlock tables

当然，当会话断开了，全局锁会被自动释放。

全局锁应用场景是什么？

全局锁主要应用于做全库逻辑备份，这样在备份数据库期间，不会因为数据或表结构的更新，而出现备份文件的数据与预期的不一样。

举个例子大家就知道了。

在全库逻辑备份期间，假设不加全局锁的场景，看看会出现什么意外的情况。

如果在全库逻辑备份期间，有用户购买了一件商品，一般购买商品的业务逻辑是会涉及到多张数据库表的更新，比如在用户表更新该用户的余额，然后在商品表更新被购买的商品的库存。

那么，有可能出现这样的顺序：

1. 先备份了用户表的数据；
2. 然后有用户发起了购买商品的操作；
3. 接着再备份商品表的数据。

也就是在备份用户表和商品表之间，有用户购买了商品。

这种情况下，备份的结果是用户表中该用户的余额并没有扣除，反而商品表中该商品的库存被减少了，如果后面用这个备份文件恢复数据库数据的话，用户钱没少，而库存少了，等于用户白嫖了一件商品。

所以，在全库逻辑备份期间，加上全局锁，就不会出现上面这种情况了。

加全局锁又会带来什么缺点呢？

加上全局锁，意味着整个数据库都是只读状态。

那么如果数据库里有很多数据，备份就会花费很多的时间，关键是备份期间，业务只能读数据，而不能更新数据，这样会造成业务停滞。

既然备份数据库数据的时候，使用全局锁会影响业务，那有什么其他方式可以避免？

有的，如果数据库的引擎支持的事务支持可重复读的隔离级别，那么在备份数据库之前先开启事务，会先创建 Read View，然后整个事务执行期间都在用这个 Read View，而且由于 MVCC 的支持，备份期间业务依然可以对数据进行更新操作。

因为在可重复读的隔离级别下，即使其他事务更新了表的数据，也不会影响备份数据库时的 Read View，这就是事务四大特性中的隔离性，这样备份期间备份的数据一直是在开启事务时的数据。

备份数据库的工具是 mysqldump，在使用 mysqldump 时加上 –single-transaction 参数的时候，就会在备份数据库之前先开启事务。这种方法只适用于支持「可重复读隔离级别的事务」的存储引擎。

InnoDB 存储引擎默认的事务隔离级别正是可重复读，因此可以采用这种方式来备份数据库。

但是，对于 MyISAM 这种不支持事务的引擎，在备份数据库时就要使用全局锁的方法。

表级锁

表锁

如果我们想对学生表（t_student）加表锁，可以使用下面的命令：

//表级别的共享锁，也就是读锁；
lock tables t_student read;

//表级别的独占锁，也就是写锁；
lock tables t_stuent write;

需要注意的是，表锁除了会限制别的线程的读写外，也会限制本线程接下来的读写操作。

也就是说如果本线程对学生表加了「共享表锁」，那么本线程接下来如果要对学生表执行写操作的语句，是会被阻塞的，当然其他线程对学生表进行写操作时也会被阻塞，直到锁被释放。

要释放表锁，可以使用下面这条命令，会释放当前会话的所有表锁：

unlock tables

另外，当会话退出后，也会释放所有表锁。

不过尽量避免在使用 InnoDB 引擎的表使用表锁，因为表锁的颗粒度太大，会影响并发性能，InnoDB 牛逼的地方在于实现了颗粒度更细的行级锁。

元数据锁（MDL）

我们不需要显示的使用 MDL，因为当我们对数据库表进行操作时，会自动给这个表加上 MDL：

• 对一张表进行 CRUD 操作时，加的是 MDL 读锁；
• 对一张表做结构变更操作的时候，加的是 MDL 写锁；

MDL 是为了保证当用户对表执行 CRUD 操作时，防止其他线程对这个表结构做了变更。

当有线程在执行 select 语句（ 加 MDL 读锁）的期间，如果有其他线程要更改该表的结构（ 申请 MDL 写锁），那么将会被阻塞，直到执行完 select 语句（ 释放 MDL 读锁）。

反之，当有线程对表结构进行变更（ 加 MDL 写锁）的期间，如果有其他线程执行了 CRUD 操作（ 申请 MDL 读锁），那么就会被阻塞，直到表结构变更完成（ 释放 MDL 写锁）。

MDL 不需要显示调用，那它是在什么时候释放的?

MDL 是在事务提交后才会释放，这意味着事务执行期间，MDL 是一直持有的。

那如果数据库有一个长事务（所谓的长事务，就是开启了事务，但是一直还没提交），那在对表结构做变更操作的时候，可能会发生意想不到的事情，比如下面这个顺序的场景：

1. 首先，线程 A 先启用了事务（但是一直不提交），然后执行一条 select 语句，此时就先对该表加上 MDL 读锁；
2. 然后，线程 B 也执行了同样的 select 语句，此时并不会阻塞，因为「读读」并不冲突；
3. 接着，线程 C 修改了表字段，此时由于线程 A 的事务并没有提交，也就是 MDL 读锁还在占用着，这时线程 C 就无法申请到 MDL 写锁，就会被阻塞，

那么在线程 C 阻塞后，后续有对该表的 select 语句，就都会被阻塞，如果此时有大量该表的 select 语句的请求到来，就会有大量的线程被阻塞住，这时数据库的线程很快就会爆满了。

为什么线程 C 因为申请不到 MDL 写锁，而导致后续的申请读锁的查询操作也会被阻塞？

这是因为申请 MDL 锁的操作会形成一个队列，队列中写锁获取优先级高于读锁，一旦出现 MDL 写锁等待，会阻塞后续该表的所有 CRUD 操作。

所以为了能安全的对表结构进行变更，在对表结构变更前，先要看看数据库中的长事务，是否有事务已经对表加上了 MDL 读锁，如果可以考虑 kill 掉这个长事务，然后再做表结构的变更。

意向锁

• 在使用 InnoDB 引擎的表里对某些记录加上「共享锁」之前，需要先在表级别加上一个「意向共享锁」；
• 在使用 InnoDB 引擎的表里对某些纪录加上「独占锁」之前，需要先在表级别加上一个「意向独占锁」；

也就是，当执行插入、更新、删除操作，需要先对表加上「意向独占锁」，然后对该记录加独占锁。

而普通的 select 是不会加行级锁的，普通的 select 语句是利用 MVCC 实现一致性读，是无锁的。

不过，select 也是可以对记录加共享锁和独占锁的，具体方式如下：

//先在表上加上意向共享锁，然后对读取的记录加共享锁
select ... lock in share mode;

//先表上加上意向独占锁，然后对读取的记录加独占锁
select ... for update;

意向共享锁和意向独占锁是表级锁，不会和行级的共享锁和独占锁发生冲突，而且意向锁之间也不会发生冲突，只会和共享表锁（*lock tables ... read*）和独占表锁（*lock tables ... write*）发生冲突。

表锁和行锁是满足读读共享、读写互斥、写写互斥的。

如果没有「意向锁」，那么加「独占表锁」时，就需要遍历表里所有记录，查看是否有记录存在独占锁，这样效率会很慢。

那么有了「意向锁」，由于在对记录加独占锁前，先会加上表级别的意向独占锁，那么在加「独占表锁」时，直接查该表是否有意向独占锁，如果有就意味着表里已经有记录被加了独占锁，这样就不用去遍历表里的记录。

所以，意向锁的目的是为了快速判断表里是否有记录被加锁。

AUTO-INC 锁

表里的主键通常都会设置成自增的，这是通过对主键字段声明 AUTO_INCREMENT 属性实现的。

之后可以在插入数据时，可以不指定主键的值，数据库会自动给主键赋值递增的值，这主要是通过 AUTO-INC 锁实现的。

AUTO-INC 锁是特殊的表锁机制，锁不是再一个事务提交后才释放，而是再执行完插入语句后就会立即释放。

在插入数据时，会加一个表级别的 AUTO-INC 锁，然后为被 AUTO_INCREMENT 修饰的字段赋值递增的值，等插入语句执行完成后，才会把 AUTO-INC 锁释放掉。

那么，一个事务在持有 AUTO-INC 锁的过程中，其他事务的如果要向该表插入语句都会被阻塞，从而保证插入数据时，被 AUTO_INCREMENT 修饰的字段的值是连续递增的。

但是， AUTO-INC 锁再对大量数据进行插入的时候，会影响插入性能，因为另一个事务中的插入会被阻塞。

因此， 在 MySQL 5.1.22 版本开始，InnoDB 存储引擎提供了一种轻量级的锁来实现自增。

一样也是在插入数据的时候，会为被 AUTO_INCREMENT 修饰的字段加上轻量级锁，然后给该字段赋值一个自增的值，就把这个轻量级锁释放了，而不需要等待整个插入语句执行完后才释放锁。

InnoDB 存储引擎提供了个 innodb_autoinc_lock_mode 的系统变量，是用来控制选择用 AUTO-INC 锁，还是轻量级的锁。

• 当 innodb_autoinc_lock_mode = 0，就采用 AUTO-INC 锁，语句执行结束后才释放锁；
• 当 innodb_autoinc_lock_mode = 2，就采用轻量级锁，申请自增主键后就释放锁，并不需要等语句执行后才释放。
• 当 innodb_autoinc_lock_mode = 1：
  • 普通 insert 语句，自增锁在申请之后就马上释放；
  • 类似 insert … select 这样的批量插入数据的语句，自增锁还是要等语句结束后才被释放；

当 innodb_autoinc_lock_mode = 2 是性能最高的方式，但是当搭配 binlog 的日志格式是 statement 一起使用的时候，在「主从复制的场景」中会发生数据不一致的问题。

举个例子，考虑下面场景：

session A 往表 t 中插入了 4 行数据，然后创建了一个相同结构的表 t2，然后两个 session 同时执行向表 t2 中插入数据。

如果 innodb_autoinc_lock_mode = 2，意味着「申请自增主键后就释放锁，不必等插入语句执行完」。那么就可能出现这样的情况：

• session B 先插入了两个记录，(1,1,1)、(2,2,2)；
• 然后，session A 来申请自增 id 得到 id=3，插入了（3,5,5)；
• 之后，session B 继续执行，插入两条记录 (4,3,3)、 (5,4,4)。

可以看到，session B 的 insert 语句，生成的 id 不连续。

当「主库」发生了这种情况，binlog 面对 t2 表的更新只会记录这两个 session 的 insert 语句，如果 binlog_format=statement，记录的语句就是原始语句。记录的顺序要么先记 session A 的 insert 语句，要么先记 session B 的 insert 语句。

但不论是哪一种，这个 binlog 拿去「从库」执行，这时从库是按「顺序」执行语句的，只有当执行完一条 SQL 语句后，才会执行下一条 SQL。因此，在从库上「不会」发生像主库那样两个 session 「同时」执行向表 t2 中插入数据的场景。所以，在备库上执行了 session B 的 insert 语句，生成的结果里面，id 都是连续的。这时，主从库就发生了数据不一致。

要解决这问题，binlog 日志格式要设置为 row，这样在 binlog 里面记录的是主库分配的自增值，到备库执行的时候，主库的自增值是什么，从库的自增值就是什么。

所以，当 innodb_autoinc_lock_mode = 2 时，并且 binlog_format = row，既能提升并发性，又不会出现数据一致性问题。

行级锁

InnoDB 引擎是支持行级锁的，而 MyISAM 引擎并不支持行级锁。

前面也提到，普通的 select 语句是不会对记录加锁的，因为它属于快照读。如果要在查询时对记录加行锁，可以使用下面这两个方式，这种查询会加锁的语句称为锁定读。

//对读取的记录加共享锁
select ... lock in share mode;

//对读取的记录加独占锁
select ... for update;

上面这两条语句必须在一个事务中，因为当事务提交了，锁就会被释放，所以在使用这两条语句的时候，要加上 begin、start transaction 或者 set autocommit = 0。

共享锁（S锁）满足读读共享，读写互斥。独占锁（X锁）满足写写互斥、读写互斥。

Record Lock

Record Lock 称为记录锁，锁住的是一条记录。而且记录锁是有 S 锁和 X 锁之分的：

• 当一个事务对一条记录加了 S 型记录锁后，其他事务也可以继续对该记录加 S 型记录锁（S 型与 S 锁兼容），但是不可以对该记录加 X 型记录锁（S 型与 X 锁不兼容）;
• 当一个事务对一条记录加了 X 型记录锁后，其他事务既不可以对该记录加 S 型记录锁（S 型与 X 锁不兼容），也不可以对该记录加 X 型记录锁（X 型与 X 锁不兼容）。

举个例子，当一个事务执行了下面这条语句：

mysql > begin;
mysql > select * from t_test where id = 1 for update;

就是对 t_test 表中主键 id 为 1 的这条记录加上 X 型的记录锁，这样其他事务就无法对这条记录进行修改了。

当事务执行 commit 后，事务过程中生成的锁都会被释放。

Gap Lock

Gap Lock 称为间隙锁，只存在于可重复读隔离级别，目的是为了解决可重复读隔离级别下幻读的现象。

假设，表中有一个范围 id 为（3，5）间隙锁，那么其他事务就无法插入 id = 4 这条记录了，这样就有效的防止幻读现象的发生。

间隙锁虽然存在 X 型间隙锁和 S 型间隙锁，但是并没有什么区别，间隙锁之间是兼容的，即两个事务可以同时持有包含共同间隙范围的间隙锁，并不存在互斥关系，因为间隙锁的目的是防止插入幻影记录而提出的。

Next-Key Lock

Next-Key Lock 称为临键锁，是 Record Lock + Gap Lock 的组合，锁定一个范围，并且锁定记录本身。

假设，表中有一个范围 id 为（3，5] 的 next-key lock，那么其他事务即不能插入 id = 4 记录，也不能修改 id = 5 这条记录。

所以，next-key lock 即能保护该记录，又能阻止其他事务将新纪录插入到被保护记录前面的间隙中。

next-key lock 是包含间隙锁+记录锁的，如果一个事务获取了 X 型的 next-key lock，那么另外一个事务在获取相同范围的 X 型的 next-key lock 时，是会被阻塞的。

比如，一个事务持有了范围为 (1, 10] 的 X 型的 next-key lock，那么另外一个事务在获取相同范围的 X 型的 next-key lock 时，就会被阻塞。

虽然相同范围的间隙锁是多个事务相互兼容的，但对于记录锁，我们是要考虑 X 型与 S 型关系，X 型的记录锁与 X 型的记录锁是冲突的。

插入意向锁

一个事务在插入一条记录的时候，需要判断插入位置是否已被其他事务加了间隙锁（next-key lock 也包含间隙锁）。

如果有的话，插入操作就会发生阻塞，直到拥有间隙锁的那个事务提交为止（释放间隙锁的时刻），在此期间会生成一个插入意向锁，表明有事务想在某个区间插入新记录，但是现在处于等待状态。

举个例子，假设事务 A 已经对表加了一个范围 id 为（3，5）间隙锁。

当事务 A 还没提交的时候，事务 B 向该表插入一条 id = 4 的新记录，这时会判断到插入的位置已经被事务 A 加了间隙锁，于是事物 B 会生成一个插入意向锁，然后将锁的状态设置为等待状态（PS：MySQL 加锁时，是先生成锁结构，然后设置锁的状态，如果锁状态是等待状态，并不是意味着事务成功获取到了锁，只有当锁状态为正常状态时，才代表事务成功获取到了锁），此时事务 B 就会发生阻塞，直到事务 A 提交了事务。

插入意向锁名字虽然有意向锁，但是它并不是意向锁，它是一种特殊的间隙锁，属于行级别锁。

如果说间隙锁锁住的是一个区间，那么「插入意向锁」锁住的就是一个点。因而从这个角度来说，插入意向锁确实是一种特殊的间隙锁。

插入意向锁与间隙锁的另一个非常重要的差别是：尽管「插入意向锁」也属于间隙锁，但两个事务却不能在同一时间内，一个拥有间隙锁，另一个拥有该间隙区间内的插入意向锁（当然，插入意向锁如果不在间隙锁区间内则是可以的）。

MySQL 是怎么加锁的？

什么 SQL 语句会加行级锁？

InnoDB 引擎是支持行级锁的，而 MyISAM 引擎并不支持行级锁，所以后面的内容都是基于 InnoDB 引擎 的。

所以，在说 MySQL 是怎么加行级锁的时候，其实是在说 InnoDB 引擎是怎么加行级锁的。

普通的 select 语句是不会对记录加锁的（除了串行化隔离级别），因为它属于快照读，是通过 MVCC（多版本并发控制）实现的。

如果要在查询时对记录加行级锁，可以使用下面这两个方式，这两种查询会加锁的语句称为锁定读。

//对读取的记录加共享锁(S型锁)
select ... lock in share mode;

//对读取的记录加独占锁(X型锁)
select ... for update;

上面这两条语句必须在一个事务中，因为当事务提交了，锁就会被释放，所以在使用这两条语句的时候，要加上 begin 或者 start transaction 开启事务的语句。

除了上面这两条锁定读语句会加行级锁之外，update 和 delete 操作都会加行级锁，且锁的类型都是独占锁(X型锁)。

//对操作的记录加独占锁(X型锁)
update table .... where id = 1;

//对操作的记录加独占锁(X型锁)
delete from table where id = 1;

共享锁（S锁）满足读读共享，读写互斥。独占锁（X锁）满足写写互斥、读写互斥。

MySQL 是怎么加行级锁的？

行级锁加锁规则比较复杂，不同的场景，加锁的形式是不同的。

加锁的对象是索引，加锁的基本单位是 next-key lock，它是由记录锁和间隙锁组合而成的，next-key lock 是前开后闭区间，而间隙锁是前开后开区间。

但是，next-key lock 在一些场景下会退化成记录锁或间隙锁。

那到底是什么场景呢？总结一句，在能使用记录锁或者间隙锁就能避免幻读现象的场景下， next-key lock 就会退化成记录锁或间隙锁。

这次会以下面这个表结构来进行实验说明：

CREATE TABLE `user` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL,
  `age` int NOT NULL,
  PRIMARY KEY (`id`),
  KEY `index_age` (`age`) USING BTREE
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

其中，id 是主键索引（唯一索引），age 是普通索引（非唯一索引），name 是普通的列。

表中的有这些行记录：

这次实验环境的 MySQL 版本是 8.0.26，隔离级别是「可重复读」。

不同版本的加锁规则可能是不同的，但是大体上是相同的。

唯一索引等值查询

唯一索引范围查询

非唯一索引等值查询

非唯一索引范围查询

没有加索引的查询

MySQL 行级锁的加锁规则总结：

唯一索引等值查询：

• 当查询的记录是「存在」的，在索引树上定位到这一条记录后，将该记录的索引中的 next-key lock 会退化成「记录锁」。
• 当查询的记录是「不存在」的，在索引树找到第一条大于该查询记录的记录后，将该记录的索引中的 next-key lock 会退化成「间隙锁」。

非唯一索引等值查询：

• 当查询的记录「存在」时，由于不是唯一索引，所以肯定存在索引值相同的记录，于是非唯一索引等值查询的过程是一个扫描的过程，直到扫描到第一个不符合条件的二级索引记录就停止扫描，然后在扫描的过程中，对扫描到的二级索引记录加的是 next-key 锁，而对于第一个不符合条件的二级索引记录，该二级索引的 next-key 锁会退化成间隙锁。同时，在符合查询条件的记录的主键索引上加记录锁。
• 当查询的记录「不存在」时，扫描到第一条不符合条件的二级索引记录，该二级索引的 next-key 锁会退化成间隙锁。因为不存在满足查询条件的记录，所以不会对主键索引加锁。

非唯一索引和主键索引的范围查询的加锁规则不同之处在于：

• 唯一索引在满足一些条件的时候，索引的 next-key lock 退化为间隙锁或者记录锁。
• 非唯一索引范围查询，索引的 next-key lock 不会退化为间隙锁和记录锁。

其实理解 MySQL 为什么要这样加锁，主要要以避免幻读角度去分析，这样就很容易理解这些加锁的规则了。

还有一件很重要的事情，在线上在执行 update、delete、select ... for update 等具有加锁性质的语句，一定要检查语句是否走了索引，如果是全表扫描的话，会对每一个索引加 next-key 锁，相当于把整个表锁住了，这是挺严重的问题。

唯一索引（主键索引）加锁的流程图如下。（注意这个流程图是针对「主键索引」的，如果是二级索引的唯一索引，除了流程图中对二级索引的加锁规则之外，还会对查询到的记录的主键索引项加「记录锁」，流程图没有提示这一个点，所以在这里用文字补充说明下）

非唯一索引加锁的流程图：

update 没加索引会锁全表？

大概就是，在线上执行一条 update 语句修改数据库数据的时候，where 条件没有带上索引，导致业务直接崩了，被老板教训了一波

这次我们就来看看：

为什么会发生这种的事故？

InnoDB 存储引擎的默认事务隔离级别是「可重复读」，但是在这个隔离级别下，在多个事务并发的时候，会出现幻读的问题，所谓的幻读是指在同一事务下，连续执行两次同样的查询语句，第二次的查询语句可能会返回之前不存在的行。

因此 InnoDB 存储引擎自己实现了行锁，通过 next-key 锁（记录锁和间隙锁的组合）来锁住记录本身和记录之间的“间隙”，防止其他事务在这个记录之间插入新的记录，从而避免了幻读现象。

当我们执行 update 语句时，实际上是会对记录加独占锁（X 锁）的，如果其他事务对持有独占锁的记录进行修改时是会被阻塞的。另外，这个锁并不是执行完 update 语句就会释放的，而是会等事务结束时才会释放。

在 InnoDB 事务中，对记录加锁带基本单位是 next-key 锁，但是会因为一些条件会退化成间隙锁，或者记录锁。

加锁的位置准确的说，锁是加在索引上的而非行上。

比如，在 update 语句的 where 条件使用了唯一索引，那么 next-key 锁会退化成记录锁，也就是只会给一行记录加锁。

这里举个例子，这里有一张数据库表，其中 id 为主键索引。

假设有两个事务的执行顺序如下：

可以看到，事务 A 的 update 语句中 where 是等值查询，并且 id 是唯一索引，所以只会对 id = 1 这条记录加锁，因此，事务 B 的更新操作并不会阻塞。

但是，在 update 语句的 where 条件没有使用索引，就会全表扫描，于是就会对所有记录加上 next-key 锁（记录锁 + 间隙锁），相当于把整个表锁住了。

假设有两个事务的执行顺序如下：

****

可以看到，这次事务 B 的 update 语句被阻塞了。

这是因为事务 A的 update 语句中 where 条件没有索引列，触发了全表扫描，在扫描过程中会对索引加锁，所以全表扫描的场景下，所有记录都会被加锁，也就是这条 update 语句产生了 4 个记录锁和 5 个间隙锁，相当于锁住了全表。

因此，当在数据量非常大的数据库表执行 update 语句时，如果没有使用索引，就会给全表的加上 next-key 锁， 那么锁就会持续很长一段时间，直到事务结束，而这期间除了 select ... from语句，其他语句都会被锁住不能执行，业务会因此停滞。

那 update 语句的 where 带上索引就能避免全表记录加锁了吗？

并不是。

关键还得看这条语句在执行过程种，优化器最终选择的是索引扫描，还是全表扫描，如果走了全表扫描，就会对全表的记录加锁了。

TIP

网上很多资料说，update 没加锁索引会加表锁，这是不对的。

Innodb 源码里面在扫描记录的时候，都是针对索引项这个单位去加锁的， update 不带索引就是全表扫扫描，也就是表里的索引项都加锁，相当于锁了整张表，所以大家误以为加了表锁。

如何避免这种事故的发生？

我们可以将 MySQL 里的 sql_safe_updates 参数设置为 1，开启安全更新模式。

大致的意思是，当 sql_safe_updates 设置为 1 时。

update 语句必须满足如下条件之一才能执行成功：

• 使用 where，并且 where 条件中必须有索引列；
• 使用 limit；
• 同时使用 where 和 limit，此时 where 条件中可以没有索引列；

delete 语句必须满足以下条件能执行成功：

• 同时使用 where 和 limit，此时 where 条件中可以没有索引列；

如果 where 条件带上了索引列，但是优化器最终扫描选择的是全表，而不是索引的话，我们可以使用 force index([index_name]) 可以告诉优化器使用哪个索引，以此避免有几率锁全表带来的隐患。

总结

不要小看一条 update 语句，在生产机上使用不当可能会导致业务停滞，甚至崩溃。

当我们要执行 update 语句的时候，确保 where 条件中带上了索引列，并且在测试机确认该语句是否走的是索引扫描，防止因为扫描全表，而对表中的所有记录加上锁。

我们可以打开 MySQL sql_safe_updates 参数，这样可以预防 update 操作时 where 条件没有带上索引列。

如果发现即使在 where 条件中带上了列索引列，优化器走的还是全标扫描，这时我们就要使用 force index([index_name]) 可以告诉优化器使用哪个索引。

MySQL 记录锁+间隙锁可以防止删除操作而导致的幻读吗？

答案是可以的。

什么是幻读？

翻译：当同一个查询在不同的时间产生不同的结果集时，事务中就会出现所谓的幻象问题。例如，如果 SELECT 执行了两次，但第二次返回了第一次没有返回的行，则该行是“幻像”行。

举个例子，假设一个事务在 T1 时刻和 T2 时刻分别执行了下面查询语句，途中没有执行其他任何语句：

SELECT * FROM t_test WHERE id > 100;

只要 T1 和 T2 时刻执行产生的结果集是不相同的，那就发生了幻读的问题，比如：

• T1 时间执行的结果是有 5 条行记录，而 T2 时间执行的结果是有 6 条行记录，那就发生了幻读的问题。
• T1 时间执行的结果是有 5 条行记录，而 T2 时间执行的结果是有 4 条行记录，也是发生了幻读的问题。

MySQL 是怎么解决幻读的？

MySQL InnoDB 引擎的默认隔离级别虽然是「可重复读」，但是它很大程度上避免幻读现象，解决的方案有两种：

• 针对快照读（普通 select 语句），是通过 MVCC 方式解决了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。
• 针对当前读（select ... for update 等语句），是通过 next-key lock（记录锁+间隙锁）方式解决了幻读，因为当执行 select ... for update 语句的时候，会加上 next-key lock，如果有其他事务在 next-key lock 锁范围内插入了一条记录，那么这个插入语句就会被阻塞，无法成功插入，所以就很好了避免幻读问题。

在 MySQL 的可重复读隔离级别下，针对当前读的语句会对索引加记录锁+间隙锁，这样可以避免其他事务执行增、删、改时导致幻读的问题。

有一点要注意的是，在执行 update、delete、select ... for update 等具有加锁性质的语句，一定要检查语句是否走了索引，如果是全表扫描的话，会对每一个索引加 next-key 锁，相当于把整个表锁住了，这是挺严重的问题。

MySQL 死锁了，怎么办？

死锁的发生

本次案例使用存储引擎 Innodb，隔离级别为可重复读（RR）。

接下来，我用实战的方式来带大家看看死锁是怎么发生的。

我建了一张订单表，其中 id 字段为主键索引，order_no 字段普通索引，也就是非唯一索引：

CREATE TABLE `t_order` (
  `id` int NOT NULL AUTO_INCREMENT,
  `order_no` int DEFAULT NULL,
  `create_date` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `index_order` (`order_no`) USING BTREE
) ENGINE=InnoDB ;

然后，先 t_order 表里现在已经有了 6 条记录：

假设这时有两事务，一个事务要插入订单 1007 ，另外一个事务要插入订单 1008，因为需要对订单做幂等性校验，所以两个事务先要查询该订单是否存在，不存在才插入记录，过程如下：

可以看到，两个事务都陷入了等待状态（前提没有打开死锁检测），也就是发生了死锁，因为都在相互等待对方释放锁。

这里在查询记录是否存在的时候，使用了 select ... for update 语句，目的为了防止事务执行的过程中，有其他事务插入了记录，而出现幻读的问题。

如果没有使用 select ... for update 语句，而使用了单纯的 select 语句，如果是两个订单号一样的请求同时进来，就会出现两个重复的订单，有可能出现幻读，如下图：

为什么会产生死锁？

可重复读隔离级别下，是存在幻读的问题。

Innodb 引擎为了解决「可重复读」隔离级别下的幻读问题，就引出了 next-key 锁，它是记录锁和间隙锁的组合。

• Record Lock，记录锁，锁的是记录本身；
• Gap Lock，间隙锁，锁的就是两个值之间的空隙，以防止其他事务在这个空隙间插入新的数据，从而避免幻读现象。

普通的 select 语句是不会对记录加锁的，因为它是通过 MVCC 的机制实现的快照读，如果要在查询时对记录加行锁，可以使用下面这两个方式：

begin;
//对读取的记录加共享锁
select ... lock in share mode;
commit; //锁释放

begin;
//对读取的记录加排他锁
select ... for update;
commit; //锁释放

行锁的释放时机是在事务提交（commit）后，锁就会被释放，并不是一条语句执行完就释放行锁。

比如，下面事务 A 查询语句会锁住 (2, +∞] 范围的记录，然后期间如果有其他事务在这个锁住的范围插入数据就会被阻塞。

需要注意的是，如果 update 语句的 where 条件没有用到索引列，那么就会全表扫描，在一行行扫描的过程中，不仅给行记录加上了行锁，还给行记录两边的空隙也加上了间隙锁，相当于锁住整个表，然后直到事务结束才会释放锁。

所以在线上千万不要执行没有带索引条件的 update 语句，不然会造成业务停滞。

Insert 语句是怎么加行级锁的？

Insert 语句在正常执行时是不会生成锁结构的，它是靠聚簇索引记录自带的 trx_id 隐藏列来作为隐式锁来保护记录的。

1、记录之间加有间隙锁

2、遇到唯一键冲突

如何避免死锁？

死锁的四个必要条件：互斥、占有且等待、不可强占用、循环等待。只要系统发生死锁，这些条件必然成立，但是只要破坏任意一个条件就死锁就不会成立。

在数据库层面，有两种策略通过「打破循环等待条件」来解除死锁状态：

• 设置事务等待锁的超时时间。当一个事务的等待时间超过该值后，就对这个事务进行回滚，于是锁就释放了，另一个事务就可以继续执行了。在 InnoDB 中，参数 innodb_lock_wait_timeout 是用来设置超时时间的，默认值时 50 秒。

  当发生超时后，就出现下面这个提示：

• 开启主动死锁检测。主动死锁检测在发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑，默认就开启。

  当检测到死锁后，就会出现下面这个提示：

上面这个两种策略是「当有死锁发生时」的避免方式。

我们可以回归业务的角度来预防死锁，对订单做幂等性校验的目的是为了保证不会出现重复的订单，那我们可以直接将 order_no 字段设置为唯一索引列，利用它的唯一性来保证订单表不会出现重复的订单，不过有一点不好的地方就是在我们插入一个已经存在的订单记录时就会抛出异常。

加了什么锁，导致死锁的？

日志篇

MySQL中常见的日志类型

错误日志(error log):对MySQL的启动、运行、关闭过程进行了记录。

二进制日志(binary log,binlog):主要记录的是更改数据库数据的SQL语句。

一般查询日志(qeneral query log) :已建立连接的客户端发送给MySQL服务器的所有SQL记录，因为SQL的量比较大，默认是不开启的，也不建议开启。

慢查询日志(slow query log)∶执行时间超过 long_query_time秒钟的查询，解决SQL慢查询问题的时候会用到。

事务日志(redo log 和undo log) : redo log是重做日志，undo log是回滚日志。

中继日志(relay log) : relay log是复制过程中产生的日志，很多方面都跟binary log差不多。不过，relay log 针对的是主从复制中的从库。

DDL日志(metadata log) : DDL语句执行的元数据操作。

更新语句的流程会涉及到 undo log（回滚日志）、redo log（重做日志） 、binlog （归档日志）这三种日志：

• undo log（回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。
• redo log（重做日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复；
• binlog （归档日志）：是 Server 层生成的日志，主要用于数据备份和主从复制；

慢查询日志

MySQL中，如何定位慢查询?

我们当时做压测的时候有的接口非常的慢，接口的响应时间超过了2秒 以上，因为我们当时的系统部署了运维的监控系统Skywalking ，在展示的报表中可以看到是哪一个接口比较慢，并且可以分析这个接口哪部分比较慢， 这里可以看到SQL的具体的执行时间，所以可以定位是哪个sql出了问题

如果，项目中没有这种运维的监控系统，其实在MySQL中也提供了慢日志查询的功能，可以在MySQL的系统配置文件中开启这个慢日志的功能，并且也可以设置SQL执行超过多少时间来记录到一个日志文件中，我记得上一个项目配置的是2秒，只要SQL执行的时间超过了2秒就会记录到日志文件中，我 们就可以在日志文件找到执行比较慢的SQL了。

慢查询日志有什么用?

慢查询日志记录了执行时间超过long_query_time(默认是10s，通常设置为1s)的所有查询语句，在解决SQL慢查询(SQL执行时间过长)问题的时候经常会用到。

SQL语句执行很慢, 如何分析呢？

候选人：如果一条sql执行很慢的话，我们通常会使用mysql自动的执行计划 explain来去查看这条sql的执行情况，比如在这里面可以通过key和key_len检 查是否命中了索引，如果本身已经添加了索引，也可以判断索引是否有失效 的情况，第二个，可以通过type字段查看sql是否有进一步的优化空间，是否 存在全索引扫描或全盘扫描，第三个可以通过extra建议来判断，是否出现了 回表的情况，如果出现了，可以尝试添加索引或修改返回字段来修复

binlog归档日志

binlog(binary log即二进制日志文件)主要记录了对MySQL数据库执行了更改的所有操作(数据库执行的所有DDL和DML语句)，包括表结构变更(CREATE、ALTER、DROP TABLE.….）、表数据修改（INSERT、UPDATE、DELET...），但不包括SELECT、SHOW这类不会对数据库造成更改的操作。

undo log 和 redo log 这两个日志都是 Innodb 存储引擎生成的。

MySQL 在完成一条更新操作后，Server 层还会生成一条 binlog，等之后事务提交的时候，会将该事物执行过程中产生的所有 binlog 统一写 入 binlog 文件。

binlog 文件是记录了所有数据库表结构变更和表数据修改的日志，不会记录查询类的操作，比如 SELECT 和 SHOW 操作。

为什么有了 binlog， 还要有 redo log？

最开始 MySQL 里并没有 InnoDB 引擎，MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力，binlog 日志只能用于归档。而 InnoDB 是另一个公司以插件形式引入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用 redo log 来实现 crash-safe 能力。

如果不小心整个数据库的数据被删除了，能使用 redo log 文件恢复数据吗？

不可以使用 redo log 文件恢复，只能使用 binlog 文件恢复。

因为 redo log 文件是循环写，是会边写边擦除日志的，只记录未被刷入磁盘的数据的物理日志，已经刷入磁盘的数据都会从 redo log 文件里擦除。

binlog 文件保存的是全量的日志，也就是保存了所有数据变更的情况，理论上只要记录在 binlog 上的数据，都可以恢复，所以如果不小心整个数据库的数据被删除了，得用 binlog 文件恢复数据。

binlog的格式有哪几种?

• Statement模式︰每一条会修改数据的sql都会被记录在binlog中，如inserts, updates,deletes。
• Row模式(推荐):每一行的具体变更事件都会被记录在binlog中。
• Mixed模式: Statement模式和Row模式的混合。默认使用Statement模式，少数特殊具体场景自动切换到Row模式。

相比较于Row模式来说，Statement模式下的日志文件更小，磁盘IO压力也较小，性能更好有些。不过，其准确性相比于Row模式要差。

binlog用来做主从复制

binlog最主要的应用场景是主从复制，主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。

主从复制

​ 刚开始系统只部署了一台服务器，读和写数据的所有压力全都由一台数据库承担，压力大，数据库服务器磁盘损坏则数据丢失，单点故障。后来使用 MySQL进行主从复制，一主一从，主库进行增删改操作，从库进行查询操作，从而减轻数据库负担。主库的数据会实时同步到从库中，实现了主库数据的备份，就算主库损毁也有备份，安全性大大提高。随着业务量的扩展、如果是单机部署的MySQL，会导致I/O频率过高。采用主从复制、读写分离可以提高数据库的可用性。

主从复制实际上就是将主库的数据同步到从库数据，通过Mysql主从复制就可以实现从库中的数据和主库中的数据一致。

主从复制的步骤:

1. 主库将数据库中数据的变化写入到binlog
2. 从库连接主库
3. 从库会创建一个I/О 线程向主库请求更新的 binlog
4. 主库会创建一个binlog dump线程来发送 binlog，从库中的I/O线程负责接收
5. 从库的l/O线程将接收的binlog 写入到从库的relay log 中。
6. 从库的SQL线程读取relay log同步数据本地。

MySQL 的主从复制依赖于 binlog ，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上。复制的过程就是将 binlog 中的数据从主库传输到从库上。

这个过程一般是异步的，也就是主库上执行事务操作的线程不会等待复制 binlog 的线程同步完成。

MySQL 集群的主从复制过程梳理成 3 个阶段：

• 写入 Binlog：主库写 binlog 日志，提交事务，并更新本地存储数据。
• 同步 Binlog：把 binlog 复制到所有从库上，每个从库把 binlog 写到暂存日志中。
• 回放 Binlog：回放 binlog，并更新存储引擎中的数据。

具体详细过程如下：

• MySQL 主库在收到客户端提交事务的请求之后，会先写入 binlog，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端“操作成功”的响应。
• 从库会创建一个专门的 I/O 线程，连接主库的 log dump 线程，来接收主库的 binlog 日志，再把 binlog 信息写入 relay log 的中继日志里，再返回给主库“复制成功”的响应。
• 从库会创建一个用于回放 binlog 的线程，去读 relay log 中继日志，然后回放 binlog 更新存储引擎中的数据，最终实现主从的数据一致性。

在完成主从复制之后，你就可以在写数据时只写主库，在读数据时只读从库，这样即使写请求会锁表或者锁记录，也不会影响读请求的执行。

除了主从复制之外，binlog还能帮助我们实现数据恢复。

从库是不是越多越好？

不是的。

因为从库数量增加，从库连接上来的 I/O 线程也比较多，主库也要创建同样多的 log dump 线程来处理复制的请求，对主库资源消耗比较高，同时还受限于主库的网络带宽。

所以在实际使用中，一个主库一般跟 2～3 个从库（1 套数据库，1 主 2 从 1 备主），这就是一主多从的 MySQL 集群结构。

MySQL 主从复制还有哪些模型？

主要有三种：

• 同步复制：MySQL 主库提交事务的线程要等待所有从库的复制成功响应，才返回客户端结果。这种方式在实际项目中，基本上没法用，原因有两个：一是性能很差，因为要复制到所有节点才返回响应；二是可用性也很差，主库和所有从库任何一个数据库出问题，都会影响业务。
• 异步复制（默认模型）：MySQL 主库提交事务的线程并不会等待 binlog 同步到各从库，就返回客户端结果。这种模式一旦主库宕机，数据就会发生丢失。
• 半同步复制：MySQL 5.7 版本之后增加的一种复制方式，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。这种半同步复制的方式，兼顾了异步复制和同步复制的优点，即使出现主库宕机，至少还有一个从库有最新的数据，不存在数据丢失的风险。

binlog的刷盘时机如何选择?

对于InnoDB存储引擎而言，事务在执行过程中，会先把日志写入到binlog cache中，只有在事务提交的时候，才会把binlog cache 中的日志持久化到磁盘上的binlog文件中。写入内存的速度更快，这样做也是为了效率考虑。

因为一个事务的binlog 不能被拆开，无论这个事务多大（比如有很多条语句），也要确保一次性写入。

这是因为有一个线程只能同时有一个事务在执行的设定，所以每当执行一个 begin/start transaction 的时候，就会默认提交上一个事务，这样如果一个事务的 binlog 被拆开的时候，在备库执行就会被当做多个事务分段自行，这样破坏了原子性，是有问题的。

所以系统会给每个线程分配一个块内存作为binlog cache 缓冲 binlog。我们可以通过binlog_cache_size参数控制单个线程binlog cache大小，如果存储内容超过了这个参数，就要暂存到磁盘( Swap )。

那么binlog是什么时候刷到磁盘中的呢?可以通过sync_binlog参数控制biglog的刷盘时机，取值范围是O-N，默认为0 :

1. 0:不去强制要求，由系统自行判断何时写入磁盘;
2. 1:每次提交事务的时候都要将binlog写入磁盘;
3. N:每N个事务，才会将binlog写入磁盘。

什么时候 binlog cache 会写到 binlog 文件？

在事务提交的时候，执行器把 binlog cache 里的完整事务写入到 binlog 文件中，并清空 binlog cache。如下图：

虽然每个线程有自己 binlog cache，但是最终都写到同一个 binlog 文件：

• 图中的 write，指的就是指把日志写入到 binlog 文件，但是并没有把数据持久化到磁盘，因为数据还缓存在文件系统的 page cache 里，write 的写入速度还是比较快的，因为不涉及磁盘 I/O。
• 图中的 fsync，才是将数据持久化到磁盘的操作，这里就会涉及磁盘 I/O，所以频繁的 fsync 会导致磁盘的 I/O 升高。

MySQL提供一个 sync_binlog 参数来控制数据库的 binlog 刷到磁盘上的频率：

• sync_binlog = 0 的时候，表示每次提交事务都只 write，不 fsync，后续交由操作系统决定何时将数据持久化到磁盘；
• sync_binlog = 1 的时候，表示每次提交事务都会 write，然后马上执行 fsync；
• sync_binlog =N(N>1) 的时候，表示每次提交事务都 write，但累积 N 个事务后才 fsync。

在MySQL中系统默认的设置是 sync_binlog = 0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦主机发生异常重启，还没持久化到磁盘的数据就会丢失。

而当 sync_binlog 设置为 1 的时候，是最安全但是性能损耗最大的设置。因为当设置为 1 的时候，即使主机发生异常重启，最多丢失一个事务的 binlog，而已经持久化到磁盘的数据就不会有影响，不过就是对写入性能影响太大。

如果能容少量事务的 binlog 日志丢失的风险，为了提高写入的性能，一般会 sync_binlog 设置为 100~1000 中的某个数值。

什么情况下会重新生成 binlog?

当遇到以下3种情况时，MySQL会重新生成一个新的日志文件，文件序号递增:

• MySQL服务器停止或重启;
• 使用flush logs命令后;
• binlog文件大小超过max_binlog_size变量的阈值后。

redo log重做日志

为什么需要 redo log ？

Buffer Pool 是提高了读写效率没错，但是问题来了，Buffer Pool 是基于内存的，而内存总是不可靠，万一断电重启，还没来得及落盘的脏页数据就会丢失。

为了防止断电导致数据丢失的问题，当有一条记录需要更新的时候，InnoDB 引擎就会先更新内存（同时标记为脏页），然后将本次对这个页的修改以 redo log 的形式记录下来，这个时候更新就算完成了。

InnoDB 引擎会在适当的时候，由后台线程将缓存在 Buffer Pool 的脏页刷新到磁盘里，这就是 WAL （Write-Ahead Logging）技术。

WAL 技术指，MySQL 的写操作并不是立刻写到磁盘上，而是先写日志，然后在合适的时间再写到磁盘上。

redo log 要写到磁盘，数据也要写磁盘，为什么要多此一举？

写入 redo log 的方式使用了追加操作， 所以磁盘操作是顺序写，而写入数据需要先找到写入位置，然后才写到磁盘，所以磁盘操作是随机写。

磁盘的「顺序写 」比「随机写」 高效的多，因此 redo log 写入磁盘的开销更小。

针对「顺序写」为什么比「随机写」更快这个问题，可以比喻为你有一个本子，按照顺序一页一页写肯定比写一个字都要找到对应页写快得多。

可以说这是 WAL 技术的另外一个优点：MySQL 的写操作从磁盘的「随机写」变成了「顺序写」，提升语句的执行性能。这是因为 MySQL 的写操作并不是立刻更新到磁盘上，而是先记录在日志上，然后在合适的时间再更新到磁盘上 。

至此， 针对为什么需要 redo log 这个问题我们有两个答案：

• 实现事务的持久性，让 MySQL 有 crash-safe 的能力，能够保证 MySQL 在任何时间段突然崩溃，重启后之前已提交的记录都不会丢失；
• 将写操作从「随机写」变成了「顺序写」，提升 MySQL 写入磁盘的性能。

redo log如何保证事务的持久性?

什么情况下会出现数据丢失?

1. redo log 写入log buffer但还未写入page cache，此时数据库崩溃，就会出现数据丢
   失（刷盘策略innodb_flush_log_at_trx_commit的值为0时可能会出现这种数据丢失);
2. redo log 已经写入page cache但还未写入磁盘，操作系统奔溃，也可能出现数据丢失
   (刷盘策略innodb_flush_log_at_trx_commit的值为2时可能会出现这种数据丢失）。

页修改之后为什么不直接刷盘呢?

为什么每次修改Buffer Pool中的页之后不直接刷盘呢?这样不就不需要redo log了嘛!
这种方式必然是不行的，性能非常差。

最大的问题就是InnoDB页的大小一般为16KB，而页又是磁盘和内存交互的基本单位。这就导致即使我们只修改了页中的几个字节数据，一次刷盘操作也需要将16KB大小的页整个都刷新到磁盘中。而且，这些修改的页可能并不相邻，也就是说这还是随机 IO。

采用redo log的方式就可以避免这种性能问题，因为redo log 的刷盘性能很好。首先,redo log 的写入属于顺序IO。其次，一行redo log记录只占几十个字节。
另外，Buffer Pool中的页（脏页）在某些情况下（比如redo log 快写满了）也会进行刷盘操作。不过，这里的刷盘操作会合并写入，更高效地顺序写入到磁盘。

---

实际上， 执行一个事务的过程中，产生的 redo log 也不是直接写入磁盘的，因为这样会产生大量的 I/O 操作，而且磁盘的运行速度远慢于内存。

所以，redo log 也有自己的缓存—— redo log buffer，每当产生一条 redo log 时，会先写入到 redo log buffer，后续在持久化到磁盘如下图：

redo log buffer 默认大小 16 MB，可以通过 innodb_log_Buffer_size 参数动态的调整大小，增大它的大小可以让 MySQL 处理「大事务」是不必写入磁盘，进而提升写 IO 性能。

redo log 什么时候刷盘？

缓存在 redo log buffer 里的 redo log 还是在内存中，它什么时候刷新到磁盘？

主要有下面几个时机：

• MySQL 正常关闭时；
• 当 redo log buffer 中记录的写入量大于 redo log buffer 内存空间的一半时，会触发落盘；
• InnoDB 的后台线程每隔 1 秒，将 redo log buffer 持久化到磁盘。
• 每次事务提交时都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘（这个策略可由 innodb_flush_log_at_trx_commit 参数控制，下面会说）。

innodb_flush_log_at_trx_commit 参数控制的是什么？

单独执行一个更新语句的时候，InnoDB 引擎会自己启动一个事务，在执行更新语句的过程中，生成的 redo log 先写入到 redo log buffer 中，然后等事务提交的时候，再将缓存在 redo log buffer 中的 redo log 按组的方式「顺序写」到磁盘。

上面这种 redo log 刷盘时机是在事务提交的时候，这个默认的行为。

除此之外，InnoDB 还提供了另外两种策略，由参数 innodb_flush_log_at_trx_commit 参数控制，可取的值有：0、1、2，默认值为 1，这三个值分别代表的策略如下：

• 当设置该参数为 0 时，表示每次事务提交时 ，还是将 redo log 留在 redo log buffer 中 ，该模式下在事务提交时不会主动触发写入磁盘的操作。
• 当设置该参数为 1 时，表示每次事务提交时，都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘，这样可以保证 MySQL 异常重启之后数据不会丢失。
• 当设置该参数为 2 时，表示每次事务提交时，都只是缓存在 redo log buffer 里的 redo log 写到 redo log 文件，注意写入到「 redo log 文件」并不意味着写入到了磁盘，因为操作系统的文件系统中有个 Page Cache，Page Cache 是专门用来缓存文件数据的，所以写入「 redo log文件」意味着写入到了操作系统的文件缓存。

我画了一个图，方便大家理解：

innodb_flush_log_at_trx_commit 为 0 和 2 的时候，什么时候才将 redo log 写入磁盘？

InnoDB 的后台线程每隔 1 秒：

• 针对参数 0 ：会把缓存在 redo log buffer 中的 redo log ，通过调用 write() 写到操作系统的 Page Cache，然后调用 fsync() 持久化到磁盘。所以参数为 0 的策略，MySQL 进程的崩溃会导致上一秒钟所有事务数据的丢失;
• 针对参数 2 ：调用 fsync，将缓存在操作系统中 Page Cache 里的 redo log 持久化到磁盘。所以参数为 2 的策略，较取值为 0 情况下更安全，因为 MySQL 进程的崩溃并不会丢失数据，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。

加入了后台现线程后，innodb_flush_log_at_trx_commit 的刷盘时机如下图：

这三个参数的应用场景是什么？

这三个参数的数据安全性和写入性能的比较如下：

• 数据安全性：参数 1 > 参数 2 > 参数 0
• 写入性能：参数 0 > 参数 2> 参数 1

所以，数据安全性和写入性能是熊掌不可得兼的，要不追求数据安全性，牺牲性能；要不追求性能，牺牲数据安全性。

• 在一些对数据安全性要求比较高的场景中，显然 innodb_flush_log_at_trx_commit 参数需要设置为 1。
• 在一些可以容忍数据库崩溃时丢失 1s 数据的场景中，我们可以将该值设置为 0，这样可以明显地减少日志同步到磁盘的 I/O 操作。
• 安全性和性能折中的方案就是参数 2，虽然参数 2 没有参数 0 的性能高，但是数据安全性方面比参数 0 强，因为参数 2 只要操作系统不宕机，即使数据库崩溃了，也不会丢失数据，同时性能方便比参数 1 高。

redo log 文件写满了怎么办？

默认情况下， InnoDB 存储引擎有 1 个重做日志文件组( redo log Group），「重做日志文件组」由有 2 个 redo log 文件组成，这两个 redo 日志的文件名叫 ：ib_logfile0 和 ib_logfile1 。

在重做日志组中，每个 redo log File 的大小是固定且一致的，假设每个 redo log File 设置的上限是 1 GB，那么总共就可以记录 2GB 的操作。

重做日志文件组是以循环写的方式工作的，从头开始写，写到末尾就又回到开头，相当于一个环形。

所以 InnoDB 存储引擎会先写 ib_logfile0 文件，当 ib_logfile0 文件被写满的时候，会切换至 ib_logfile1 文件，当 ib_logfile1 文件也被写满时，会切换回 ib_logfile0 文件。

redo log 是为了防止 Buffer Pool 中的脏页丢失而设计的，那么如果随着系统运行，Buffer Pool 的脏页刷新到了磁盘中，那么 redo log 对应的记录也就没用了，这时候我们擦除这些旧记录，以腾出空间记录新的更新操作。

redo log 是循环写的方式，相当于一个环形，InnoDB 用 write pos 表示 redo log 当前记录写到的位置，用 checkpoint 表示当前要擦除的位置，如下图：

图中的：

• write pos 和 checkpoint 的移动都是顺时针方向；
• write pos ～ checkpoint 之间的部分（图中的红色部分），用来记录新的更新操作；
• check point ～ write pos 之间的部分（图中蓝色部分）：待落盘的脏数据页记录；

如果 write pos 追上了 checkpoint，就意味着 redo log 文件满了，这时 MySQL 不能再执行新的更新操作，也就是说 MySQL 会被阻塞（因此所以针对并发量大的系统，适当设置 redo log 的文件大小非常重要），此时会停下来将 Buffer Pool 中的脏页刷新到磁盘中，然后标记 redo log 哪些记录可以被擦除，接着对旧的 redo log 记录进行擦除，等擦除完旧记录腾出了空间，checkpoint 就会往后移动（图中顺时针），然后 MySQL 恢复正常运行，继续执行新的更新操作。

所以，一次 checkpoint 的过程就是脏页刷新到磁盘中变成干净页，然后标记 redo log 哪些记录可以被覆盖的过程。

binlog和redo log区别

1. binlog主要用于数据库还原，属于数据级别的数据恢复，主从复制是binlog最常见的一个应用场景。redolog主要用于保证事务的持久性，属于事务级别的数据恢复。
2. redolog属于InnoDB引擎特有的， binlog属于所有存储引擎共有的，因为 binlog是MySQL的 Server层实现的。
3. redolog属于物理日志，主要记录的是某个页的修改，（比如对XXX 表空间中的YYY数据页ZZZ偏移量的地方做了AAA更新，每当执行一个事务就会产生这样的一条或者多条物理日志）。binlog属于逻辑日志，主要记录的是数据库执行的所有DDL和DML语句。
4. binlog通过追加的方式进行写入，大小没有限制。redo log采用循环写的方式进行写入，大小固定，当写到结尾时，会回到开头循环写日志。

1、适用对象不同：

• binlog 是 MySQL 的 Server 层实现的日志，所有存储引擎都可以使用；
• redo log 是 Innodb 存储引擎实现的日志；

2、文件格式不同：

• binlog 有 3 种格式类型，分别是 STATEMENT（默认格式）、ROW、 MIXED，区别如下：
  • STATEMENT：每一条修改数据的 SQL 都会被记录到 binlog 中（相当于记录了逻辑操作，所以针对这种格式， binlog 可以称为逻辑日志），主从复制中 slave 端再根据 SQL 语句重现。但 STATEMENT 有动态函数的问题，比如你用了 uuid 或者 now 这些函数，你在主库上执行的结果并不是你在从库执行的结果，这种随时在变的函数会导致复制的数据不一致；
  • ROW：记录行数据最终被修改成什么样了（这种格式的日志，就不能称为逻辑日志了），不会出现 STATEMENT 下动态函数的问题。但 ROW 的缺点是每行数据的变化结果都会被记录，比如执行批量 update 语句，更新多少行数据就会产生多少条记录，使 binlog 文件过大，而在 STATEMENT 格式下只会记录一个 update 语句而已；
  • MIXED：包含了 STATEMENT 和 ROW 模式，它会根据不同的情况自动使用 ROW 模式和 STATEMENT 模式；
• redo log 是物理日志，记录的是在某个数据页做了什么修改，比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新；

3、写入方式不同：

• binlog 是追加写，写满一个文件，就创建一个新的文件继续写，不会覆盖以前的日志，保存的是全量的日志。
• redo log 是循环写，日志空间大小是固定，全部写满就从头开始，保存未被刷入磁盘的脏页日志。

4、用途不同：

• binlog 用于备份恢复、主从复制；
• redo log 用于掉电等故障恢复。

redo log 和 undo log 区别

这两种日志是属于 InnoDB 存储引擎的日志，它们的区别在于：

• redo log 记录了此次事务「完成后」的数据状态，记录的是更新之后的值；记录的是数据页的物理变化，服务宕机可用来同步数据，
• undo log 记录了此次事务「开始前」的数据状态，记录的是更新之前的值；记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据
• redo log 保证了事务四大特性中的持久性，undo log保证了事务的原子性和一致性

事务提交之前发生了崩溃，重启后会通过undo log回滚事务，事务提交之后发生了崩溃，重启后会通过redo log恢复事务

所以有了 redo log，再通过 WAL 技术，InnoDB 就可以保证即使数据库发生异常重启，之前已提交的记录都不会丢失，这个能力称为 crash-safe（崩溃恢复）。

被修改 Undo 页面，需要记录对应 redo log 吗？

需要的。

开启事务后，InnoDB 层更新记录前，首先要记录相应的 undo log，如果是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面。

在内存修改该 Undo 页面后，需要记录对应的redo log。

undo log 回滚日志

为什么需要 undo log？

我们在执行执行一条“增删改”语句的时候，虽然没有输入 begin 开启事务和 commit 提交事务，但是 MySQL 会隐式开启事务来执行“增删改”语句的，执行完就自动提交事务的，这样就保证了执行完“增删改”语句后，我们可以及时在数据库表看到“增删改”的结果了。

执行一条语句是否自动提交事务，是由 autocommit 参数决定的，默认是开启。所以，执行一条 update 语句也是会使用事务的。

一个事务在执行过程中，在还没有提交事务之前，如果 MySQL 发生了崩溃，要怎么回滚到事务之前的数据呢？

如果我们每次在事务执行过程中，都记录下回滚时需要的信息到一个日志里，那么在事务执行中途发生了 MySQL 崩溃后，就不用担心无法回滚到事务之前的数据，我们可以通过这个日志回滚到事务之前的数据。

实现这一机制就是 undo log（回滚日志），它保证了事务的 ACID 特性 (opens new window)中的原子性（Atomicity）。

undo log 是一种用于撤销回退的日志。在事务没提交之前，MySQL 会先记录更新前的数据到 undo log 日志文件里面，当事务回滚时，可以利用 undo log 来进行回滚。如下图：

每当 InnoDB 引擎对一条记录进行操作（修改、删除、新增）时，要把回滚时需要的信息都记录到 undo log 里，比如：

• 在插入一条记录时，要把这条记录的主键值记下来，这样之后回滚时只需要把这个主键值对应的记录删掉就好了；
• 在删除一条记录时，要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了；
• 在更新一条记录时，要把被更新的列的旧值记下来，这样之后回滚时再把这些列更新为旧值就好了。

在发生回滚时，就读取 undo log 里的数据，然后做原先相反操作。比如当 delete 一条记录时，undo log 中会把记录中的内容都记下来，然后执行回滚操作的时候，就读取 undo log 里的数据，然后进行 insert 操作。

一条记录的每一次更新操作产生的 undo log 格式都有一个 roll_pointer 指针和一个 trx_id 事务id：

• 通过 trx_id 可以知道该记录是被哪个事务修改的；
• 通过 roll_pointer 指针可以将这些 undo log 串成一个链表，这个链表就被称为版本链；

版本链如下图：

undo log 还有一个作用，通过 ReadView + undo log 实现 MVCC（多版本并发控制）。

对于「读提交」和「可重复读」隔离级别的事务来说，它们的快照读（普通 select 语句）是通过 Read View + undo log 来实现的，它们的区别在于创建 Read View 的时机不同：

• 「读提交」隔离级别是在每个 select 都会生成一个新的 Read View，也意味着，事务期间的多次读取同一条数据，前后两次读的数据可能会出现不一致，因为可能这期间另外一个事务修改了该记录，并提交了事务。
• 「可重复读」隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View，这样就保证了在事务期间读到的数据都是事务启动前的记录。

这两个隔离级别实现是通过「事务的 Read View 里的字段」和「记录中的两个隐藏列（trx_id 和 roll_pointer）」的比对，如果不满足可见性，就会顺着 undo log 版本链里找到满足其可见性的记录，从而控制并发事务访问同一个记录时的行为，这就叫 MVCC（多版本并发控制）。

因此，undo log 两大作用：

• 实现事务回滚，保障事务的原子性。事务处理过程中，如果出现了错误或者用户执 行了 ROLLBACK 语句，MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态。
• 实现 MVCC（多版本并发控制）关键因素之一。MVCC 是通过 ReadView + undo log 实现的。undo log 为每条记录保存多份历史数据，MySQL 在执行快照读（普通 select 语句）的时候，会根据事务的 Read View 里的信息，顺着 undo log 的版本链找到满足其可见性的记录。

undo log如何保证事务的原子性?

每一个事务对数据的修改都会被记录到undo log，当执行事务过程中出现错误或者需要执行回滚操作的话，MySQL可以利用undo log将数据恢复到事务开始之前的状态。

undo log属于逻辑日志，记录的是SQL语句，比如说事务执行一条DELETE语句，那undo log 就会记录一条相对应的INSERT 语句。

除了保证事务的原子性,undo log还有什么用?

InnoDB存储引擎中MVCC的实现用到了undo log。

当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo log读取之前的行版本信息，以此实现非锁定读取。

update 语句的执行过程

三个日志讲完了，至此我们可以先小结下。

当优化器分析出成本最小的执行计划后，执行器就按照执行计划开始进行更新操作。

具体更新一条记录 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:

1. 执行器负责具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id = 1 这一行记录：
   • 如果 id=1 这一行所在的数据页本来就在 buffer pool 中，就直接返回给执行器更新；
   • 如果记录不在 buffer pool，将数据页从磁盘读入到 buffer pool，返回记录给执行器。
2. 执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样：
   • 如果一样的话就不进行后续更新流程；
   • 如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB 真正的执行更新记录的操作；
3. 开启事务， InnoDB 层更新记录前，首先要记录相应的 undo log，因为这是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面，不过在内存修改该 Undo 页面后，需要记录对应的 redo log。
4. InnoDB 层开始更新记录，会先更新内存（同时标记为脏页），然后将记录写到 redo log 里面，这个时候更新就算完成了。为了减少磁盘I/O，不会立即将脏页写入磁盘，后续由后台线程选择一个合适的时机将脏页写入到磁盘。这就是 WAL 技术，MySQL 的写操作并不是立刻写到磁盘上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。
5. 至此，一条记录更新完了。
6. 在一条更新语句执行完成后，然后开始记录该语句对应的 binlog，此时记录的 binlog 会被保存到 binlog cache，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过程中的所有 binlog 刷新到硬盘。
7. 事务提交，剩下的就是「两阶段提交」的事情。

为什么需要两阶段提交

事务提交后，redo log 和 binlog 都要持久化到磁盘，但是这两个是独立的逻辑，可能出现半成功的状态，这样就造成两份日志之间的逻辑不一致。

举个例子，假设 id = 1 这行数据的字段 name 的值原本是 'jay'，然后执行 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 如果在持久化 redo log 和 binlog 两个日志的过程中，出现了半成功状态，那么就有两种情况：

• 如果在将 redo log 刷入到磁盘之后， MySQL 突然宕机了，而 binlog 还没有来得及写入。MySQL 重启后，通过 redo log 能将 Buffer Pool 中 id = 1 这行数据的 name 字段恢复到新值 xiaolin，但是 binlog 里面没有记录这条更新语句，在主从架构中，binlog 会被复制到从库，由于 binlog 丢失了这条更新语句，从库的这一行 name 字段是旧值 jay，与主库的值不一致性；
• 如果在将 binlog 刷入到磁盘之后， MySQL 突然宕机了，而 redo log 还没有来得及写入。由于 redo log 还没写，崩溃恢复以后这个事务无效，所以 id = 1 这行数据的 name 字段还是旧值 jay，而 binlog 里面记录了这条更新语句，在主从架构中，binlog 会被复制到从库，从库执行了这条更新语句，那么这一行 name 字段是新值 xiaolin，与主库的值不一致性；

可以看到，在持久化 redo log 和 binlog 这两份日志的时候，如果出现半成功的状态，就会造成主从环境的数据不一致性。这是因为 redo log 影响主库的数据，binlog 影响从库的数据，所以 redo log 和 binlog 必须保持一致才能保证主从数据一致。

MySQL 为了避免出现两份日志之间的逻辑不一致的问题，使用了「两阶段提交」来解决，两阶段提交其实是分布式事务一致性协议，它可以保证多个逻辑操作要不全部成功，要不全部失败，不会出现半成功的状态。

两阶段提交把单个事务的提交拆分成了 2 个阶段，分别是「准备（Prepare）阶段」和「提交（Commit）阶段」，每个阶段都由协调者（Coordinator）和参与者（Participant）共同完成。注意，不要把提交（Commit）阶段和 commit 语句混淆了，commit 语句执行的时候，会包含提交（Commit）阶段。

举个拳击比赛的例子，两位拳击手（参与者）开始比赛之前，裁判（协调者）会在中间确认两位拳击手的状态，类似于问你准备好了吗？

• 准备阶段：裁判（协调者）会依次询问两位拳击手（参与者）是否准备好了，然后拳击手听到后做出应答，如果觉得自己准备好了，就会跟裁判说准备好了；如果没有自己还没有准备好（比如拳套还没有带好），就会跟裁判说还没准备好。
• 提交阶段：如果两位拳击手（参与者）都回答准备好了，裁判（协调者）宣布比赛正式开始，两位拳击手就可以直接开打；如果任何一位拳击手（参与者）回答没有准备好，裁判（协调者）会宣布比赛暂停，对应事务中的回滚操作。

两阶段提交的过程是怎样的？

在 MySQL 的 InnoDB 存储引擎中，开启 binlog 的情况下，MySQL 会同时维护 binlog 日志与 InnoDB 的 redo log，为了保证这两个日志的一致性，MySQL 使用了内部 XA 事务，内部 XA 事务由 binlog 作为协调者，存储引擎是参与者。

当客户端执行 commit 语句或者在自动提交的情况下，MySQL 内部开启一个 XA 事务，分两阶段来完成 XA 事务的提交，如下图：

从图中可看出，事务的提交过程有两个阶段，就是将 redo log 的写入拆成了两个步骤：prepare 和 commit，中间再穿插写入binlog，具体如下：

• prepare 阶段：将 XID（内部 XA 事务的 ID） 写入到 redo log，同时将 redo log 对应的事务状态设置为 prepare，然后将 redo log 持久化到磁盘（innodb_flush_log_at_trx_commit = 1 的作用）；
• commit 阶段：把 XID 写入到 binlog，然后将 binlog 持久化到磁盘（sync_binlog = 1 的作用），接着调用引擎的提交事务接口，将 redo log 状态设置为 commit，此时该状态并不需要持久化到磁盘，只需要 write 到文件系统的 page cache 中就够了，因为只要 binlog 写磁盘成功，就算 redo log 的状态还是 prepare 也没有关系，一样会被认为事务已经执行成功；

异常重启会出现什么现象？

我们来看看在两阶段提交的不同时刻，MySQL 异常重启会出现什么现象？下图中有时刻 A 和时刻 B 都有可能发生崩溃：

不管是时刻 A（redo log 已经写入磁盘， binlog 还没写入磁盘），还是时刻 B （redo log 和 binlog 都已经写入磁盘，还没写入 commit 标识）崩溃，此时的 redo log 都处于 prepare 状态。

在 MySQL 重启后会按顺序扫描 redo log 文件，碰到处于 prepare 状态的 redo log，就拿着 redo log 中的 XID 去 binlog 查看是否存在此 XID：

• 如果 binlog 中没有当前内部 XA 事务的 XID，说明 redolog 完成刷盘，但是 binlog 还没有刷盘，则回滚事务。对应时刻 A 崩溃恢复的情况。
• 如果 binlog 中有当前内部 XA 事务的 XID，说明 redolog 和 binlog 都已经完成了刷盘，则提交事务。对应时刻 B 崩溃恢复的情况。

可以看到，对于处于 prepare 阶段的 redo log，即可以提交事务，也可以回滚事务，这取决于是否能在 binlog 中查找到与 redo log 相同的 XID，如果有就提交事务，如果没有就回滚事务。这样就可以保证 redo log 和 binlog 这两份日志的一致性了。

所以说，两阶段提交是以 binlog 写成功为事务提交成功的标识，因为 binlog 写成功了，就意味着能在 binlog 中查找到与 redo log 相同的 XID。

处于 prepare 阶段的 redo log 加上完整 binlog，重启就提交事务，MySQL 为什么要这么设计?

binlog 已经写入了，之后就会被从库（或者用这个 binlog 恢复出来的库）使用。

所以，在主库上也要提交这个事务。采用这个策略，主库和备库的数据就保证了一致性。

事务没提交的时候，redo log 会被持久化到磁盘吗？

会的。

事务执行中间过程的 redo log 也是直接写在 redo log buffer 中的，这些缓存在 redo log buffer 里的 redo log 也会被「后台线程」每隔一秒一起持久化到磁盘。

也就是说，事务没提交的时候，redo log 也是可能被持久化到磁盘的。

有的同学可能会问，如果 mysql 崩溃了，还没提交事务的 redo log 已经被持久化磁盘了，mysql 重启后，数据不就不一致了？

放心，这种情况 mysql 重启会进行回滚操作，因为事务没提交的时候，binlog 是还没持久化到磁盘的。

所以， redo log 可以在事务没提交之前持久化到磁盘，但是 binlog 必须在事务提交之后，才可以持久化到磁盘。

两阶段提交有什么问题？

两阶段提交虽然保证了两个日志文件的数据一致性，但是性能很差，主要有两个方面的影响：

• 磁盘 I/O 次数高：对于“双1”配置，每个事务提交都会进行两次 fsync（刷盘），一次是 redo log 刷盘，另一次是 binlog 刷盘。
• 锁竞争激烈：两阶段提交虽然能够保证「单事务」两个日志的内容一致，但在「多事务」的情况下，却不能保证两者的提交顺序一致，因此，在两阶段提交的流程基础上，还需要加一个锁来保证提交的原子性，从而保证多事务的情况下，两个日志的提交顺序一致。

为什么两阶段提交的磁盘 I/O 次数会很高？

binlog 和 redo log 在内存中都对应的缓存空间，binlog 会缓存在 binlog cache，redo log 会缓存在 redo log buffer，它们持久化到磁盘的时机分别由下面这两个参数控制。一般我们为了避免日志丢失的风险，会将这两个参数设置为 1：

• 当 sync_binlog = 1 的时候，表示每次提交事务都会将 binlog cache 里的 binlog 直接持久到磁盘；
• 当 innodb_flush_log_at_trx_commit = 1 时，表示每次事务提交时，都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘；

可以看到，如果 sync_binlog 和 当 innodb_flush_log_at_trx_commit 都设置为 1，那么在每个事务提交过程中， 都会至少调用 2 次刷盘操作，一次是 redo log 刷盘，一次是 binlog 落盘，所以这会成为性能瓶颈。

为什么锁竞争激烈？

在早期的 MySQL 版本中，通过使用 prepare_commit_mutex 锁来保证事务提交的顺序，在一个事务获取到锁时才能进入 prepare 阶段，一直到 commit 阶段结束才能释放锁，下个事务才可以继续进行 prepare 操作。

通过加锁虽然完美地解决了顺序一致性的问题，但在并发量较大的时候，就会导致对锁的争用，性能不佳。

MySQL 磁盘 I/O 很高，有什么优化的方法？

现在我们知道事务在提交的时候，需要将 binlog 和 redo log 持久化到磁盘，那么如果出现 MySQL 磁盘 I/O 很高的现象，我们可以通过控制以下参数，来 “延迟” binlog 和 redo log 刷盘的时机，从而降低磁盘 I/O 的频率：

• 设置组提交的两个参数： binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 参数，延迟 binlog 刷盘的时机，从而减少 binlog 的刷盘次数。这个方法是基于“额外的故意等待”来实现的，因此可能会增加语句的响应时间，但即使 MySQL 进程中途挂了，也没有丢失数据的风险，因为 binlog 早被写入到 page cache 了，只要系统没有宕机，缓存在 page cache 里的 binlog 就会被持久化到磁盘。
• 将 sync_binlog 设置为大于 1 的值（比较常见是 100~1000），表示每次提交事务都 write，但累积 N 个事务后才 fsync，相当于延迟了 binlog 刷盘的时机。但是这样做的风险是，主机掉电时会丢 N 个事务的 binlog 日志。
• 将 innodb_flush_log_at_trx_commit 设置为 2。表示每次事务提交时，都只是缓存在 redo log buffer 里的 redo log 写到 redo log 文件，注意写入到「 redo log 文件」并不意味着写入到了磁盘，因为操作系统的文件系统中有个 Page Cache，专门用来缓存文件数据的，所以写入「 redo log文件」意味着写入到了操作系统的文件缓存，然后交由操作系统控制持久化到磁盘的时机。但是这样做的风险是，主机掉电的时候会丢数据。

总结

具体更新一条记录 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:

1. 执行器负责具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id = 1 这一行记录：
   • 如果 id=1 这一行所在的数据页本来就在 buffer pool 中，就直接返回给执行器更新；
   • 如果记录不在 buffer pool，将数据页从磁盘读入到 buffer pool，返回记录给执行器。
2. 执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样：
   • 如果一样的话就不进行后续更新流程；
   • 如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB 真正的执行更新记录的操作；
3. 开启事务， InnoDB 层更新记录前，首先要记录相应的 undo log，因为这是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面，不过在内存修改该 Undo 页面后，需要记录对应的 redo log。
4. InnoDB 层开始更新记录，会先更新内存（同时标记为脏页），然后将记录写到 redo log 里面，这个时候更新就算完成了。为了减少磁盘I/O，不会立即将脏页写入磁盘，后续由后台线程选择一个合适的时机将脏页写入到磁盘。这就是 WAL 技术，MySQL 的写操作并不是立刻写到磁盘上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。
5. 至此，一条记录更新完了。
6. 在一条更新语句执行完成后，然后开始记录该语句对应的 binlog，此时记录的 binlog 会被保存到 binlog cache，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过程中的所有 binlog 刷新到硬盘。
7. 事务提交（为了方便说明，这里不说组提交的过程，只说两阶段提交）：
   • prepare 阶段：将 redo log 对应的事务状态设置为 prepare，然后将 redo log 刷新到硬盘；
   • commit 阶段：将 binlog 刷新到磁盘，接着调用引擎的提交事务接口，将 redo log 状态设置为 commit（将事务设置为 commit 状态后，刷入到磁盘 redo log 文件）；
8. 至此，一条更新语句执行完成。

内存篇

为什么要有 Buffer Pool？

虽然说 MySQL 的数据是存储在磁盘里的，但是也不能每次都从磁盘里面读取数据，这样性能是极差的。

要想提升查询性能，加个缓存就行了嘛。所以，当数据从磁盘中取出后，缓存内存中，下次查询同样的数据的时候，直接从内存中读取。

为此，Innodb 存储引擎设计了一个缓冲池（*Buffer Pool*），来提高数据库的读写性能。

有了缓冲池后：

• 当读取数据时，如果数据存在于 Buffer Pool 中，客户端就会直接读取 Buffer Pool 中的数据，否则再去磁盘中读取。
• 当修改数据时，首先是修改 Buffer Pool 中数据所在的页，然后将其页设置为脏页，最后由后台线程将脏页写入到磁盘。

Buffer Pool 有多大？

Buffer Pool 是在 MySQL 启动的时候，向操作系统申请的一片连续的内存空间，默认配置下 Buffer Pool 只有 128MB 。

可以通过调整 innodb_buffer_pool_size 参数来设置 Buffer Pool 的大小，一般建议设置成可用物理内存的 60%~80%。

Buffer Pool 缓存什么？

InnoDB 会把存储的数据划分为若干个「页」，以页作为磁盘和内存交互的基本单位，一个页的默认大小为 16KB。因此，Buffer Pool 同样需要按「页」来划分。

在 MySQL 启动的时候，InnoDB 会为 Buffer Pool 申请一片连续的内存空间，然后按照默认的16KB的大小划分出一个个的页， Buffer Pool 中的页就叫做缓存页。此时这些缓存页都是空闲的，之后随着程序的运行，才会有磁盘上的页被缓存到 Buffer Pool 中。

所以，MySQL 刚启动的时候，你会观察到使用的虚拟内存空间很大，而使用到的物理内存空间却很小，这是因为只有这些虚拟内存被访问后，操作系统才会触发缺页中断，接着将虚拟地址和物理地址建立映射关系。

Buffer Pool 除了缓存「索引页」和「数据页」，还包括了 undo 页，插入缓存、自适应哈希索引、锁信息等等。

Undo 页是记录什么？

开启事务后，InnoDB 层更新记录前，首先要记录相应的 undo log，如果是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的Undo 页面。

查询一条记录，就只需要缓冲一条记录吗？

不是的。

当我们查询一条记录时，InnoDB 是会把整个页的数据加载到 Buffer Pool 中，将页加载到 Buffer Pool 后，再通过页里的「页目录」去定位到某条具体的记录。

为了更好的管理这些在 Buffer Pool 中的缓存页，InnoDB 为每一个缓存页都创建了一个控制块，控制块信息包括「缓存页的表空间、页号、缓存页地址、链表节点」等等。

控制块也是占有内存空间的，它是放在 Buffer Pool 的最前面，接着才是缓存页，如下图：

上图中控制块和缓存页之间灰色部分称为碎片空间。

为什么会有碎片空间呢？

每一个控制块都对应一个缓存页，那在分配足够多的控制块和缓存页后，可能剩余的那点儿空间不够一对控制块和缓存页的大小，这个用不到的那点儿内存空间就被称为碎片。

如果你把 Buffer Pool 的大小设置的刚刚好的话，也可能不会产生碎片。

查询一条记录，就只需要缓冲一条记录吗？

不是的。

当我们查询一条记录时，InnoDB 是会把整个页的数据加载到 Buffer Pool 中，因为，通过索引只能定位到磁盘中的页，而不能定位到页中的一条记录。将页加载到 Buffer Pool 后，再通过页里的页目录去定位到某条具体的记录。

如何管理 Buffer Pool？

如何管理空闲页？

Buffer Pool 是一片连续的内存空间，当 MySQL 运行一段时间后，这片连续的内存空间中的缓存页既有空闲的，也有被使用的。那当我们从磁盘读取数据的时候，总不能通过遍历这一片连续的内存空间来找到空闲的缓存页吧，这样效率太低了。

所以，为了能够快速找到空闲的缓存页，可以使用链表结构，将空闲缓存页的「控制块」作为链表的节点，这个链表称为 Free 链表（空闲链表）。

Free 链表上除了有控制块，还有一个头节点，该头节点包含链表的头节点地址，尾节点地址，以及当前链表中节点的数量等信息。

Free 链表节点是一个一个的控制块，而每个控制块包含着对应缓存页的地址，所以相当于 Free 链表节点都对应一个空闲的缓存页。

有了 Free 链表后，每当需要从磁盘中加载一个页到 Buffer Pool 中时，就从 Free链表中取一个空闲的缓存页，并且把该缓存页对应的控制块的信息填上，然后把该缓存页对应的控制块从 Free 链表中移除。

管理脏页？

设计 Buffer Pool 除了能提高读性能，还能提高写性能，也就是更新数据的时候，不需要每次都要写入磁盘，而是将 Buffer Pool 对应的缓存页标记为脏页，然后再由后台线程将脏页写入到磁盘。

那为了能快速知道哪些缓存页是脏的，于是就设计出 Flush 链表，它跟 Free 链表类似的，链表的节点也是控制块，区别在于 Flush 链表的元素都是脏页。

有了 Flush 链表后，后台线程就可以遍历 Flush 链表，将脏页写入到磁盘。

如何提高缓存命中率？

Buffer Pool 的大小是有限的，对于一些频繁访问的数据我们希望可以一直留在 Buffer Pool 中，而一些很少访问的数据希望可以在某些时机可以淘汰掉，从而保证 Buffer Pool 不会因为满了而导致无法再缓存新的数据，同时还能保证常用数据留在 Buffer Pool 中。

要实现这个，最容易想到的就是 LRU（Least recently used）算法。

该算法的思路是，链表头部的节点是最近使用的，而链表末尾的节点是最久没被使用的。那么，当空间不够了，就淘汰最久没被使用的节点，从而腾出空间。

简单的 LRU 算法的实现思路是这样的：

• 当访问的页在 Buffer Pool 里，就直接把该页对应的 LRU 链表节点移动到链表的头部。
• 当访问的页不在 Buffer Pool 里，除了要把页放入到 LRU 链表的头部，还要淘汰 LRU 链表末尾的节点。

比如下图，假设 LRU 链表长度为 5，LRU 链表从左到右有 1，2，3，4，5 的页。

如果访问了 3 号的页，因为 3 号页在 Buffer Pool 里，所以把 3 号页移动到头部即可。

而如果接下来，访问了 8 号页，因为 8 号页不在 Buffer Pool 里，所以需要先淘汰末尾的 5 号页，然后再将 8 号页加入到头部。

Buffer Pool 里有三种页和链表来管理数据。

图中：

• Free Page（空闲页），表示此页未被使用，位于 Free 链表；
• Clean Page（干净页），表示此页已被使用，但是页面未发生修改，位于LRU 链表。
• Dirty Page（脏页），表示此页「已被使用」且「已经被修改」，其数据和磁盘上的数据已经不一致。当脏页上的数据写入磁盘后，内存数据和磁盘数据一致，那么该页就变成了干净页。脏页同时存在于 LRU 链表和 Flush 链表。

简单的 LRU 算法并没有被 MySQL 使用，因为简单的 LRU 算法无法避免下面这两个问题：

• 预读失效；
• Buffer Pool 污染；

什么是预读失效？

程序是有空间局部性的，靠近当前被访问数据的数据，在未来很大概率会被访问到。

所以，MySQL 在加载数据页时，会提前把它相邻的数据页一并加载进来，目的是为了减少磁盘 IO。

但是可能这些被提前加载进来的数据页，并没有被访问，相当于这个预读是白做了，这个就是预读失效。

如果使用简单的 LRU 算法，就会把预读页放到 LRU 链表头部，而当 Buffer Pool空间不够的时候，还需要把末尾的页淘汰掉。

如果这些预读页如果一直不会被访问到，就会出现一个很奇怪的问题，不会被访问的预读页却占用了 LRU 链表前排的位置，而末尾淘汰的页，可能是频繁访问的页，这样就大大降低了缓存命中率。

怎么解决预读失效而导致缓存命中率降低的问题？

我们不能因为害怕预读失效，而将预读机制去掉，大部分情况下，局部性原理还是成立的。

要避免预读失效带来影响，最好就是让预读的页停留在 Buffer Pool 里的时间要尽可能的短，让真正被访问的页才移动到 LRU 链表的头部，从而保证真正被读取的热数据留在 Buffer Pool 里的时间尽可能长。

那到底怎么才能避免呢？

MySQL 是这样做的，它改进了 LRU 算法，将 LRU 划分了 2 个区域：old 区域 和 young 区域。

young 区域在 LRU 链表的前半部分，old 区域则是在后半部分，如下图：

old 区域占整个 LRU 链表长度的比例可以通过 innodb_old_blocks_pct 参数来设置，默认是 37，代表整个 LRU 链表中 young 区域与 old 区域比例是 63:37。

划分这两个区域后，预读的页就只需要加入到 old 区域的头部，当页被真正访问的时候，才将页插入 young 区域的头部。如果预读的页一直没有被访问，就会从 old 区域移除，这样就不会影响 young 区域中的热点数据。

接下来，给大家举个例子。

假设有一个长度为 10 的 LRU 链表，其中 young 区域占比 70 %，old 区域占比 30 %。

现在有个编号为 20 的页被预读了，这个页只会被插入到 old 区域头部，而 old 区域末尾的页（10号）会被淘汰掉。

如果 20 号页一直不会被访问，它也没有占用到 young 区域的位置，而且还会比 young 区域的数据更早被淘汰出去。

如果 20 号页被预读后，立刻被访问了，那么就会将它插入到 young 区域的头部，young 区域末尾的页（7号），会被挤到 old 区域，作为 old 区域的头部，这个过程并不会有页被淘汰。

虽然通过划分 old 区域 和 young 区域避免了预读失效带来的影响，但是还有个问题无法解决，那就是 Buffer Pool 污染的问题。

什么是 Buffer Pool 污染？

当某一个 SQL 语句扫描了大量的数据时，在 Buffer Pool 空间比较有限的情况下，可能会将 Buffer Pool 里的所有页都替换出去，导致大量热数据被淘汰了，等这些热数据又被再次访问的时候，由于缓存未命中，就会产生大量的磁盘 IO，MySQL 性能就会急剧下降，这个过程被称为 Buffer Pool 污染。

注意， Buffer Pool 污染并不只是查询语句查询出了大量的数据才出现的问题，即使查询出来的结果集很小，也会造成 Buffer Pool 污染。

比如，在一个数据量非常大的表，执行了这条语句：

select * from t_user where name like "%xiaolin%";

可能这个查询出来的结果就几条记录，但是由于这条语句会发生索引失效，所以这个查询过程是全表扫描的，接着会发生如下的过程：

• 从磁盘读到的页加入到 LRU 链表的 old 区域头部；
• 当从页里读取行记录时，也就是页被访问的时候，就要将该页放到 young 区域头部；
• 接下来拿行记录的 name 字段和字符串 xiaolin 进行模糊匹配，如果符合条件，就加入到结果集里；
• 如此往复，直到扫描完表中的所有记录。

经过这一番折腾，原本 young 区域的热点数据都会被替换掉。

举个例子，假设需要批量扫描：21，22，23，24，25 这五个页，这些页都会被逐一访问（读取页里的记录）。

在批量访问这些数据的时候，会被逐一插入到 young 区域头部。

可以看到，原本在 young 区域的热点数据 6 和 7 号页都被淘汰了，这就是 Buffer Pool 污染的问题。

怎么解决出现 Buffer Pool 污染而导致缓存命中率下降的问题？

像前面这种全表扫描的查询，很多缓冲页其实只会被访问一次，但是它却只因为被访问了一次而进入到 young 区域，从而导致热点数据被替换了。

LRU 链表中 young 区域就是热点数据，只要我们提高进入到 young 区域的门槛，就能有效地保证 young 区域里的热点数据不会被替换掉。

MySQL 是这样做的，进入到 young 区域条件增加了一个停留在 old 区域的时间判断。

具体是这样做的，在对某个处在 old 区域的缓存页进行第一次访问时，就在它对应的控制块中记录下来这个访问时间：

• 如果后续的访问时间与第一次访问的时间在某个时间间隔内，那么该缓存页就不会被从 old 区域移动到 young 区域的头部；
• 如果后续的访问时间与第一次访问的时间不在某个时间间隔内，那么该缓存页移动到 young 区域的头部；

这个间隔时间是由 innodb_old_blocks_time 控制的，默认是 1000 ms。

也就说，只有同时满足「被访问」与「在 old 区域停留时间超过 1 秒」两个条件，才会被插入到 young 区域头部，这样就解决了 Buffer Pool 污染的问题 。

另外，MySQL 针对 young 区域其实做了一个优化，为了防止 young 区域节点频繁移动到头部。young 区域前面 1/4 被访问不会移动到链表头部，只有后面的 3/4被访问了才会。

脏页什么时候会被刷入磁盘？

引入了 Buffer Pool 后，当修改数据时，首先是修改 Buffer Pool 中数据所在的页，然后将其页设置为脏页，但是磁盘中还是原数据。

因此，脏页需要被刷入磁盘，保证缓存和磁盘数据一致，但是若每次修改数据都刷入磁盘，则性能会很差，因此一般都会在一定时机进行批量刷盘。

可能大家担心，如果在脏页还没有来得及刷入到磁盘时，MySQL 宕机了，不就丢失数据了吗？

这个不用担心，InnoDB 的更新操作采用的是 Write Ahead Log 策略，即先写日志，再写入磁盘，通过 redo log 日志让 MySQL 拥有了崩溃恢复能力。

下面几种情况会触发脏页的刷新：

• 当 redo log 日志满了的情况下，会主动触发脏页刷新到磁盘；
• Buffer Pool 空间不足时，需要将一部分数据页淘汰掉，如果淘汰的是脏页，需要先将脏页同步到磁盘；
• MySQL 认为空闲时，后台线程会定期将适量的脏页刷入到磁盘；
• MySQL 正常关闭之前，会把所有的脏页刷入到磁盘；

在我们开启了慢 SQL 监控后，如果你发现「偶尔」会出现一些用时稍长的 SQL，这可能是因为脏页在刷新到磁盘时可能会给数据库带来性能开销，导致数据库操作抖动。

如果间断出现这种现象，就需要调大 Buffer Pool 空间或 redo log 日志的大小。

总结

Innodb 存储引擎设计了一个缓冲池（*Buffer Pool*），来提高数据库的读写性能。

Buffer Pool 以页为单位缓冲数据，可以通过 innodb_buffer_pool_size 参数调整缓冲池的大小，默认是 128 M。

Innodb 通过三种链表来管理缓页：

• Free List （空闲页链表），管理空闲页；
• Flush List （脏页链表），管理脏页；
• LRU List，管理脏页+干净页，将最近且经常查询的数据缓存在其中，而不常查询的数据就淘汰出去。；

InnoDB 对 LRU 做了一些优化，我们熟悉的 LRU 算法通常是将最近查询的数据放到 LRU 链表的头部，而 InnoDB 做 2 点优化：

• 将 LRU 链表 分为young 和 old 两个区域，加入缓冲池的页，优先插入 old 区域；页被访问时，才进入 young 区域，目的是为了解决预读失效的问题。
• 当「页被访问」且「 old 区域停留时间超过 innodb_old_blocks_time 阈值（默认为1秒）」时，才会将页插入到 young 区域，否则还是插入到 old 区域，目的是为了解决批量数据访问，大量热数据淘汰的问题。

可以通过调整 innodb_old_blocks_pct 参数，设置 young 区域和 old 区域比例。

在开启了慢 SQL 监控后，如果你发现「偶尔」会出现一些用时稍长的 SQL，这可因为脏页在刷新到磁盘时导致数据库性能抖动。如果在很短的时间出现这种现象，就需要调大 Buffer Pool 空间或 redo log 日志的大小。

说⼀说事物隔离级别

事务的四大特性有哪些

ACID事务 四⼤特性

说⼀说你了解的MVCC机制

MySQL的执行引擎有哪些？

MySQL日志文件有哪几种？

MySQL有哪些锁？作用是什么？

情景篇

MYSQL超大分页怎么处理 ?

超大分页一般都是在数据量比较大时，我们使用了limit分页查询，并且需要对数据进行排序，这个时候效率就很低。

我们可以采用覆盖索引和子查询来解决。先分页查询数据的id字段，确定了id之后，再用子查询来过滤，只查询这个 id列表中的数据就可以了 因为查询id的时候，走的覆盖索引，所以效率可以提升很多。

假设我们需要从 users 表中分页查询数据，每页100条记录，从第10000条开始：
-- Step 1: 创建覆盖索引
-- users 表的 id 列上创建一个索引 idx_users_id。
-- 索引的主要目的是加速基于 id 列的查询操作。

CREATE INDEX idx_users_id ON users(id);

-- Step 2: 分页查询id字段
-- 获取从第10001到第10100行的 id。
-- 由于只查询 id 字段，并且在 id 上有索引，所以这个查询会利用覆盖索引，查询速度较快。
SELECT id FROM users 
ORDER BY id 
LIMIT 10000, 100;

-- Step 3: 用子查询过滤，查询这个id列表中的数据
-- 基于步骤2中获取的 id 列表，再次查询 users 表以获取完整的记录。

SELECT * FROM users 
WHERE id IN (
    SELECT id FROM users 
    ORDER BY id 
    LIMIT 10000, 100
)
ORDER BY id;

sql优化的经验

https://www.yuque.com/snailclimb/mf2z3k/abc2sv

当然如果直说sql优化的话，我们会从这几方面考虑：

• 建表的时候

1. 选择合适的数据类型：尽量使用占用存储空间较小的数据类型。
2. 避免使用NULL：对于经常查询的列，避免使用NULL，这样可以提高索引效率。

• 使用索引

1. 索引选择：根据查询频率和查询类型，选择合适的索引类型（如B-tree索引、哈希索引）。
2. 联合索引：对于多个条件的查询，建立联合索引可以提高查询效率。

• sql语句的编写

1. 避免SELECT *：尽量指定具体的列名，减少不必要的数据传输。会消耗更多的CPU。
2. 使用预编译语句：预编译语句可以提高查询效率并避免SQL注入。

• 主从复制

1. 目的：提高读性能，提供冗余备份。
2. 配置：配置主服务器（Master）和从服务器（Slave），主服务器处理写操作，从服务器处理读操作。

• 读写分离

1. 目的：将读操作和写操作分离，分散负载。
2. 实现：应用程序层面根据操作类型（读/写）选择不同的数据库连接。

• 如果量比较大的话，可以考虑分库分表

1. 目的：解决单表数据量过大带来的性能问题。
2. 方法：根据某个字段（如用户ID）进行分库分表。

Redis

什么是 Redis？

Redis 是一种基于内存的数据库，对数据的读写操作都是在内存中完成，因此读写速度非常快，常用于缓存，消息队列、分布式锁等场景。

• 字符串(string)：普通字符串，Redis中最简单的数据类型
• 哈希(hash)：也叫散列，类似于Java中的HashMap结构
• 列表(list)：按照插入顺序排序，可以有重复元素，类似于Java中的LinkedList
• 集合(set)：无序集合，没有重复元素，类似于Java中的HashSet
• 有序集合(sorted set / zset)：集合中每个元素关联一个分数（score），根据分数升序排序，没有重复元素

为什么用 Redis 作为 MySQL 的缓存？

主要是因为 Redis 具备「高性能」和「高并发」两种特性。

1、Redis 具备高性能

假如用户第一次访问 MySQL 中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据缓存在 Redis 中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了，操作 Redis 缓存就是直接操作内存，所以速度相当快。

2、 Redis 具备高并发

单台设备的 Redis 的 QPS（Query Per Second，每秒钟处理完请求的次数） 是 MySQL 的 10 倍。

所以，直接访问 Redis 能够承受的请求是远远大于直接访问 MySQL 的，可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

Redis 数据结构

Redis 数据类型以及使用场景分别是什么？

常见的有五种数据类型：String（字符串），Hash（哈希），List（列表），Set（集合）、Zset（有序集合）。

通用命令

• KEYS pattern 查找所有符合给定模式( pattern)的 key
• EXISTS key 检查给定 key 是否存在
• TYPE key 返回 key 所储存的值的类型
• DEL key 该命令用于在 key 存在是删除 key

String

String 是最基本的 key-value 结构，key 是唯一标识，value 是具体的值。

常用指令

Redis 字符串类型常用命令：

• SET key value 设置指定key的值
• GET key 获取指定key的值
• SETEX key seconds value 设置指定key的值，并将 key 的过期时间设为 seconds 秒
• SETNX key value 只有在 key 不存在时设置 key 的值

普通字符串的基本操作：

# 设置 key-value 类型的值
> SET name lin
OK
# 根据 key 获得对应的 value
> GET name
"lin"
# 判断某个 key 是否存在
> EXISTS name
(integer) 1
# 返回 key 所储存的字符串值的长度
> STRLEN name
(integer) 3
# 删除某个 key 对应的值
> DEL name
(integer) 1

批量设置 :

# 批量设置 key-value 类型的值
> MSET key1 value1 key2 value2 
OK
# 批量获取多个 key 对应的 value
> MGET key1 key2 
1) "value1"
2) "value2"

计数器（字符串的内容为整数的时候可以使用）：

# 设置 key-value 类型的值
> SET number 0
OK
# 将 key 中储存的数字值增一
> INCR number
(integer) 1
# 将key中存储的数字值加 10
> INCRBY number 10
(integer) 11
# 将 key 中储存的数字值减一
> DECR number
(integer) 10
# 将key中存储的数字值键 10
> DECRBY number 10
(integer) 0

过期（默认为永不过期）：

# 设置 key 在 60 秒后过期（该方法是针对已经存在的key设置过期时间）
> EXPIRE name  60 
(integer) 1
# 查看数据还有多久过期
> TTL name 
(integer) 51

#设置 key-value 类型的值，并设置该key的过期时间为 60 秒
> SET key  value EX 60
OK
> SETEX key  60 value
OK

不存在就插入：

# 不存在就插入（not exists）
>SETNX key value
(integer) 1

应用场景

缓存对象

使用 String 来缓存对象有两种方式：

• 直接缓存整个对象的 JSON，命令例子： SET user:1 '{"name":"xiaolin", "age":18}'。
• 采用将 key 进行分离为 user:ID:属性，采用 MSET 存储，用 MGET 获取各属性值，命令例子： MSET user:1:name xiaolin user:1:age 18 user:2:name xiaomei user:2:age 20。

常规计数

因为 Redis 处理命令是单线程，所以执行命令的过程是原子的。

因此 String 数据类型适合计数场景，比如计算访问次数、点赞、转发、库存数量等等。

比如计算文章的阅读量：

# 初始化文章的阅读量
> SET aritcle:readcount:1001 0
OK
#阅读量+1
> INCR aritcle:readcount:1001
(integer) 1
#阅读量+1
> INCR aritcle:readcount:1001
(integer) 2
#阅读量+1
> INCR aritcle:readcount:1001
(integer) 3
# 获取对应文章的阅读量
> GET aritcle:readcount:1001
"3"

分布式锁

SET 命令有个 NX 参数可以实现「key不存在才插入」，可以用它来实现分布式锁：

• 如果 key 不存在，则显示插入成功，可以用来表示加锁成功；
• 如果 key 存在，则会显示插入失败，可以用来表示加锁失败。

一般而言，还会对分布式锁加上过期时间，分布式锁的命令如下：

SET lock_key unique_value NX PX 10000

• lock_key 就是 key 键；
• unique_value 是客户端生成的唯一的标识；
• NX 代表只在 lock_key 不存在时，才对 lock_key 进行设置操作；
• PX 10000 表示设置 lock_key 的过期时间为 10s，这是为了避免客户端发生异常而无法释放锁。

而解锁的过程就是将 lock_key 键删除，但不能乱删，要保证执行操作的客户端就是加锁的客户端。

所以，解锁的时候，我们要先判断锁的 unique_value 是否为加锁客户端，是的话，才将 lock_key 键删除。

可以看到，解锁是有两个操作，这时就需要 Lua 脚本来保证解锁的原子性，因为 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，保证了锁释放操作的原子性。

// 释放锁时，先比较 unique_value 是否相等，避免锁的误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

这样一来，就通过使用 SET 命令和 Lua 脚本在 Redis 单节点上完成了分布式锁的加锁和解锁。

共享 Session 信息

通常我们在开发后台管理系统时，会使用 Session 来保存用户的会话(登录)状态，这些 Session 信息会被保存在服务器端，但这只适用于单系统应用，如果是分布式系统此模式将不再适用。

例如用户一的 Session 信息被存储在服务器一，但第二次访问时用户一被分配到服务器二，这个时候服务器并没有用户一的 Session 信息，就会出现需要重复登录的问题，问题在于分布式系统每次会把请求随机分配到不同的服务器。

分布式系统单独存储 Session 流程图：

因此，我们需要借助 Redis 对这些 Session 信息进行统一的存储和管理，这样无论请求发送到那台服务器，服务器都会去同一个 Redis 获取相关的 Session 信息，这样就解决了分布式系统下 Session 存储的问题。

分布式系统使用同一个 Redis 存储 Session 流程图：

List（列表）

常用指令

# 将一个或多个值value插入到key列表的表头(最左边)，最后的值在最前面
LPUSH key value [value ...] 
# 将一个或多个值value插入到key列表的表尾(最右边)
RPUSH key value [value ...]
# 移除并返回key列表的头元素
LPOP key     
# 移除并返回key列表的尾元素
RPOP key 

# 返回列表key中指定区间内的元素，区间以偏移量start和stop指定，从0开始
LRANGE key start stop

# 从key列表表头弹出一个元素，没有就阻塞timeout秒，如果timeout=0则一直阻塞
BLPOP key [key ...] timeout
# 从key列表表尾弹出一个元素，没有就阻塞timeout秒，如果timeout=0则一直阻塞
BRPOP key [key ...] timeout
# 获取列表长度
LLEN key 			

应用场景

消息队列

消息队列在存取消息时，必须要满足三个需求，分别是消息保序、处理重复的消息和保证消息可靠性。

Redis 的 List 和 Stream 两种数据类型，就可以满足消息队列的这三个需求。

1、如何满足消息保序需求？

List 本身就是按先进先出的顺序对数据进行存取的，所以，如果使用 List 作为消息队列保存消息的话，就已经能满足消息保序的需求了。

List 可以使用 LPUSH + RPOP （或者反过来，RPUSH+LPOP）命令实现消息队列。

• 在消费者读取数据时，有一个潜在的性能风险点：

在生产者往 List 中写入数据时，List 并不会主动地通知消费者有新消息写入，如果消费者想要及时处理消息，就需要在程序中不停地调用 RPOP 命令（比如使用一个while(1)循环）。如果有新消息写入，RPOP命令就会返回结果，否则，RPOP命令返回空值，再继续循环。

所以，即使没有新消息写入List，消费者也要不停地调用 RPOP 命令，这就会导致消费者程序的 CPU 一直消耗在执行 RPOP 命令上，带来不必要的性能损失。

• 为了解决这个问题，Redis提供了 BRPOP 命令。

  BRPOP命令也称为阻塞式读取，客户端在没有读到队列数据时，自动阻塞，直到有新的数据写入队列，再开始读取新数据。和消费者程序自己不停地调用RPOP命令相比，这种方式能节省CPU开销。

2、如何处理重复的消息？

消费者要实现重复消息的判断，需要 2 个方面的要求：

• 每个消息都有一个全局的 ID。
• 消费者要记录已经处理过的消息的 ID。当收到一条消息后，消费者程序就可以对比收到的消息 ID 和记录的已处理过的消息 ID，来判断当前收到的消息有没有经过处理。如果已经处理过，那么，消费者程序就不再进行处理了。

但是 List 并不会为每个消息生成 ID 号，所以我们需要自行为每个消息生成一个全局唯一ID，生成之后，我们在用 LPUSH 命令把消息插入 List 时，需要在消息中包含这个全局唯一 ID。

例如，我们执行以下命令，就把一条全局 ID 为 111000102、库存量为 99 的消息插入了消息队列：

> LPUSH mq "111000102:stock:99"
(integer) 1

3、如何保证消息可靠性？

当消费者程序从 List 中读取一条消息后，List 就不会再留存这条消息了。所以，如果消费者程序在处理消息的过程出现了故障或宕机，就会导致消息没有处理完成，那么，消费者程序再次启动后，就没法再次从 List 中读取消息了。

为了留存消息

List 类型提供了 BRPOPLPUSH 命令，

作用是让消费者程序从一个 List 中读取消息，同时，Redis 会把这个消息再插入到另一个 List（可以叫作备份 List）留存。

这样一来，如果消费者程序读了消息但没能正常处理，等它重启后，就可以从备份 List 中重新读取消息并进行处理了。

好了，到这里可以知道基于 List 类型的消息队列，满足消息队列的三大需求（消息保序、处理重复的消息和保证消息可靠性）。

• 消息保序：使用 LPUSH + RPOP；
• 阻塞读取：使用 BRPOP；
• 重复消息处理：生产者自行实现全局唯一 ID；
• 消息的可靠性：使用 BRPOPLPUSH

List 作为消息队列有什么缺陷？

List 不支持多个消费者消费同一条消息，因为一旦消费者拉取一条消息后，这条消息就从 List 中删除了，无法被其它消费者再次消费。

要实现一条消息可以被多个消费者消费，那么就要将多个消费者组成一个消费组，使得多个消费者可以消费同一条消息，但是 List 类型并不支持消费组的实现。

这就要说起 Redis 从 5.0 版本开始提供的 Stream 数据类型了，Stream 同样能够满足消息队列的三大需求，而且它还支持「消费组」形式的消息读取。

Hash

Hash 是一个键值对（key - value）集合。

常见命令

• key：哈希表的键名。
• field：要设置的字段名。
• value：字段的值。

Redis hash 是一个string类型的 field 和 value 的映射表，hash特别适合用于存储对象，常用命令：

• HSET key field value 将哈希表 key 中的字段 field 的值设为 value
• HGET key field 获取存储在哈希表中指定字段的值
• HDEL key field 删除存储在哈希表中的指定字段
• HKEYS key 获取哈希表中所有字段
• HVALS key 获取哈希表中所有值

# 存储一个哈希表key的键值
HSET key field value   
# 获取哈希表key对应的field键值
HGET key field

# 在一个哈希表key中存储多个键值对
HMSET key field value [field value...] 
# 批量获取哈希表key中多个field键值
HMGET key field [field ...]       
# 删除哈希表key中的field键值
HDEL key field [field ...]    

# 返回哈希表key中field的数量
HLEN key       
# 返回哈希表key中所有的键值
HGETALL key 

# 为哈希表key中field键的值加上增量n
HINCRBY key field n                         

应用场景

Hash 类型的 （key，field， value） 的结构与对象的（对象id， 属性， 值）的结构相似，也可以用来存储对象。

我们以用户信息为例，它在关系型数据库中的结构是这样的：

我们可以使用如下命令，将用户对象的信息存储到 Hash 类型：

# 存储一个哈希表uid:1的键值
> HMSET uid:1 name Tom age 15
2
# 存储一个哈希表uid:2的键值
> HMSET uid:2 name Jerry age 13
2
# 获取哈希表用户id为1中所有的键值
> HGETALL uid:1
1) "name"
2) "Tom"
3) "age"
4) "15"

在介绍 String 类型的应用场景时有所介绍，String + Json也是存储对象的一种方式，那么存储对象时，到底用 String + json 还是用 Hash 呢？

一般对象用 String + Json 存储，对象中某些频繁变化的属性可以考虑抽出来用 Hash 类型存储。

Set

Set 类型是一个无序并唯一的键值集合，它的存储顺序不会按照插入的先后顺序进行存储。

Set 类型和 List 类型的区别如下：

• List 可以存储重复元素，Set 只能存储非重复元素；
• List 是按照元素的先后顺序存储元素的，而 Set 则是无序方式存储元素的。

常用命令

Set常用操作：

# 往集合key中存入元素，元素存在则忽略，若key不存在则新建
SADD key member [member ...]
# 从集合key中删除元素
SREM key member [member ...] 
# 获取集合key中所有元素
SMEMBERS key
# 获取集合key中的元素个数
SCARD key

# 判断member元素是否存在于集合key中
SISMEMBER key member

# 从集合key中随机选出count个元素，元素不从key中删除
SRANDMEMBER key [count]
# 从集合key中随机选出count个元素，元素从key中删除
SPOP key [count]

Set运算操作：

# 交集运算
SINTER key [key ...]
# 将交集结果存入新集合destination中
SINTERSTORE destination key [key ...]

# 并集运算
SUNION key [key ...]
# 将并集结果存入新集合destination中
SUNIONSTORE destination key [key ...]

# 差集运算
SDIFF key [key ...]
# 将差集结果存入新集合destination中
SDIFFSTORE destination key [key ...]

应用场景

Set 类型比较适合用来数据去重和保障数据的唯一性，还可以用来统计多个集合的交集、错集和并集等，当我们存储的数据是无序并且需要去重的情况下，比较适合使用集合类型进行存储。

Set 的差集、并集和交集的计算复杂度较高，在数据量较大的情况下，如果直接执行这些计算，会导致 Redis 实例阻塞。

在主从集群中，为了避免主库因为 Set 做聚合计算（交集、差集、并集）时导致主库被阻塞，我们可以选择一个从库完成聚合统计，或者把数据返回给客户端，由客户端来完成聚合统计。

点赞

Set 类型可以保证一个用户只能点一个赞，这里举例子一个场景，key 是文章id，value 是用户id。

uid:1 、uid:2、uid:3 三个用户分别对 article:1 文章点赞了。

# uid:1 用户对文章 article:1 点赞
> SADD article:1 uid:1
(integer) 1
# uid:2 用户对文章 article:1 点赞
> SADD article:1 uid:2
(integer) 1
# uid:3 用户对文章 article:1 点赞
> SADD article:1 uid:3
(integer) 1

uid:1 取消了对 article:1 文章点赞。

> SREM article:1 uid:1
(integer) 1

获取 article:1 文章所有点赞用户 :

> SMEMBERS article:1
1) "uid:3"
2) "uid:2"

获取 article:1 文章的点赞用户数量：

> SCARD article:1
(integer) 2

判断用户 uid:1 是否对文章 article:1 点赞了：

> SISMEMBER article:1 uid:1
(integer) 0  # 返回0说明没点赞，返回1则说明点赞了

共同关注

Set 类型支持交集运算，所以可以用来计算共同关注的好友、公众号等。

key 可以是用户id，value 则是已关注的公众号的id。

uid:1 用户关注公众号 id 为 5、6、7、8、9，uid:2 用户关注公众号 id 为 7、8、9、10、11。

# uid:1 用户关注公众号 id 为 5、6、7、8、9
> SADD uid:1 5 6 7 8 9
(integer) 5
# uid:2  用户关注公众号 id 为 7、8、9、10、11
> SADD uid:2 7 8 9 10 11
(integer) 5

uid:1 和 uid:2 共同关注的公众号：

# 获取共同关注
> SINTER uid:1 uid:2
1) "7"
2) "8"
3) "9"

给 uid:2 推荐 uid:1 关注的公众号：

> SDIFF uid:1 uid:2
1) "5"
2) "6"

验证某个公众号是否同时被 uid:1 或 uid:2 关注:

> SISMEMBER uid:1 5
(integer) 1 # 返回0，说明关注了
> SISMEMBER uid:2 5
(integer) 0 # 返回0，说明没关注

抽奖活动

存储某活动中中奖的用户名 ，Set 类型因为有去重功能，可以保证同一个用户不会中奖两次。

key为抽奖活动名，value为员工名称，把所有员工名称放入抽奖箱 ：

>SADD lucky Tom Jerry John Sean Marry Lindy Sary Mark
(integer) 5

如果允许重复中奖，可以使用 SRANDMEMBER 命令。

# 抽取 1 个一等奖：
> SRANDMEMBER lucky 1
1) "Tom"
# 抽取 2 个二等奖：
> SRANDMEMBER lucky 2
1) "Mark"
2) "Jerry"
# 抽取 3 个三等奖：
> SRANDMEMBER lucky 3
1) "Sary"
2) "Tom"
3) "Jerry"

如果不允许重复中奖，可以使用 SPOP 命令。

# 抽取一等奖1个
> SPOP lucky 1
1) "Sary"
# 抽取二等奖2个
> SPOP lucky 2
1) "Jerry"
2) "Mark"
# 抽取三等奖3个
> SPOP lucky 3
1) "John"
2) "Sean"
3) "Lindy"

Zset

Zset 常用操作：

# 往有序集合key中加入带分值元素
ZADD key score member [[score member]...]   
# 往有序集合key中删除元素
ZREM key member [member...]                 
# 返回有序集合key中元素member的分值
ZSCORE key member
# 返回有序集合key中元素个数
ZCARD key 

# 为有序集合key中元素member的分值加上increment
ZINCRBY key increment member 

# 正序获取有序集合key从start下标到stop下标的元素
ZRANGE key start stop [WITHSCORES]
# 倒序获取有序集合key从start下标到stop下标的元素
ZREVRANGE key start stop [WITHSCORES]

# 返回有序集合中指定分数区间内的成员，分数由低到高排序。
ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]

# 返回指定成员区间内的成员，按字典正序排列, 分数必须相同。
ZRANGEBYLEX key min max [LIMIT offset count]
# 返回指定成员区间内的成员，按字典倒序排列, 分数必须相同
ZREVRANGEBYLEX key max min [LIMIT offset count]

Zset 运算操作（相比于 Set 类型，ZSet 类型没有支持差集运算）：

# 并集计算(相同元素分值相加)，numberkeys一共多少个key，WEIGHTS每个key对应的分值乘积
ZUNIONSTORE destkey numberkeys key [key...] 
# 交集计算(相同元素分值相加)，numberkeys一共多少个key，WEIGHTS每个key对应的分值乘积
ZINTERSTORE destkey numberkeys key [key...]

应用场景

Zset 类型（Sorted Set，有序集合） 可以根据元素的权重来排序，我们可以自己来决定每个元素的权重值。比如说，我们可以根据元素插入 Sorted Set 的时间确定权重值，先插入的元素权重小，后插入的元素权重大。

在面对需要展示最新列表、排行榜等场景时，如果数据更新频繁或者需要分页显示，可以优先考虑使用 Sorted Set。

排行榜

有序集合比较典型的使用场景就是排行榜。例如学生成绩的排名榜、游戏积分排行榜、视频播放排名、电商系统中商品的销量排名等。

我们以博文点赞排名为例，小林发表了五篇博文，分别获得赞为 200、40、100、50、150。

# arcticle:1 文章获得了200个赞
> ZADD user:xiaolin:ranking 200 arcticle:1
(integer) 1
# arcticle:2 文章获得了40个赞
> ZADD user:xiaolin:ranking 40 arcticle:2
(integer) 1
# arcticle:3 文章获得了100个赞
> ZADD user:xiaolin:ranking 100 arcticle:3
(integer) 1
# arcticle:4 文章获得了50个赞
> ZADD user:xiaolin:ranking 50 arcticle:4
(integer) 1
# arcticle:5 文章获得了150个赞
> ZADD user:xiaolin:ranking 150 arcticle:5
(integer) 1

文章 arcticle:4 新增一个赞，可以使用 ZINCRBY 命令（为有序集合key中元素member的分值加上increment）：

> ZINCRBY user:xiaolin:ranking 1 arcticle:4
"51"

查看某篇文章的赞数，可以使用 ZSCORE 命令（返回有序集合key中元素个数）：

> ZSCORE user:xiaolin:ranking arcticle:4
"50"

获取小林文章赞数最多的 3 篇文章，可以使用 ZREVRANGE 命令（倒序获取有序集合 key 从start下标到stop下标的元素）：

# WITHSCORES 表示把 score 也显示出来
> ZREVRANGE user:xiaolin:ranking 0 2 WITHSCORES
1) "arcticle:1"
2) "200"
3) "arcticle:5"
4) "150"
5) "arcticle:3"
6) "100"

获取小林 100 赞到 200 赞的文章，可以使用 ZRANGEBYSCORE 命令（返回有序集合中指定分数区间内的成员，分数由低到高排序）：

> ZRANGEBYSCORE user:xiaolin:ranking 100 200 WITHSCORES
1) "arcticle:3"
2) "100"
3) "arcticle:5"
4) "150"
5) "arcticle:1"
6) "200"

电话、姓名排序

使用有序集合的 ZRANGEBYLEX 或 ZREVRANGEBYLEX 可以帮助我们实现电话号码或姓名的排序，我们以 ZRANGEBYLEX （返回指定成员区间内的成员，按 key 正序排列，分数必须相同）为例。

注意：不要在分数不一致的 SortSet 集合中去使用 ZRANGEBYLEX和 ZREVRANGEBYLEX 指令，因为获取的结果会不准确。

1、电话排序

我们可以将电话号码存储到 SortSet 中，然后根据需要来获取号段：

> ZADD phone 0 13100111100 0 13110114300 0 13132110901 
(integer) 3
> ZADD phone 0 13200111100 0 13210414300 0 13252110901 
(integer) 3
> ZADD phone 0 13300111100 0 13310414300 0 13352110901 
(integer) 3

获取所有号码:

> ZRANGEBYLEX phone - +
1) "13100111100"
2) "13110114300"
3) "13132110901"
4) "13200111100"
5) "13210414300"
6) "13252110901"
7) "13300111100"
8) "13310414300"
9) "13352110901"

获取 132 号段的号码：

> ZRANGEBYLEX phone [132 (133
1) "13200111100"
2) "13210414300"
3) "13252110901"

获取132、133号段的号码：

> ZRANGEBYLEX phone [132 (134
1) "13200111100"
2) "13210414300"
3) "13252110901"
4) "13300111100"
5) "13310414300"
6) "13352110901"

2、姓名排序

> zadd names 0 Toumas 0 Jake 0 Bluetuo 0 Gaodeng 0 Aimini 0 Aidehua 
(integer) 6

获取所有人的名字:

> ZRANGEBYLEX names - +
1) "Aidehua"
2) "Aimini"
3) "Bluetuo"
4) "Gaodeng"
5) "Jake"
6) "Toumas"

获取名字中大写字母A开头的所有人：

> ZRANGEBYLEX names [A (B
1) "Aidehua"
2) "Aimini"

获取名字中大写字母 C 到 Z 的所有人：

> ZRANGEBYLEX names [C [Z
1) "Gaodeng"
2) "Jake"
3) "Toumas"

BitMap 位图

Bitmap，即位图，是一串连续的二进制数组（0和1），可以通过偏移量（offset）定位元素。BitMap通过最小的单位bit来进行0|1的设置，表示某个元素的值或者状态，时间复杂度为O(1)。

Bitmap 本身是用 String 类型作为底层数据结构实现的一种统计二值状态的数据类型。

String 类型是会保存为二进制的字节数组，所以，Redis 就把字节数组的每个 bit 位利用起来，用来表示一个元素的二值状态，你可以把 Bitmap 看作是一个 bit 数组。

应用场景

Bitmap 类型非常适合二值状态统计的场景，这里的二值状态就是指集合元素的取值就只有 0 和 1 两种，在记录海量数据时，Bitmap 能够有效地节省内存空间。

1. 签到统计

在签到打卡的场景中，我们只用记录签到（1）或未签到（0），所以它就是非常典型的二值状态。

签到统计时，每个用户一天的签到用 1 个 bit 位就能表示，一个月（假设是 31 天）的签到情况用 31 个 bit 位就可以，而一年的签到也只需要用 365 个 bit 位，根本不用太复杂的集合类型。

2. 判断用户登陆态

Bitmap 提供了 GETBIT、SETBIT 操作，通过一个偏移值 offset 对 bit 数组的 offset 位置的 bit 位进行读写操作，需要注意的是 offset 从 0 开始。

只需要一个 key = login_status 表示存储用户登陆状态集合数据， 将用户 ID 作为 offset，在线就设置为 1，下线设置 0。通过 GETBIT判断对应的用户是否在线。 5000 万用户只需要 6 MB 的空间。

3. 连续签到用户总数

如何统计出这连续 7 天连续打卡用户总数呢？

我们把每天的日期作为 Bitmap 的 key，userId 作为 offset，若是打卡则将 offset 位置的 bit 设置成 1。

key 对应的集合的每个 bit 位的数据则是一个用户在该日期的打卡记录。

一共有 7 个这样的 Bitmap，如果我们能对这 7 个 Bitmap 的对应的 bit 位做 『与』运算。同样的 UserID offset 都是一样的，当一个 userID 在 7 个 Bitmap 对应对应的 offset 位置的 bit = 1 就说明该用户 7 天连续打卡。

HyperLogLog

是一种用于「统计基数」的数据集合类型，基数统计就是指统计一个集合中不重复的元素个数。

HyperLogLog 是统计规则是基于概率完成的，不是非常准确，标准误算率是 0.81%。

所以，简单来说 HyperLogLog 提供不精确的去重计数。

HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的内存空间总是固定的、并且是很小的。

应用场景

百万级网页 UV 计数

GEO

主要用于存储地理位置信息，并对存储的信息进行操作。

在日常生活中，我们越来越依赖搜索“附近的餐馆”、在打车软件上叫车，这些都离不开基于位置信息服务的应用。

GEO 本身并没有设计新的底层数据结构，而是直接使用了 Sorted Set 集合类型。

应用场景

滴滴叫车

Stream

Redis Stream 是 Redis 5.0 版本新增加的数据类型，Redis 专门为消息队列设计的数据类型。

在 Redis 5.0 Stream 没出来之前，消息队列的实现方式都有着各自的缺陷，例如：

• 发布订阅模式，不能持久化也就无法可靠的保存消息，并且对于离线重连的客户端不能读取历史消息的缺陷；
• List 实现消息队列的方式不能重复消费，一个消息消费完就会被删除，而且生产者需要自行实现全局唯一 ID。

基于以上问题，Redis 5.0 便推出了 Stream 类型也是此版本最重要的功能，用于完美地实现消息队列，它支持消息的持久化、支持自动生成全局唯一 ID、支持 ack 确认消息的模式、支持消费组模式等，让消息队列更加的稳定和可靠。

应用场景

消息队列

• String 类型的应用场景：缓存对象、常规计数、分布式锁、共享 session 信息等。
• List 类型的应用场景：消息队列（但是有两个问题：1. 生产者需要自行实现全局唯一 ID；2. 不能以消费组形式消费数据）等。
• Hash 类型：缓存对象、购物车等。
• Set 类型：聚合计算（并集、交集、差集）场景，比如点赞、共同关注、抽奖活动等。
• Zset 类型：排序场景，比如排行榜、电话和姓名排序等。

Redis 后续版本又支持四种数据类型，它们的应用场景如下：

• BitMap（2.2 版新增）：二值状态统计的场景，比如签到、判断用户登陆状态、连续签到用户总数等；
• HyperLogLog（2.8 版新增）：海量数据基数统计的场景，比如百万级网页 UV 计数等；
• GEO（3.2 版新增）：存储地理位置信息的场景，比如滴滴叫车；
• Stream（5.0 版新增）：消息队列，相比于基于 List 类型实现的消息队列，有这两个特有的特性：自动生成全局唯一消息ID，支持以消费组形式消费数据。

五种常见的 Redis 数据类型是怎么实现？

String 类型内部实现

String 类型的底层的数据结构实现主要是 SDS（简单动态字符串）

List 类型内部实现

List 类型的底层数据结构是由双向链表或压缩列表实现的：

• 如果列表的元素个数小于 512 个（默认值，可由 list-max-ziplist-entries 配置），列表每个元素的值都小于 64 字节（默认值，可由 list-max-ziplist-value 配置），Redis 会使用压缩列表作为 List 类型的底层数据结构；
• 如果列表的元素不满足上面的条件，Redis 会使用双向链表作为 List 类型的底层数据结构；

但是在 Redis 3.2 版本之后，List 数据类型底层数据结构就只由 quicklist 实现了，替代了双向链表和压缩列表。

Hash 类型内部实现

Hash 类型的底层数据结构是由压缩列表或哈希表实现的：

• 如果哈希类型元素个数小于 512 个（默认值，可由 hash-max-ziplist-entries 配置），所有值小于 64 字节（默认值，可由 hash-max-ziplist-value 配置）的话，Redis 会使用压缩列表作为 Hash 类型的底层数据结构；
• 如果哈希类型元素不满足上面条件，Redis 会使用哈希表作为 Hash 类型的底层数据结构。

在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

Set 类型内部实现

Set 类型的底层数据结构是由哈希表或整数集合实现的：

• 如果集合中的元素都是整数且元素个数小于 512 （默认值，set-maxintset-entries配置）个，Redis 会使用整数集合作为 Set 类型的底层数据结构；
• 如果集合中的元素不满足上面条件，则 Redis 使用哈希表作为 Set 类型的底层数据结构。

ZSet 类型内部实现

Zset 类型的底层数据结构是由压缩列表或跳表实现的：

• 如果有序集合的元素个数小于 128 个，并且每个元素的值小于 64 字节时，Redis 会使用压缩列表作为 Zset 类型的底层数据结构；
• 如果有序集合的元素不满足上面的条件，Redis 会使用跳表作为 Zset 类型的底层数据结构；

在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

Redis 线程模型

Redis 是单线程吗？

Redis 单线程指的是「接收客户端请求->解析请求 ->进行数据读写等操作->发送数据给客户端」这个过程是由一个线程（主线程）来完成的。

Redis它采用单线程模型来处理客户端请求。这里的单线程指的是Redis服务器进程中只有一个主线程来处理所有的网络I/O、数据读写、命令执行等任务，而不是像传统的多线程服务器一样，每个连接都会创建一个新的线程来处理。

{  网络I/O、数据读写、命令执行是？？
1.网络I/O（Input/Output）指的是通过网络进行数据传输的输入和输出操作。在Redis中，网络I/O主要是指接收客户端的请求和发送响应给客户端的过程，包括读取客户端发送的命令、解析命令参数、执行相应的操作，然后将执行结果返回给客户端。
2.数据读写指的是Redis对数据的读取和写入操作。在Redis中，数据以键值对的形式存储在内存中，通过读写操作可以对这些数据进行访问和修改。读操作用于获取指定键的值，而写操作则用于设置键值对或修改已有键的值。
3.命令执行是指Redis服务器根据客户端发送的命令进行相应的操作。Redis支持多种命令，如GET、SET、DEL等，每个命令都有特定的作用和语法，执行命令可以对数据进行查询、修改、删除等操作。
}

之所以 Redis 为「关闭文件、AOF 刷盘、释放内存」这些任务创建单独的线程来处理，是因为这些任务的操作都是很耗时的，如果把这些任务都放在主线程来处理，那么 Redis 主线程就很容易发生阻塞，这样就无法处理后续的请求了。

Redis采用单线程模型的主要原因是为了避免多线程带来的线程切换、锁竞争等开销，从而提高系统的吞吐量和响应速度。此外，单线程模型还可以简化系统的设计和实现，减少出错的概率。

Redis 单线程模式是怎样的？

Redis 采用单线程为什么还这么快？

Redis 采用单线程（网络 I/O 和执行命令）那么快，有如下几个原因：

• Redis 的大部分操作都在内存中完成因此 Redis 瓶颈可能是机器的内存或者网络带宽，而并非 CPU，既然 CPU 不是瓶颈，那么自然就采用单线程的解决方案了；

• Redis 采用单线程模型可以避免了多线程之间的竞争，省去了多线程切换带来的时间和性能上的开销，而且也不会导致死锁问题。

• Redis 采用了 I/O 多路复用机制，非阻塞IO，处理大量的客户端 Socket 请求。（例如，bgsave 和 bgrewriteaof 都是在后台执行操作，不影响主线程的正常使用，不会产生阻塞）使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，Redis 采用自己实现的事件分离器，效率比较高。

• Redis高效数据结构，对数据的操作也比较简单：

​ （1）整个 Redis 就是一个全局哈希表：他的时间复杂度是 O(1)，而且为了防止哈希冲突导致链表过长，Redis 会执行 rehash 操作，扩充 哈希桶数量，减少哈希冲突。并且防止一次性重新映射数据过大导致线程阻塞，采用 渐进式 rehash。巧妙的将一次性拷贝分摊到多次请求过程后总，避免阻塞。

​ （2）Redis 全程使用 hash 结构：读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。可以根据实际存储的数据类型选择不同编码。

Redis 很快原理总结：

1. 纯内存操作：一般都是简单的存取操作，线程占用的时间很少，时间的花费主要集中在 IO 上，所以读取速度快。采用单线程模型
2. 保证每个操作的原子性，也减少了线程的上下文切换和竞争。
3. 使用IO多路复用模型：非阻塞 IO，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，Redis 采用自己实现的事件分离器，效率比较高。
4. Redis高效数据结构，对数据的操作也比较简单：

​ 整个 Redis 就是一个全局哈希表：他的时间复杂度是 O(1)，而且为了防止哈希冲突导致链表过长，Redis 会执行 rehash 操作，扩充 哈希桶数量，减少哈希冲突。并且防止一次性重新映射数据过大导致线程阻塞，采用 渐进式 rehash。巧妙的将一次性拷贝分摊到多次请求过程后总，避免阻塞。

​ Redis 全程使用 hash 结构：读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。可以根据实际存储的数据类型选择不同编码。

IO 多路复用机制

是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听 Socket 和已连接 Socket。内核会一直监听这些 Socket 上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。

I/O多路复用是指利用单个线程来同时监听多个Socket ，并 在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU 资源。目前的I/O多路复用都是采用的epoll模式实现，它会在通知用户进程 Socket就绪的同时，把已就绪的Socket写入用户空间，不需要挨个遍历 Socket来判断是否就绪，提升了性能。

其中Redis的网络模型就是使用I/O多路复用结合事件的处理器来应对多个 Socket请求，比如，提供了连接应答处理器、命令回复处理器，命令请求处理器；

在Redis6.0之后，为了提升更好的性能，在命令回复处理器使用了多线程来处理回复事件，在命令请求处理器中，将命令的转换使用了多线程，增加命令转换速度，在命令执行的时候，依然是单线程。

Redis使用IO多路复用（IO multiplexing）机制来同时监听多个文件描述符？（sockets或者文件等），这是一种高效的IO处理方式，能够有效地管理多个IO事件并在事件发生时作出相应的处理。

在Redis中，IO多路复用机制通常是通过select、poll、epoll这些系统调用来实现的，具体选择哪种机制取决于操作系统和性能需求。这些机制都可以监视多个文件描述符，并在有事件发生时通知应用程序，从而实现同时管理多个IO事件的能力。

通过IO多路复用机制，Redis可以在一个线程中同时监听多个客户端连接的IO事件，当有数据到达或连接就绪时，Redis可以立即作出响应，而不需要为每个连接创建一个单独的线程或进程，从而减少了系统资源的开销，提高了IO处理的效率。（redis快的原因之一）

总的来说，Redis使用IO多路复用机制可以更高效地处理多个IO事件，提高系统的性能和响应速度，是一种常见的IO处理方式，尤其适用于需要高效处理大量并发IO请求的场景。

Redis 6.0 之前为什么使用单线程？

CPU 并不是制约 Redis 性能表现的瓶颈所在，更多情况下是受到内存大小和网络I/O的限制，所以 Redis 核心网络模型使用单线程并没有什么问题。

使用了单线程后，可维护性高，多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。

Redis 6.0 之后为什么引入了多线程？

虽然 Redis 的主要工作（网络 I/O 和执行命令）一直是单线程模型，但是在 Redis 6.0 版本之后，也采用了多个 I/O 线程来处理网络请求，这是因为随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 I/O 的处理上。

所以为了提高网络 I/O 的并行度，Redis 6.0 对于网络 I/O 采用多线程来处理。但是对于命令的执行，Redis 仍然使用单线程来处理。

Redis 持久化

Redis 如何实现数据不丢失？

Redis 的读写操作都是在内存中，所以 Redis 性能才会高，但是当 Redis 重启后，内存中的数据就会丢失。

为了保证内存中的数据不会丢失，Redis 实现了数据持久化的机制，这个机制会把数据存储到磁盘，这样在 Redis 重启就能够从磁盘中恢复原有的数据。

Redis 共有三种数据持久化的方式：

• AOF 日志：每执行一条写操作命令，就把该命令以追加的方式写入到一个文件里；
• RDB 快照：将某一时刻的内存数据，以二进制的方式写入磁盘；
• 混合持久化方式：Redis 4.0 新增的方式，集成了 AOF 和 RBD 的优点；

AOF 日志是如何实现的？

Redis 在执行完一条写操作命令后，就会把该命令以追加的方式写入到一个文件里，然后 Redis 重启时，会读取该文件记录的命令，然后逐一执行命令的方式来进行数据恢复。

为什么先执行命令，再把数据写入日志呢？

Reids 是先执行写操作命令后，才将该命令记录到 AOF 日志里的，这么做其实有两个好处。

• 避免额外的检查开销：因为如果先将写操作命令记录到 AOF 日志里，再执行该命令的话，如果当前的命令语法有问题，那么如果不进行命令语法检查，该错误的命令记录到 AOF 日志里后，Redis 在使用日志恢复数据时，就可能会出错。
• 不会阻塞当前写操作命令的执行：因为当写操作命令执行成功后，才会将命令记录到 AOF 日志。

当然，这样做也会带来风险：

• 数据可能会丢失： 执行写操作命令和记录日志是两个过程，那当 Redis 在还没来得及将命令写入到硬盘时，服务器发生宕机了，这个数据就会有丢失的风险。
• 可能阻塞其他操作： 由于写操作命令执行成功后才记录到 AOF 日志，所以不会阻塞当前命令的执行，但因为 AOF 日志也是在主线程中执行，所以当 Redis 把日志文件写入磁盘的时候，还是会阻塞后续的操作无法执行。

AOF 写回策略

具体内核缓冲区的数据什么时候写入到硬盘，由内核决定。

• Always，这个单词的意思是「总是」，所以它的意思是每次写操作命令执行完后，同步将 AOF 日志数据写回硬盘；
• Everysec，这个单词的意思是「每秒」，所以它的意思是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，然后每隔一秒将缓冲区里的内容写回到硬盘；
• No，意味着不由 Redis 控制写回硬盘的时机，转交给操作系统控制写回的时机，也就是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，再由操作系统决定何时将缓冲区内容写回硬盘。

AOF 重写机制

AOF 日志文件过大就会带来性能问题，比如重启 Redis 后，需要读 AOF 文件的内容以恢复数据，如果文件过大，整个恢复的过程就会很慢。当 AOF 文件的大小超过所设定的阈值后，Redis 就会启用 AOF 重写机制，来压缩 AOF 文件。

举个例子，在没有使用重写机制前，假设前后执行了「set name xiaolin」和「set name xiaolincoding」这两个命令的话，就会将这两个命令记录到 AOF 文件。

但是在使用重写机制后，就会读取 name 最新的 value（键值对） ，然后用一条 「set name xiaolincoding」命令记录到新的 AOF 文件，之前的第一个命令就没有必要记录了，因为它属于「历史」命令。一个键值对在重写日志中只用一条命令就行了。

重写过程

Redis 的重写 AOF 过程是由后台子进程 bgrewriteaof来完成的，这么做可以达到两个好处：

• 子进程进行 AOF 重写期间，主进程可以继续处理命令请求，从而避免阻塞主进程；
• 子进程带有主进程的数据副本，这里使用子进程而不是线程，因为如果是使用线程，多线程之间会共享内存，那么在修改共享内存数据的时候，需要通过加锁来保证数据的安全，而这样就会降低性能。而使用子进程，创建子进程时，父子进程是共享内存数据的，不过这个共享的内存只能以只读的方式，而当父子进程任意一方修改了该共享内存，就会发生「写时复制」，于是父子进程就有了独立的数据副本，就不用加锁来保证数据安全。

重写 AOF 日志过程中，如果主进程修改了已经存在 key-value，此时这个 key-value 数据在子进程的内存数据就跟主进程的内存数据不一致了，这时要怎么办呢？

为了解决这种数据不一致问题，Redis 设置了一个 AOF 重写缓冲区，这个缓冲区在创建 bgrewriteaof 子进程之后开始使用。

在重写 AOF 期间，当 Redis 执行完一个写命令之后，它会同时将这个写命令写入到 「AOF 缓冲区」和 「AOF 重写缓冲区」。

在 bgrewriteaof 子进程执行 AOF 重写期间，主进程需要执行以下三个工作:

• 执行客户端发来的命令；
• 将执行后的写命令追加到 「AOF 缓冲区」；
• 将执行后的写命令追加到 「AOF 重写缓冲区」；

当子进程完成 AOF 重写工作（扫描数据库中所有数据，逐一把内存数据的键值对转换成一条命令，再将命令记录到重写日志）后，会向主进程发送一条信号，信号是进程间通讯的一种方式，且是异步的。

主进程收到该信号后，会调用一个信号处理函数，该函数主要做以下工作：

• 将 AOF 重写缓冲区中的所有内容追加到新的 AOF 的文件中，使得新旧两个 AOF 文件所保存的数据库状态一致；
• 新的 AOF 的文件进行改名，覆盖现有的 AOF 文件。

RDB 快照是如何实现的呢？

AOF 日志记录的是操作命令，不是实际的数据，用 AOF 方法做故障恢复时，需要全量把日志都执行一遍，一旦 AOF 日志非常多， Redis 的恢复操作缓慢。

RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据，而 AOF 文件记录的是命令操作的日志，而不是实际的数据。

RDB 做快照时会阻塞线程吗？

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave，他们的区别就在于是否在「主线程」里执行：

• 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；
• 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞；

RDB 在执行快照的时候，数据能修改吗？

执行 bgsave 过程中，Redis 依然可以继续处理操作命令的，也就是数据是能被修改的，关键的技术就在于写时复制技术（Copy-On-Write, COW）。

• 执行 bgsave 命令的时候，会通过 fork() 创建子进程，此时子进程和父进程是共享同一片内存数据的，因为创建子进程的时候，会复制父进程的页表，但是页表指向的物理内存还是一个，此时如果主线程执行读操作，则主线程和 bgsave 子进程互相不影响。
• 如果主线程执行写操作，则被修改的数据会复制一份副本，然后 bgsave 子进程会把该副本数据写入 RDB 文件，在这个过程中，主线程仍然可以直接修改原来的数据。

为什么会有混合持久化？

RDB 优点是数据恢复速度快，但是快照的频率不好把握。频率太低，丢失的数据就会比较多，频率太高，就会影响性能。

AOF 优点是丢失数据少，但是数据恢复不快。

混合持久化优点：

• 混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快的启动，同时结合 AOF 的优点，有减低了大量数据丢失的风险。

混合持久化缺点：

• AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；
• 兼容性差，如果开启混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。

Redis 集群方案

Redis 如何实现服务高可用？

要想设计一个高可用的 Redis 服务，一定要从 Redis 的多服务节点来考虑，比如 Redis 的主从复制、哨兵模式、切片集群。

1.主从复制

主从复制是 Redis 高可用服务的最基础的保证，实现方案就是将从前的一台 Redis 服务器，同步数据到多台从 Redis 服务器上，即一主多从的模式，且主从服务器之间采用的是「读写分离」的方式。

主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。

主从服务器之间的命令复制是异步进行的。

具体来说，在主从服务器命令传播阶段，主服务器收到新的写命令后，会发送给从服务器。但是，主服务器并不会等到从服务器实际执行完命令后，再把结果返回给客户端，而是主服务器自己在本地执行完命令后，就会向客户端返回结果了。如果从服务器还没有执行主服务器同步过来的命令，主从服务器间的数据就不一致了。

所以，无法实现强一致性保证（主从数据时时刻刻保持一致），数据不一致是难以避免的。

2.哨兵模式

在使用 Redis 主从服务的时候，会有一个问题，就是当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复。

为了解决这个问题，Redis 增加了哨兵模式（Redis Sentinel），因为哨兵模式做到了可以监控主从服务器，并且提供主从节点故障转移的功能。

3.切片集群模式

当 Redis 缓存数据量大到一台服务器无法缓存时，就需要使用 Redis 切片集群（Redis Cluster ）方案，它将数据分布在不同的服务器上，以此来降低系统对单主节点的依赖，从而提高 Redis 服务的读写性能。

分片集群主要解决的是：

海量数据存储的问题，集群中有多个 master，每个master保存不同数据，并且还可以给每个master设置多个slave 节点，就可以继续增大集群的高并发能力。同时每个master之间通过ping监 测彼此健康状态，就类似于哨兵模式了。当客户端请求可以访问集群任意节 点，最终都会被转发到正确节点

Redis分片集群中数据是怎么存储和读取的？

在redis集群中是这样的 Redis 集群引入了哈希槽的概念，有 16384 个哈希槽，集群中每个主节点绑 定了一定范围的哈希槽范围， key通过 CRC16 校验后对 16384 取模来决定放 置哪个槽，通过槽找到对应的节点进行存储。 取值的逻辑是一样的

集群脑裂导致数据丢失怎么办？

什么是脑裂？

在 Redis 主从架构中，部署方式一般是「一主多从」，主节点提供写操作，从节点提供读操作。

如果主节点的网络突然发生了问题，它与所有的从节点都失联了，但是此时的主节点和客户端的网络是正常的，这个客户端并不知道 Redis 内部已经出现了问题，还在照样的向这个失联的主节点写数据（过程A），此时这些数据被旧主节点缓存到了缓冲区里，因为主从节点之间的网络问题，这些数据都是无法同步给从节点的。

这时，哨兵也发现主节点失联了，它就认为主节点挂了（但实际上主节点正常运行，只是网络出问题了），于是哨兵就会在「从节点」中选举出一个 leader 作为主节点，这时集群就有两个主节点了 —— 脑裂出现了。

然后，网络突然好了，哨兵因为之前已经选举出一个新主节点了，它就会把旧主节点降级为从节点（A），然后从节点（A）会向新主节点请求数据同步，因为第一次同步是全量同步的方式，此时的从节点（A）会清空掉自己本地的数据，然后再做全量同步。所以，之前客户端在过程 A 写入的数据就会丢失了，也就是集群产生脑裂数据丢失的问题。

总结：由于网络问题，集群节点之间失去联系。主从数据不同步；重新平衡选举，产生两个主服务。等网络恢复，旧主节点会降级为从节点，再与新主节点进行同步复制的时候，由于会从节点会清空自己的缓冲区，所以导致之前客户端写入的数据丢失了。

解决方案

当主节点发现从节点下线或者通信超时的总数量小于阈值时，那么禁止主节点进行写数据，直接把错误返回给客户端。

在 Redis 的配置文件中有两个参数我们可以设置：

• min-slaves-to-write x，主节点必须要有至少 x 个从节点连接，如果小于这个数，主节点会禁止写数据。

• min-slaves-max-lag x，主从数据复制和同步的延迟不能超过 x 秒，如果超过，主节点会禁止写数据。

关于解决的话，我记得在redis的配置中可以设置：第一可以设置最少的salve 节点个数，比如设置至少要有一个从节点才能同步数据，第二个可以设置主 从数据复制和同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的 数据丢失

Redis 过期删除与内存淘汰

过期删除策略

Redis 使用的过期删除策略是「惰性删除+定期删除」这两种策略配和使用。

当我们查询一个 key 时，Redis 首先检查该 key 是否存在于过期字典中：

• 如果不在，则正常读取键值；
• 如果存在，则会获取该 key 的过期时间，然后与当前系统时间进行比对，如果比系统时间大，那就没有过期，否则判定该 key 已过期。

1. 惰性删除

不主动删除过期键，每次从数据库访问 key 时，都检测 key 是否过期，如果过期则删除该 key。

惰性删除策略的优点：

• 因为每次访问时，才会检查 key 是否过期，所以此策略只会使用很少的系统资源，因此，惰性删除策略对 CPU 时间最友好。

惰性删除策略的缺点：

• 如果一个 key 已经过期，而这个 key 又仍然保留在数据库中，那么只要这个过期 key 一直没有被访问，它所占用的内存就不会释放，造成了一定的内存空间浪费。所以，惰性删除策略对内存不友好。

2. 定期删除

每隔一段时间「随机」从数据库中取出一定数量的 key 进行检查，并删除其中的过期key。

Redis 的定期删除的流程：

在 Redis 中，默认每秒进行 10 次过期检查一次数据库，此配置可通过 Redis 的配置文件 redis.conf 进行配置，配置键为 hz 它的默认值是 hz 10。

1. 从过期字典中随机抽取 20 个 key；
2. 检查这 20 个 key 是否过期，并删除已过期的 key；
3. 如果本轮检查的已过期 key 的数量，超过 5 个（20/4），也就是「已过期 key 的数量」占比「随机抽取 key 的数量」大于 25%，则继续重复步骤 1；如果已过期的 key 比例小于 25%，则停止继续删除过期 key，然后等待下一轮再检查。

定期删除是一个循环的流程。那 Redis 为了保证定期删除不会出现循环过度，导致线程卡死现象，为此增加了定期删除循环流程的时间上限，默认不会超过 25ms。

定期清理的两种模式：

SLOW模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配 置文件redis.conf 的 hz 选项来调整这个次数

FAST模式执行频率不固定，每次事件循环会尝试执行，但两次间隔不低于2ms， 每次耗时不超过1ms

定期删除策略的优点：

• 通过限制删除操作执行的时长和频率，来减少删除操作对 CPU 的影响，同时也能删除一部分过期的数据减少了过期键对空间的无效占用。

定期删除策略的缺点：

• 难以确定删除操作执行的时长和频率。如果执行的太频繁，就会对 CPU 不友好；如果执行的太少，那又和惰性删除一样了，过期 key 占用的内存不会及时得到释放。

3. 定时删除

定时删除策略的做法是，在设置 key 的过期时间时，同时创建一个定时事件，当时间到达时，由事件处理器自动执行 key 的删除操作。

定时删除策略的优点：

• 可以保证过期 key 会被尽快删除，也就是内存可以被尽快地释放。因此，定时删除对内存是最友好的。

定时删除策略的缺点：

• 在过期 key 比较多的情况下，删除过期 key 可能会占用相当一部分 CPU 时间，在内存不紧张但 CPU 时间紧张的情况下，将 CPU 时间用于删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响。所以，定时删除策略对 CPU 不友好。

Redis 过期删除策略

可以看到，惰性删除策略和定期删除策略都有各自的优点，所以 Redis 选择「惰性删除+定期删除」这两种策略配和使用，以求在合理使用 CPU 时间和避免内存浪费之间取得平衡。

Redis 持久化时，对过期键会如何处理的？

RDB 文件分为两个阶段，RDB 文件生成阶段和加载阶段。

• RDB 文件生成阶段：从内存状态持久化成 RDB（文件）的时候，会对 key 进行过期检查，过期的键「不会」被保存到新的 RDB 文件中，因此 Redis 中的过期键不会对生成新 RDB 文件产生任何影响。
• RDB 加载阶段：RDB 加载阶段时，要看服务器是主服务器还是从服务器，分别对应以下两种情况：
  • 如果 Redis 是「主服务器」运行模式的话，在载入 RDB 文件时，程序会对文件中保存的键进行检查，过期键「不会」被载入到数据库中。所以过期键不会对载入 RDB 文件的主服务器造成影响；
  • 如果 Redis 是「从服务器」运行模式的话，在载入 RDB 文件时，不论键是否过期都会被载入到数据库中。但由于主从服务器在进行数据同步时，从服务器的数据会被清空。所以一般来说，过期键对载入 RDB 文件的从服务器也不会造成影响。

AOF 文件分为两个阶段，AOF 文件写入阶段和 AOF 重写阶段。

• AOF 文件写入阶段：当 Redis 以 AOF 模式持久化时，如果数据库某个过期键还没被删除，那么 AOF 文件会保留此过期键，当此过期键被删除后，Redis 会向 AOF 文件追加一条 DEL 命令来显式地删除该键值。
• AOF 重写阶段：执行 AOF 重写时，会对 Redis 中的键值对进行检查，已过期的键不会被保存到重写后的 AOF 文件中，因此不会对 AOF 重写造成任何影响。

Redis 主从模式中，对过期键会如何处理？

当 Redis 运行在主从模式下时，从库不会进行过期扫描，从库对过期的处理是被动的。

即使从库中的 key 过期了，如果有客户端访问从库时，依然可以得到 key 对应的值，像未过期的键值对一样返回。

从库的过期键处理依靠主服务器控制，主库在 key 到期时，会在 AOF 文件里增加一条 del 指令，同步到所有的从库，从库通过执行这条 del 指令来删除过期的 key。

内存淘汰策略

Redis 内存满了，会触发内存淘汰机制，这个阀值就是我们设置的最大运行内存。此值在 Redis 的配置文件中可以找到，配置项为 maxmemory。

1、不进行数据淘汰的策略

noeviction（Redis3.0之后，默认的内存淘汰策略） ：它表示当运行内存超过最大设置内存时，不淘汰任何数据，而是不再提供服务，直接返回错误。

2、进行数据淘汰的策略

针对「进行数据淘汰」这一类策略，又可以细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」这两类策略。

LRU的意思就是最少最近使用，用当前时间减去最后一次访问时间，这个值 越大则淘汰优先级越高。

LFU的意思是最少频率使用。会统计每个key的访问频率，值越小淘汰优先级 越高

在设置了过期时间的数据中进行淘汰：

• volatile-random：随机淘汰设置了过期时间的任意键值；
• volatile-ttl：优先淘汰更早过期的键值。
• volatile-lru（Redis3.0 之前，默认的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最久未使用的键值；
• volatile-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最少使用的键值；

在所有数据范围内进行淘汰：

• allkeys-random：随机淘汰任意键值;
• allkeys-lru：淘汰整个键值中最久未使用的键值；
• allkeys-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰整个键值中最少使用的键值。

LRU 算法和 LFU 算法区别

LRU

Least Recently Used 翻译为最近最少使用，会选择淘汰最近最少使用的数据。

Redis 是如何实现 LRU 算法的？

Redis 实现的是一种近似 LRU 算法，目的是为了更好的节约内存，它的实现方式是在 Redis 的对象结构体中添加一个额外的字段，用于记录此数据的最后一次访问时间。

当 Redis 进行内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5 个值（此值可配置），然后淘汰最久没有使用的那个。

Redis 实现的 LRU 算法的优点：

• 不用为所有的数据维护一个大链表，节省了空间占用；
• 不用在每次数据访问时都移动链表项，提升了缓存的性能；

但 LRU 算法有一个问题，无法解决缓存污染问题。

比如应用一次读取了大量的数据，而这些数据只会被读取这一次，那么这些数据会留存在 Redis 缓存中很长一段时间，造成缓存污染。

LFU

Least Frequently Used 翻译为最近最不常用的，LFU 算法是根据数据访问次数来淘汰数据的，它的核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。

Redis 是如何实现 LRU 算法的？

LFU 算法相比于 LRU 算法的实现，多记录了「数据的访问频次」的信息。

Redis 过期删除策略和内存淘汰策略有什么区别？

Redis 使用的过期删除策略是「惰性删除+定期删除」，删除的对象是已过期的 key。

****

内存淘汰策略是解决内存过大的问题，当 Redis 的运行内存超过最大运行内存时，就会触发内存淘汰策略。

Redis 4.0 之后共实现了 8 种内存淘汰策略

Redis 缓存设计

缓存雪崩、缓存击穿、缓存穿透

用户的数据一般都是存储于数据库，数据库的数据是落在磁盘上的，磁盘的读写速度可以说是计算机里最慢的硬件了。

当用户的请求，都访问数据库的话，请求数量一上来，数据库很容易就奔溃的了，所以为了避免用户直接访问数据库，会用 Redis 作为缓存层。

因为 Redis 是内存数据库，我们可以将数据库的数据缓存在 Redis 里，相当于数据缓存在内存，内存的读写速度比硬盘快好几个数量级，这样大大提高了系统性能。

缓存雪崩

通常我们为了保证缓存中的数据与数据库中的数据一致性，会给 Redis 里的数据设置过期时间，当缓存数据过期后，用户访问的数据如果不在缓存里，业务系统需要重新生成缓存，因此就会访问数据库，并将数据更新到 Redis 里，这样后续请求都可以直接命中缓存。

那么，当大量缓存数据在同一时间过期（失效）时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。

可以采用两种方案解决。

• 将缓存失效时间随机打散： 我们可以在原有的失效时间基础上增加一个随机值（比如 1 到 10 分钟）这样每个缓存的过期时间都不重复了，也就降低了缓存集体失效的概率。
• 设置缓存不过期： 我们可以通过后台服务来更新缓存数据，从而避免因为缓存失效造成的缓存雪崩，也可以在一定程度上避免缓存并发问题。并将更新缓存的工作交由后台线程定时更新。

缓存击穿

我们的业务通常会有几个数据会被频繁地访问，比如秒杀活动，这类被频地访问的数据被称为热点数据。

如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，这就是缓存击穿的问题。

可以发现缓存击穿跟缓存雪崩很相似，你可以认为缓存击穿是缓存雪崩的一个子集。

应对缓存击穿可以采取前面说到两种方案：

• 互斥锁方案，保证同一时间只有一个业务线程请求缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。

• 不给热点数据设置过期时间，由后台异步更新缓存，或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间；

①：在设置key的时候，设置一个过期时间字段一块存入缓存中，不给当前 key设置过期时间

②：当查询的时候，从redis取出数据后判断时间是否过期

③：如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据， 这个数据不是最新

如果选择数据的强一致性，建议使用分布式锁的方案，性能上可能没那么高，锁需要等，也有可能产生死锁的问题

如果选择key的逻辑删除，则优先考虑的高可用性，性能比较高，但是数据同步这块做不到强一致。

缓存穿透

当发生缓存雪崩或击穿时，数据库中还是保存了应用要访问的数据，一旦缓存恢复相对应的数据，就可以减轻数据库的压力，而缓存穿透就不一样了。

当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。

缓存穿透的发生一般有这两种情况：

• 业务误操作，缓存中的数据和数据库中的数据都被误删除了，所以导致缓存和数据库中都没有数据；
• 黑客恶意攻击，故意大量访问某些读取不存在数据的业务；

应对缓存穿透的方案，常见的方案有三种。

• 非法请求的限制：当有大量恶意请求访问不存在的数据的时候，也会发生缓存穿透，因此在 API 入口处我们要判断求请求参数是否合理，请求参数是否含有非法值、请求字段是否存在，如果判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。
• 设置空值或者默认值：当我们线上业务发现缓存穿透的现象时，可以针对查询的数据，在缓存中设置一个空值或者默认值，这样后续请求就可以从缓存中读取到空值或者默认值，返回给应用，而不会继续查询数据库。实现简单，维护方便；额外的内存消耗；可能造成短期的不一致。
• 使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在：我们可以在写入数据库数据时，使用布隆过滤器做个标记，然后在用户请求到来时，业务线程确认缓存失效后，可以通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在，即使发生了缓存穿透，大量请求只会查询 Redis 和布隆过滤器，而不会查询数据库，保证了数据库能正常运行，Redis 自身也是支持布隆过滤器的。内存占用较少，没有多余key；实现复杂；存在误判可能。

布隆过滤器原理

布隆过滤器主要是用于检索一个元素是否在一个集合中。

布隆过滤器的核心思想是使用多个哈希函数来将元素映射到位数组中的多个位置上。当一个元素被加入到布隆过滤器中时，它会被多次哈希，并将对应的位数组位置设置为1。当需要判断一个元素是否在布隆过滤器中时，我们只需将该元素进行多次哈希，并检查对应的位数组位置是否都为1，如果其中有任意一位为0，则说明该元素不在集合中；如果所有位都为1，则说明该元素可能在集合中（因为有可能存在哈希冲突），需要进一步检查。

布隆过滤器应对缓存穿透问题的工具。

布隆过滤器由「初始值都为 0 的位图数组」和「 N 个哈希函数」两部分组成。当我们在写入数据库数据时，在布隆过滤器里做个标记，这样下次查询数据是否在数据库时，只需要查询布隆过滤器，如果查询到数据没有被标记，说明不在数据库中。

布隆过滤器会通过 3 个操作完成标记：

• 第一步，使用 N 个哈希函数分别对数据做哈希计算，得到 N 个哈希值；
• 第二步，将第一步得到的 N 个哈希值对位图数组的长度取模，得到每个哈希值在位图数组的对应位置。
• 第三步，将每个哈希值在位图数组的对应位置的值设置为 1；

举个例子，假设有一个位图数组长度为 8，哈希函数 3 个的布隆过滤器。

在数据库写入数据 x 后，把数据 x 标记在布隆过滤器时，数据 x 会被 3 个哈希函数分别计算出 3 个哈希值，然后在对这 3 个哈希值对 8 取模，假设取模的结果为 1、4、6，然后把位图数组的第 1、4、6 位置的值设置为 1。当应用要查询数据 x 是否数据库时，通过布隆过滤器只要查到位图数组的第 1、4、6 位置的值是否全为 1，只要有一个为 0，就认为数据 x 不在数据库中。

布隆过滤器由于是基于哈希函数实现查找的，高效查找的同时存在哈希冲突的可能性，比如数据 x 和数据 y 可能都落在第 1、4、6 位置，而事实上，可能数据库中并不存在数据 y，存在误判的情况。

所以，查询布隆过滤器说数据存在，并不一定证明数据库中存在这个数据，但是查询到数据不存在，数据库中一定就不存在这个数据。

总的来说，布隆过滤器通过牺牲一定的准确性来换取内存占用和查询速度上的优势，因此在设计和使用时需要权衡误判率和内存消耗。

使用BitMap作为布隆过滤器，使用多个hash函数对key进行hash运算，得到一个整数索引值，对位数组长度进行取模运算得到一个位置，每个hash函数都会得到一个不同的位置，将这几个位置的值置为1。

向布隆过滤器查询某个key是否存在时，先把这个 key 通过相同的多个 hash 函数进行运算，查看对应的位置是否都为 1，

只要有一个位为零，那么说明布隆过滤器中这个 key 不存在；

如果这几个位置全都是 1，那么说明极有可能存在但不是一定存在；

因为这些位置的 1 可能是因为其他的 key 存在导致的，也就是前面说过的hash冲突。

设计缓存策略，可以动态缓存热点数据呢？

热点数据动态缓存的策略总体思路：通过数据最新访问时间来做排名，并过滤掉不常访问的数据，只留下经常访问的数据。

以电商平台场景中的例子，现在要求只缓存用户经常访问的 Top 1000 的商品。具体细节如下：

• 先通过缓存系统做一个排序队列（比如存放 1000 个商品），系统会根据商品的访问时间，更新队列信息，越是最近访问的商品排名越靠前；
• 同时系统会定期过滤掉队列中排名最后的 200 个商品，然后再从数据库中随机读取出 200 个商品加入队列中；
• 这样当请求每次到达的时候，会先从队列中获取商品 ID，如果命中，就根据 ID 再从另一个缓存数据结构中读取实际的商品信息，并返回。

常见的缓存更新策略

常见的缓存更新策略共有3种：

• Cache Aside（旁路缓存）策略；
• Read/Write Through（读穿 / 写穿）策略；
• Write Back（写回）策略；

Cache Aside（旁路缓存）策略

Cache Aside（旁路缓存）策略是最常用的，应用程序直接与「数据库、缓存」交互，并负责对缓存的维护。

该策略又可以细分为「读策略」和「写策略」。

写策略的步骤：

• 先更新数据库中的数据，再删除缓存中的数据。

读策略的步骤：

• 如果读取的数据命中了缓存，则直接返回数据；
• 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。

注意，写策略的步骤的顺序不能倒过来，即不能先删除缓存再更新数据库，原因是在「读+写」并发的时候，会出现缓存和数据库的数据不一致性的问题。

举个例子，假设某个用户的年龄是 20，请求 A 要更新用户年龄为 21，所以它会删除缓存中的内容。这时，另一个请求 B 要读取这个用户的年龄，它查询缓存发现未命中后，会从数据库中读取到年龄为 20，并且写入到缓存中，然后请求 A 继续更改数据库，将用户的年龄更新为 21。

最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库的数据不一致。

为什么「先更新数据库再删除缓存」不会有数据不一致的问题？

继续用「读 + 写」请求的并发的场景来分析。

假如某个用户数据在缓存中不存在，请求 A 读取数据时从数据库中查询到年龄为 20，在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21，并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存中。

假如某个用户数据在缓存中不存在，请求 A 读取数据时从数据库中查询到年龄为 20，在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21，并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存中。

最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库数据不一致。 从上面的理论上分析，先更新数据库，再删除缓存也是会出现数据不一致性的问题，但是在实际中，这个问题出现的概率并不高。

因为缓存的写入通常要远远快于数据库的写入，所以在实际中很难出现请求 B 已经更新了数据库并且删除了缓存，请求 A 才更新完缓存的情况。而一旦请求 A 早于请求 B 删除缓存之前更新了缓存，那么接下来的请求就会因为缓存不命中而从数据库中重新读取数据，所以不会出现这种不一致的情况。

Cache Aside 策略适合读多写少的场景，不适合写多的场景，因为当写入比较频繁时，缓存中的数据会被频繁地清理，这样会对缓存的命中率有一些影响。如果业务对缓存命中率有严格的要求，那么可以考虑两种解决方案：

• 一种做法是在更新数据时也更新缓存，只是在更新缓存前先加一个分布式锁，因为这样在同一时间只允许一个线程更新缓存，就不会产生并发问题了。当然这么做对于写入的性能会有一些影响；
• 另一种做法同样也是在更新数据时更新缓存，只是给缓存加一个较短的过期时间，这样即使出现缓存不一致的情况，缓存的数据也会很快过期，对业务的影响也是可以接受。

Read/Write Through（读穿 / 写穿）策略

Read/Write Through（读穿 / 写穿）策略原则是应用程序只和缓存交互，不再和数据库交互，而是由缓存和数据库交互，相当于更新数据库的操作由缓存自己代理了。

1、Read Through 策略

先查询缓存中数据是否存在，如果存在则直接返回，如果不存在，则由缓存组件负责从数据库查询数据，并将结果写入到缓存组件，最后缓存组件将数据返回给应用。

2、Write Through 策略

当有数据更新的时候，先查询要写入的数据在缓存中是否已经存在：

• 如果缓存中数据已经存在，则更新缓存中的数据，并且由缓存组件同步更新到数据库中，然后缓存组件告知应用程序更新完成。
• 如果缓存中数据不存在，直接更新数据库，然后返回；

Read Through/Write Through 策略的特点是由缓存节点而非应用程序来和数据库打交道，在我们开发过程中相比 Cache Aside 策略要少见一些，原因是我们经常使用的分布式缓存组件，无论是 Memcached 还是 Redis 都不提供写入数据库和自动加载数据库中的数据的功能。而我们在使用本地缓存的时候可以考虑使用这种策略。

Write Back（写回）策略

Write Back（写回）策略在更新数据的时候，只更新缓存，同时将缓存数据设置为脏的，然后立马返回，并不会更新数据库。对于数据库的更新，会通过批量异步更新的方式进行。

实际上，Write Back（写回）策略也不能应用到我们常用的数据库和缓存的场景中，因为 Redis 并没有异步更新数据库的功能。

Write Back 是计算机体系结构中的设计，比如 CPU 的缓存、操作系统中文件系统的缓存都采用了 Write Back（写回）策略。

Write Back 策略特别适合写多的场景，因为发生写操作的时候， 只需要更新缓存，就立马返回了。比如，写文件的时候，实际上是写入到文件系统的缓存就返回了，并不会写磁盘。

但是带来的问题是，数据不是强一致性的，而且会有数据丢失的风险，因为缓存一般使用内存，而内存是非持久化的，所以一旦缓存机器掉电，就会造成原本缓存中的脏数据丢失。所以你会发现系统在掉电之后，之前写入的文件会有部分丢失，就是因为 Page Cache 还没有来得及刷盘造成的。

保证缓存和数据库数据的一致性

数据库或缓存更新顺序

先数据库，再缓存

举个例子，比如「请求 A 」和「请求 B 」两个请求，同时更新「同一条」数据，则可能出现这样的顺序：

A 请求先将数据库的数据更新为 1，然后在更新缓存前，请求 B 将数据库的数据更新为 2，紧接着也把缓存更新为 2，然后 A 请求更新缓存为 1。

此时，数据库中的数据是 2，而缓存中的数据却是 1，出现了缓存和数据库中的数据不一致的现象。

---

「先更新数据库，再删除缓存」的方案虽然保证了数据库与缓存的数据一致性，但是每次更新数据的时候，缓存的数据都会被删除，这样会对缓存的命中率带来影响。

所以，如果我们的业务对缓存命中率有很高的要求，我们可以采用「更新数据库 + 更新缓存」的方案，因为更新缓存并不会出现缓存未命中的情况。

但是这个方案前面我们也分析过，更新数据库和更新缓存这两个操作是独立的，而我们又没有对操作做任何并发控制，那么当两个线程并发更新它们的话，就会因为写入顺序的不同造成数据的不一致。

所以我们得增加一些手段来解决这个问题，这里提供两种做法：

• 在更新缓存前先加个分布式锁，保证同一时间只运行一个请求更新缓存，就会不会产生并发问题了，当然引入了锁后，对于写入的性能就会带来影响。
• 在更新完缓存时，给缓存加上较短的过期时间，这样即时出现缓存不一致的情况，缓存的数据也会很快过期，对业务还是能接受的。

先缓存，再数据库

依然还是存在并发的问题，分析思路也是一样。

假设「请求 A 」和「请求 B 」两个请求，同时更新「同一条」数据，则可能出现这样的顺序：

****

A 请求先将缓存的数据更新为 1，然后在更新数据库前，B 请求来了， 将缓存的数据更新为 2，紧接着把数据库更新为 2，然后 A 请求将数据库的数据更新为 1。

此时，数据库中的数据是 1，而缓存中的数据却是 2，出现了缓存和数据库中的数据不一致的现象。

所以，无论是「先更新数据库，再更新缓存」，还是「先更新缓存，再更新数据库」，这两个方案都存在并发问题，当两个请求并发更新同一条数据的时候，可能会出现缓存和数据库中的数据不一致的现象。

先更新数据库，还是先删除缓存？

在更新数据时，不更新缓存，而是删除缓存中的数据。然后，到读取数据时，发现缓存中没了数据之后，再从数据库中读取数据，更新到缓存中。Cache Aside 策略，中文是叫旁路缓存策略。

该策略又可以细分为「读策略」和「写策略」。

写策略的步骤：

• 更新数据库中的数据；
• 删除缓存中的数据。

读策略的步骤：

• 如果读取的数据命中了缓存，则直接返回数据；
• 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。

阿旺在想到「写策略」的时候，又陷入更深层次的思考，到底该选择哪种顺序呢？

• 先删除缓存，再更新数据库；
• 先更新数据库，再删除缓存。

先删除缓存，再更新数据库

假设某个用户的年龄是 20，请求 A 要更新用户年龄为 21，所以它会删除缓存中的内容。这时，另一个请求 B 要读取这个用户的年龄，它查询缓存发现未命中后，会从数据库中读取到年龄为 20，并且写入到缓存中，然后请求 A 继续更改数据库，将用户的年龄更新为 21。

最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库的数据不一致。

可以看到，先删除缓存，再更新数据库，在「读 + 写」并发的时候，还是会出现缓存和数据库的数据不一致的问题。

---

针对「先删除缓存，再更新数据库」方案在「读 + 写」并发请求而造成缓存不一致的解决办法是「延迟双删」。

延迟双删实现的伪代码如下：

#删除缓存
redis.delKey(X)
#更新数据库
db.update(X)
#睡眠
Thread.sleep(N)
#再删除缓存
redis.delKey(X)

加了个睡眠时间，主要是为了确保请求 A 在睡眠的时候，请求 B 能够在这这一段时间完成「从数据库读取数据，再把缺失的缓存写入缓存」的操作，然后请求 A 睡眠完，再删除缓存。

所以，请求 A 的睡眠时间就需要大于请求 B 「从数据库读取数据 + 写入缓存」的时间。

先更新数据库，再删除缓存

假如某个用户数据在缓存中不存在，请求 A 读取数据时从数据库中查询到年龄为 20，在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21，并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存中。

最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库数据不一致。

从上面的理论上分析，先更新数据库，再删除缓存也是会出现数据不一致性的问题，但是在实际中，这个问题出现的概率并不高。

因为缓存的写入通常要远远快于数据库的写入，所以在实际中很难出现请求 B 已经更新了数据库并且删除了缓存，请求 A 才更新完缓存的情况。

而一旦请求 A 早于请求 B 删除缓存之前更新了缓存，那么接下来的请求就会因为缓存不命中而从数据库中重新读取数据，所以不会出现这种不一致的情况。

「先更新数据库 + 再删除缓存」=的方案，是可以保证数据一致性的。

还给缓存数据加上了「过期时间」，就算在这期间存在缓存数据不一致，有过期时间来兜底，这样也能达到最终一致。

问题：

说自己明明更新了数据，但是数据要过一段时间才生效。

「先更新数据库， 再删除缓存」其实是两个操作，前面的所有分析都是建立在这两个操作都能同时执行成功，而这次客户投诉的问题就在于，在删除缓存（第二个操作）的时候失败了，导致缓存中的数据是旧值。

好在之前给缓存加上了过期时间，所以才会出现客户说的过一段时间才更新生效的现象，假设如果没有这个过期时间的兜底，那后续的请求读到的就会一直是缓存中的旧数据，这样问题就更大了。

如何保证两个操作都能执行成功？

应用要把数据 X 的值从 1 更新为 2，先成功更新了数据库，然后在 Redis 缓存中删除 X 的缓存，但是这个操作却失败了，这个时候数据库中 X 的新值为 2，Redis 中的 X 的缓存值为 1，出现了数据库和缓存数据不一致的问题。

后续有访问数据 X 的请求，会先在 Redis 中查询，因为缓存并没有 诶删除，所以会缓存命中，但是读到的却是旧值 1。

其实不管是先操作数据库，还是先操作缓存，只要第二个操作失败都会出现数据一致的问题。

解决办法

1. 重试机制。

我们可以引入消息队列，将第二个操作（删除缓存）要操作的数据加入到消息队列，由消费者来操作数据。

• 如果应用删除缓存失败，可以从消息队列中重新读取数据，然后再次删除缓存，这个就是重试机制。当然，如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。
• 如果删除缓存成功，就要把数据从消息队列中移除，避免重复操作，否则就继续重试。

举个例子

2. 订阅 MySQL binlog，再操作缓存

「先更新数据库，再删缓存」的策略的第一步是更新数据库，那么更新数据库成功，就会产生一条变更日志，记录在 binlog 里。

通过订阅 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除，阿里巴巴开源的 Canal 中间件就是基于这个实现的。

Canal 模拟 MySQL 主从复制的交互协议，把自己伪装成一个 MySQL 的从节点，向 MySQL 主节点发送 dump 请求，MySQL 收到请求后，就会开始推送 Binlog 给 Canal，Canal 解析 Binlog 字节流之后，转换为便于读取的结构化数据，供下游程序订阅使用。

下图是 Canal 的工作原理：

所以，如果要想保证「先更新数据库，再删缓存」策略第二个操作能执行成功，我们可以使用「消息队列来重试缓存的删除」，或者「订阅 MySQL binlog 再操作缓存」，这两种方法有一个共同的特点，都是采用异步操作缓存。

为什么是删除缓存，而不是更新缓存呢？

删除一个数据，相比更新一个数据更加轻量级，出问题的概率更小。在实际业务中，缓存的数据可能不是直接来自数据库表，也许来自多张底层数据表的聚合。

• 比如商品详情信息，在底层可能会关联商品表、价格表、库存表等，如果更新了一个价格字段，那么就要更新整个数据库，还要关联的去查询和汇总各个周边业务系统的数据，这个操作会非常耗时。
• 从另外一个角度，不是所有的缓存数据都是频繁访问的，更新后的缓存可能会长时间不被访问，所以说，从计算资源和整体性能的考虑，更新的时候删除缓存，等到下次查询命中再填充缓存，是一个更好的方案。

Redis 实战

Redis 如何实现延迟队列？

延迟队列是指把当前要做的事情，往后推迟一段时间再做。

延迟队列的常见使用场景有以下几种：

• 在淘宝、京东等购物平台上下单，超过一定时间未付款，订单会自动取消；
• 打车的时候，在规定时间没有车主接单，平台会取消你的单并提醒你暂时没有车主接单；
• 点外卖的时候，如果商家在10分钟还没接单，就会自动取消订单；

在 Redis 可以使用有序集合（ZSet）的方式来实现延迟消息队列的，ZSet 有一个 Score 属性可以用来存储延迟执行的时间。

Redis 的大 key 如何处理？

什么是 Redis 大 key？

大 key 并不是指 key 的值很大，而是 key 对应的 value 很大。

一般而言，下面这两种情况被称为大 key：

• String 类型的值大于 10 KB；
• Hash、List、Set、ZSet 类型的元素的个数超过 5000个；

大 key 会造成什么问题？

大 key 会带来以下四种影响：

• 客户端超时阻塞。由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。
• 引发网络阻塞。每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。
• 阻塞工作线程。如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。
• 内存分布不均。集群模型在 slot 分片均匀情况下，会出现数据和查询倾斜情况，部分有大 key 的 Redis 节点占用内存多，QPS 也会比较大。

如何找到大 key ？

1、redis-cli --bigkeys 查找大key

2、使用 SCAN 命令查找大 key

3、使用 RdbTools 工具查找大 key

如何删除大 key？

删除操作的本质是要释放键值对占用的内存空间，不要小瞧内存的释放过程。

删除大 key 这一个动作，这里给出两种方法：

• 分批次删除
• 异步删除（Redis 4.0版本以上）

这样 Redis 会将这个 key 放入到一个异步线程中进行删除，这样不会阻塞主线程。

Redis 管道有什么用？

管道技术（Pipeline）是客户端提供的一种批处理技术，用于一次处理多个 Redis 命令，从而提高整个交互的性能。

使用管道技术可以解决多个命令执行时的网络等待，它是把多个命令整合到一起发送给服务器端处理之后统一返回给客户端，这样就免去了每条命令执行后都要等待的情况，从而有效地提高了程序的执行效率。

要注意的是，管道技术本质上是客户端提供的功能，而非 Redis 服务器端的功能。

Redis 事务支持回滚吗？

Redis 中并没有提供回滚机制，虽然 Redis 提供了 DISCARD 命令，但是这个命令只能用来主动放弃事务执行，把暂存的命令队列清空，起不到回滚的效果。

事务执行过程中，如果命令入队时没报错，而事务提交后，实际执行时报错了，正确的命令依然可以正常执行，所以这可以看出 Redis 并不一定保证原子性（原子性：事务中的命令要不全部成功，要不全部失败）。

如何用 Redis 实现分布式锁的？

分布式锁是用于分布式环境下并发控制的一种机制，用于控制某个资源在同一时刻只能被一个应用所使用。如下图所示

Redis 本身可以被多个客户端共享访问，正好就是一个共享存储系统，可以用来保存分布式锁，而且 Redis 的读写性能高，可以应对高并发的锁操作场景。

Redis 的 SET 命令有个 NX 参数可以实现「key不存在才插入」，所以可以用它来实现分布式锁：setnx(SET if not exists)

由于redis的单线程的，用了命令之后，只能有一个客户端对某一个key设置值，在没有过期或删除key的时候是其他客户端是不能设置这个key的

• 如果 key 不存在，则显示插入成功，可以用来表示加锁成功；
• 如果 key 存在，则会显示插入失败，可以用来表示加锁失败。

基于 Redis 节点实现分布式锁时，对于加锁操作，我们需要满足三个条件。

• 加锁包括了读取锁变量、检查锁变量值和设置锁变量值三个操作，但需要以原子操作的方式完成，所以，我们使用 SET 命令带上 NX 选项来实现加锁；
• 锁变量需要设置过期时间，以免客户端拿到锁后发生异常，导致锁一直无法释放，所以，我们在 SET 命令执行时加上 EX/PX 选项，设置其过期时间；
• 锁变量的值需要能区分来自不同客户端的加锁操作，以免在释放锁时，出现误释放操作，所以，我们使用 SET 命令设置锁变量值时，每个客户端设置的值是一个唯一值，用于标识客户端；

满足这三个条件的分布式命令如下：

SET lock_key unique_value NX PX 10000 

• lock_key 就是 key 键；
• unique_value 是客户端生成的唯一的标识，区分来自不同客户端的锁操作；
• NX 代表只在 lock_key 不存在时，才对 lock_key 进行设置操作；
• PX 10000 表示设置 lock_key 的过期时间为 10s，这是为了避免客户端发生异常而无法释放锁。

而解锁的过程就是将 lock_key 键删除（del lock_key），但不能乱删，要保证执行操作的客户端就是加锁的客户端。所以，解锁的时候，我们要先判断锁的 unique_value 是否为加锁客户端，是的话，才将 lock_key 键删除。

可以看到，解锁是有两个操作，这时就需要 Lua 脚本来保证解锁的原子性，因为 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，保证了锁释放操作的原子性。

// 释放锁时，先比较 unique_value 是否相等，避免锁的误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

使用 SET 命令和 Lua 脚本在 Redis 单节点上完成了分布式锁的加锁和解锁。

基于 Redis 实现分布式锁有什么优缺点？

基于 Redis 实现分布式锁的优点：

1. 性能高效（这是选择缓存实现分布式锁最核心的出发点）。
2. 实现方便。很多研发工程师选择使用 Redis 来实现分布式锁，很大成分上是因为 Redis 提供了 setnx 方法，实现分布式锁很方便。
3. 避免单点故障（因为 Redis 是跨集群部署的，自然就避免了单点故障）。

基于 Redis 实现分布式锁的缺点：

• 超时时间不好设置：如果锁的超时时间设置过长，会影响性能，如果设置的超时时间过短会保护不到共享资源。比如在有些场景中，一个线程 A 获取到了锁之后，由于业务代码执行时间可能比较长，导致超过了锁的超时时间，自动失效，注意 A 线程没执行完，后续线程 B 又意外的持有了锁，意味着可以操作共享资源，那么两个线程之间的共享资源就没办法进行保护了。
  • 那么如何合理设置超时时间呢？ 我们可以基于续约的方式设置超时时间：先给锁设置一个超时时间，然后启动一个守护线程，让守护线程在一段时间后，重新设置这个锁的超时时间。实现方式就是：写一个守护线程，然后去判断锁的情况，当锁快失效的时候，再次进行续约加锁，当主线程执行完成后，销毁续约锁即可，不过这种方式实现起来相对复杂。
• Redis 主从复制模式中的数据是异步复制的，这样导致分布式锁的不可靠性。如果在 Redis 主节点获取到锁后，在没有同步到其他节点时，Redis 主节点宕机了，此时新的 Redis 主节点依然可以获取锁，所以多个应用服务就可以同时获取到锁。

持久化篇目

AOF 持久化是怎么实现的？

AOF日志

三种写回策略

AOF重写机制

AOF后台重写

总结

RDB 快照是怎么实现的？

快照怎么用？

执行快照时，数据能被修改吗？

RDB 和 AOF 合体

Redis 大 Key 对持久化有什么影响？

大 Key 对 AOF 日志的影响

大 Key 对 AOF 重写和 RDB 的影响

高可用篇目

在Redis中提供的集群方案总共有三种：主从复制、哨兵模式、Redis分片集群。

主从复制流程

主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。

1. 第一次同步

比如，现在有服务器 A 和 服务器 B，我们在服务器 B 上执行下面这条命令：

# 服务器 B 执行这条命令
replicaof <服务器 A 的 IP 地址> <服务器 A 的 Redis 端口号>

接着，服务器 B 就会变成服务器 A 的「从服务器」，然后与主服务器进行第一次同步。

主从服务器间的第一次同步的过程可分为三个阶段：

• 第一阶段是建立链接、协商同步；
• 第二阶段是主服务器同步数据给从服务器；
• 第三阶段是主服务器发送新写操作命令给从服务器。

第一阶段：建立链接、协商同步

执行了 replicaof 命令后，从服务器就会给主服务器发送 psync 命令，表示要进行数据同步。

psync 命令包含两个参数，分别是主服务器的 runID 和复制进度 offset。

• runID，每个 Redis 服务器在启动时都会自动生产一个随机的 ID 来唯一标识自己。当从服务器和主服务器第一次同步时，因为不知道主服务器的 run ID，所以将其设置为 "?"。
• offset，表示复制的进度，第一次同步时，其值为 -1。

主服务器收到 psync 命令后，会用 FULLRESYNC 作为响应命令返回给对方。

并且这个响应命令会带上两个参数：主服务器的 runID 和主服务器目前的复制进度 offset。从服务器收到响应后，会记录这两个值。

FULLRESYNC 响应命令的意图是采用全量复制的方式，也就是主服务器会把所有的数据都同步给从服务器。

第二阶段：主服务器同步数据给从服务器

主服务器会执行 bgsave 命令来生成 RDB 文件，然后把文件发送给从服务器。

从服务器收到 RDB 文件后，会先清空当前的数据，然后载入 RDB 文件。

主服务器生成 RDB 这个过程是不会阻塞主线程的，因为 bgsave 命令是产生了一个子进程来做生成 RDB 文件的工作，是异步工作的，这样 Redis 依然可以正常处理命令。

但是，这期间的写操作命令并没有记录到刚刚生成的 RDB 文件中，这时主从服务器间的数据就不一致了。

那么为了保证主从服务器的数据一致性，主服务器在下面这三个时间间隙中将收到的写操作命令，写入到 replication buffer 缓冲区里：

• 主服务器生成 RDB 文件期间；
• 主服务器发送 RDB 文件给从服务器期间；
• 「从服务器」加载 RDB 文件期间；

第三阶段：主服务器发送新写操作命令给从服务器

在主服务器生成的 RDB 文件发送完，从服务器收到 RDB 文件后，丢弃所有旧数据，将 RDB 数据载入到内存。完成 RDB 的载入后，会回复一个确认消息给主服务器。

接着，主服务器将 replication buffer 缓冲区里所记录的写操作命令发送给从服务器，从服务器执行来自主服务器 replication buffer 缓冲区里发来的命令，这时主从服务器的数据就一致了。

2. 基于长连接的命令传播

主从服务器在完成第一次同步后，双方之间就会维护一个 TCP 连接。

后续主服务器可以通过这个连接继续将写操作命令传播给从服务器，然后从服务器执行该命令，使得与主服务器的数据库状态相同。

这个连接是长连接的，目的是避免频繁的 TCP 连接和断开带来的性能开销。

上面的这个过程被称为基于长连接的命令传播，通过这种方式来保证第一次同步后的主从服务器的数据一致性。

分摊主服务器的压力

主从服务器在第一次数据同步的过程中，主服务器会做两件耗时的操作：生成 RDB 文件和传输 RDB 文件。

主服务器是可以有多个从服务器的，如果从服务器数量非常多，而且都与主服务器进行全量同步的话，就会带来两个问题：

• 由于是通过 bgsave 命令来生成 RDB 文件的，那么主服务器就会忙于使用 fork() 创建子进程，如果主服务器的内存数据非大，在执行 fork() 函数时是会阻塞主线程的，从而使得 Redis 无法正常处理请求；
• 传输 RDB 文件会占用主服务器的网络带宽，会对主服务器响应命令请求产生影响。

在「从服务器」上执行下面这条命令，使其作为目标服务器的从服务器：

replicaof <目标服务器的IP> 6379

此时如果目标服务器本身也是「从服务器」，那么该目标服务器就会成为「经理」的角色，不仅可以接受主服务器同步的数据，也会把数据同步给自己旗下的从服务器，从而减轻主服务器的负担。

3. 增量复制

如果主从服务器在命令同步时出现了网络断开又恢复的情况，

从 Redis 2.8 开始，网络断开又恢复后，从主从服务器会采用增量复制的方式继续同步，也就是只会把网络断开期间主服务器接收到的写操作命令，同步给从服务器。

网络恢复后的增量复制过程如下图：

主要有三个步骤：

• 从服务器在恢复网络后，会发送 psync 命令给主服务器，此时的 psync 命令里的 offset 参数不是 -1；
• 主服务器收到该命令后，然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据；
• 然后主服务将主从服务器断线期间，所执行的写命令发送给从服务器，然后从服务器执行这些命令。

主服务器怎么知道要将哪些增量数据发送给从服务器呢？

答案藏在这两个东西里：

• repl_backlog_buffer，是一个「环形」缓冲区，用于主从服务器断连后，从中找到差异的数据；
• replication offset，标记上面那个缓冲区的同步进度，主从服务器都有各自的偏移量，主服务器使用 master_repl_offset 来记录自己「写」到的位置，从服务器使用 slave_repl_offset 来记录自己「读」到的位置。

在主服务器进行命令传播时，不仅会将写命令发送给从服务器，还会将写命令写入到 repl_backlog_buffer 缓冲区里，因此 这个缓冲区里会保存着最近传播的写命令。

网络断开后，当从服务器重新连上主服务器时，从服务器会通过 psync 命令将自己的复制偏移量 slave_repl_offset 发送给主服务器，主服务器根据自己的 master_repl_offset 和 slave_repl_offset 之间的差距，然后来决定对从服务器执行哪种同步操作：

• 如果判断出从服务器要读取的数据还在 repl_backlog_buffer 缓冲区里，那么主服务器将采用增量同步的方式；
• 如果判断出从服务器要读取的数据已经不存在 repl_backlog_buffer 缓冲区里，那么主服务器将采用全量同步的方式。

当主服务器在 repl_backlog_buffer 中找到主从服务器差异（增量）的数据后，就会将增量的数据写入到 replication buffer 缓冲区，这个缓冲区我们前面也提到过，它是缓存将要传播给从服务器的命令。

repl_backlog_buffer 缓行缓冲区的默认大小是 1M，并且由于它是一个环形缓冲区，所以当缓冲区写满后，主服务器继续写入的话，就会覆盖之前的数据。因此，当主服务器的写入速度远超于从服务器的读取速度，缓冲区的数据一下就会被覆盖。

那么在网络恢复时，如果从服务器想读的数据已经被覆盖了，主服务器就会采用全量同步，这个方式比增量同步的性能损耗要大很多。

因此，为了避免在网络恢复时，主服务器频繁地使用全量同步的方式，我们应该调整下 repl_backlog_buffer 缓冲区大小，尽可能的大一些，减少出现从服务器要读取的数据被覆盖的概率，从而使得主服务器采用增量同步的方式。

repl_backlog_buffer 最小的大小可以根据这面这个公式估算。

• second 为从服务器断线后重新连接上主服务器所需的平均时间(以秒计算)。
• write_size_per_second 则是主服务器平均每秒产生的写命令数据量大小。

举个例子，如果主服务器平均每秒产生 1 MB 的写命令，而从服务器断线之后平均要 5 秒才能重新连接主服务器。

那么 repl_backlog_buffer 大小就不能低于 5 MB，否则新写地命令就会覆盖旧数据了。

当然，为了应对一些突发的情况，可以将 repl_backlog_buffer 的大小设置为此基础上的 2 倍，也就是 10 MB。

关于 repl_backlog_buffer 大小修改的方法，只需要修改配置文件里下面这个参数项的值就可以。

repl-backlog-size 1mb

总结

主从复制共有三种模式：全量复制、基于长连接的命令传播、增量复制。

1. 主从服务器第一次同步的时候，就是采用全量复制。
2. 第一次同步完成后，主从服务器都会维护着一个长连接，主服务器在接收到写操作命令后，就会通过这个连接将写命令传播给从服务器，来保证主从服务器的数据一致性。
3. 如果遇到网络断开，增量复制就可以上场了，不过这个还跟 repl_backlog_size 这个大小有关系。

如果它配置的过小，主从服务器网络恢复时，可能发生「从服务器」想读的数据已经被覆盖了，那么这时就会导致主服务器采用全量复制的方式。所以为了避免这种情况的频繁发生，要调大这个参数的值，以降低主从服务器断开后全量同步的概率。

主从同步分为了两个阶段，一个是全量同步，一个是 增量同步

全量同步是指从节点第一次与主节点建立连接的时候使用全量同步，流程是 这样的：

第一：从节点请求主节点同步数据，其中从节点会携带自己的replication id 和offset偏移量。

第二：主节点判断是否是第一次请求，主要判断的依据就是，主节点与从节 点是否是同一个replication id，如果不是，就说明是第一次同步，那主节点 就会把自己的replication id和offset发送给从节点，让从节点与主节点的信息 保持一致。

第三：在同时主节点会执行bgsave，生成rdb文件后，发送给从节点去执 行，从节点先把自己的数据清空，然后执行主节点发送过来的rdb文件，这 样就保持了一致

当然，如果在rdb生成执行期间，依然有请求到了主节点，而主节点会以命 令的方式记录到缓冲区，缓冲区是一个日志文件，最后把这个日志文件发送 给从节点，这样就能保证主节点与从节点完全一致了，后期再同步数据的时 候，都是依赖于这个日志文件，这个就是全量同步

增量同步指的是，当从节点服务重启之后，数据就不一致了，所以这个时 候，从节点会请求主节点同步数据，主节点还是判断不是第一次请求，不是 第一次就获取从节点的offset值，然后主节点从命令日志中获取offset值之后 的数据，发送给从节点进行数据同步

面试题

Redis主从节点时长连接还是短连接？

长连接

怎么判断 Redis 某个节点是否正常工作？

Redis 判断节点是否正常工作，基本都是通过互相的 ping-pong 心态检测机制，如果有一半以上的节点去 ping 一个节点的时候没有 pong 回应，集群就会认为这个节点挂掉了，会断开与这个节点的连接。

Redis 主从节点发送的心态间隔是不一样的，而且作用也有一点区别：

• Redis 主节点默认每隔 10 秒对从节点发送 ping 命令，判断从节点的存活性和连接状态，可通过参数repl-ping-slave-period控制发送频率。
• Redis 从节点每隔 1 秒发送 replconf ack{offset} 命令，给主节点上报自身当前的复制偏移量，目的是为了：
  • 实时监测主从节点网络状态；
  • 上报自身复制偏移量， 检查复制数据是否丢失， 如果从节点数据丢失， 再从主节点的复制缓冲区中拉取丢失数据。

主从复制架构中，过期key如何处理？

主节点处理了一个key或者通过淘汰算法淘汰了一个key，这个时间主节点模拟一条del命令发送给从节点，从节点收到该命令后，就进行删除key的操作。

是同步复制还是异步复制？

Redis 主节点每次收到写命令之后，先写到内部的缓冲区，然后异步发送给从节点。

主从复制中两个 Buffer(replication buffer 、repl backlog buffer)有什么区别？

replication buffer 、repl backlog buffer 区别如下：

• 出现的阶段不一样：
  • repl backlog buffer 是在增量复制阶段出现，一个主节点只分配一个 repl backlog buffer；
  • replication buffer 是在全量复制阶段和增量复制阶段都会出现，主节点会给每个新连接的从节点，分配一个 replication buffer；
• 这两个 Buffer 都有大小限制的，当缓冲区满了之后，发生的事情不一样：
  • 当 repl backlog buffer 满了，因为是环形结构，会直接覆盖起始位置数据;
  • 当 replication buffer 满了，会导致连接断开，删除缓存，从节点重新连接，重新开始全量复制。

如何应对主从数据不一致？

为什么会出现主从数据不一致？

主从数据不一致，就是指客户端从从节点中读取到的值和主节点中的最新值并不一致。

之所以会出现主从数据不一致的现象，是因为主从节点间的命令复制是异步进行的，无法实现强一致性保证（主从数据时刻保持一致）。

具体来说，在主从节点命令传播阶段，主节点收到新的写命令后，会发送给从节点。但是，主节点并不会等到从节点实际执行完命令后，再把结果返回给客户端，而是主节点自己在本地执行完命令后，就会向客户端返回结果了。如果从节点还没有执行主节点同步过来的命令，主从节点间的数据就不一致了。

如何如何应对主从数据不一致？

第一种方法，尽量保证主从节点间的网络连接状况良好，避免主从节点在不同的机房。

第二种方法，可以开发一个外部程序来监控主从节点间的复制进度。具体做法：

• Redis 的 INFO replication 命令可以查看主节点接收写命令的进度信息（master_repl_offset）和从节点复制写命令的进度信息（slave_repl_offset），所以，我们就可以开发一个监控程序，先用 INFO replication 命令查到主、从节点的进度，然后，我们用 master_repl_offset 减去 slave_repl_offset，这样就能得到从节点和主节点间的复制进度差值了。
• 如果某个从节点的进度差值大于我们预设的阈值，可以让客户端不再和这个从节点连接进行数据读取，这样可以减少读到不一致数据的情况。不过，为了避免出现客户端和所有从节点都不能连接的情况，我们需要把复制进度差值的阈值设置得大一些。

主从切换如何减少数据丢失？

主从切换过程中，产生数据丢失的情况有两种：

• 异步复制同步丢失
• 集群产生脑裂数据丢失

我们不可能保证数据完全不丢失，只能做到使得尽量少的数据丢失。

1异步复制同步丢失

对于 Redis 主节点与从节点之间的数据复制，是异步复制的，当客户端发送写请求给主节点的时候，客户端会返回 ok，接着主节点将写请求异步同步给各个从节点，但是如果此时主节点还没来得及同步给从节点时发生了断电，那么主节点内存中的数据会丢失。

减少异步复制的数据丢失的方案

Redis 配置里有一个参数 min-slaves-max-lag，表示一旦所有的从节点数据复制和同步的延迟都超过了 min-slaves-max-lag 定义的值，那么主节点就会拒绝接收任何请求。

假设将 min-slaves-max-lag 配置为 10s 后，根据目前 master->slave 的复制速度，如果数据同步完成所需要时间超过10s，就会认为 master 未来宕机后损失的数据会很多，master 就拒绝写入新请求。这样就能将 master 和 slave 数据差控制在10s内，即使 master 宕机也只是这未复制的 10s 数据。

那么对于客户端，当客户端发现 master 不可写后，我们可以采取降级措施，将数据暂时写入本地缓存和磁盘中，在一段时间（等 master 恢复正常）后重新写入 master 来保证数据不丢失，也可以将数据写入 kafka 消息队列，等 master 恢复正常，再隔一段时间去消费 kafka 中的数据，让将数据重新写入 master 。

2集群产生脑裂数据丢失

集群的脑裂现象，这就好比一个人有两个大脑，那么到底受谁控制呢？

在 Redis 主从架构中，部署方式一般是「一主多从」，主节点提供写操作，从节点提供读操作。

如果主节点的网络突然发生了问题，它与所有的从节点都失联了，但是此时的主节点和客户端的网络是正常的，这个客户端并不知道 Redis 内部已经出现了问题，还在照样的向这个失联的主节点写数据（过程A），此时这些数据被主节点缓存到了缓冲区里，因为主从节点之间的网络问题，这些数据都是无法同步给从节点的。

这时，哨兵也发现主节点失联了，它就认为主节点挂了（但实际上主节点正常运行，只是网络出问题了），于是哨兵就会在从节点中选举出一个 leeder 作为主节点，这时集群就有两个主节点了 —— 脑裂出现了。

这时候网络突然好了，哨兵因为之前已经选举出一个新主节点了，它就会把旧主节点降级为从节点（A），然后从节点（A）会向新主节点请求数据同步，因为第一次同步是全量同步的方式，此时的从节点（A）会清空掉自己本地的数据，然后再做全量同步。所以，之前客户端在过程 A 写入的数据就会丢失了，也就是集群产生脑裂数据丢失的问题。

总结一句话就是：由于网络问题，集群节点之间失去联系。主从数据不同步；重新平衡选举，产生两个主服务。等网络恢复，旧主节点会降级为从节点，再与新主节点进行同步复制的时候，由于会从节点会清空自己的缓冲区，所以导致之前客户端写入的数据丢失了。

减少脑裂的数据丢的方案

当主节点发现「从节点下线的数量太多」，或者「网络延迟太大」的时候，那么主节点会禁止写操作，直接把错误返回给客户端。

在 Redis 的配置文件中有两个参数我们可以设置：

• min-slaves-to-write x，主节点必须要有至少 x 个从节点连接，如果小于这个数，主节点会禁止写数据。
• min-slaves-max-lag x，主从数据复制和同步的延迟不能超过 x 秒，如果主从同步的延迟超过 x 秒，主节点会禁止写数据。

我们可以把 min-slaves-to-write 和 min-slaves-max-lag 这两个配置项搭配起来使用，分别给它们设置一定的阈值，假设为 N 和 T。

这两个配置项组合后的要求是，主节点连接的从节点中至少有 N 个从节点，「并且」主节点进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主节点就不会再接收客户端的写请求了。

即使原主节点是假故障，它在假故障期间也无法响应哨兵心跳，也不能和从节点进行同步，自然也就无法和从节点进行 ACK 确认了。这样一来，min-slaves-to-write 和 min-slaves-max-lag 的组合要求就无法得到满足，原主节点就会被限制接收客户端写请求，客户端也就不能在原主节点中写入新数据了。

等到新主节点上线时，就只有新主节点能接收和处理客户端请求，此时，新写的数据会被直接写到新主节点中。而原主节点会被哨兵降为从节点，即使它的数据被清空了，也不会有新数据丢失。

主从如何做到故障自动切换？

主节点挂了 ，从节点是无法自动升级为主节点的，需要人工处理，在此期间 Redis 无法对外提供写操作。

此时，Redis 哨兵机制就登场了，哨兵在发现主节点出现故障时，由哨兵自动完成故障发现和故障转移，并通知给应用方，从而实现高可用性。

为什么要有哨兵？

为什么要有哨兵机制？

Redis 在 2.8 版本以后提供的哨兵（*Sentinel*）机制，它的作用是实现主从节点故障转移。它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。

哨兵机制是如何工作的？

哨兵其实是一个运行在特殊模式下的 Redis 进程，所以它也是一个节点。

哨兵节点主要负责三件事情：监控、选主、通知。

我们重点要学习这三件事情：

• 哨兵节点是如何监控节点的？又是如何判断主节点是否真的故障了？
• 根据什么规则选择一个从节点切换为主节点？
• 怎么把新主节点的相关信息通知给从节点和客户端呢？

如何判断主节点真的故障了？

哨兵会每隔 1 秒给所有主从节点发送 PING 命令，当主从节点收到 PING 命令后，会发送一个响应命令给哨兵，这样就可以判断它们是否在正常运行。

如果主节点或者从节点没有在规定的时间内响应哨兵的 PING 命令，哨兵就会将它们标记为「主观下线」。这个「规定的时间」是配置项 down-after-milliseconds 参数设定的，单位是毫秒。

主观下线？难道还有客观下线？

为了减少误判的情况，用多个节点部署成哨兵集群（最少需要三台机器来部署哨兵集群），通过多个哨兵节点一起判断，就可以就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况。

当一个哨兵判断主节点为「主观下线」后，就会向其他哨兵发起命令，其他哨兵收到这个命令后，就会根据自身和主节点的网络状况，做出赞成投票或者拒绝投票的响应。

当这个哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值后，这时主节点就会被该哨兵标记为「客观下线」。

PS：quorum 的值一般设置为哨兵个数的二分之一加 1，例如 3 个哨兵就设置 2。

由哪个哨兵进行主从故障转移？

哨兵是以哨兵集群的方式存在的。

需要在哨兵集群中选出一个 leader，让 leader 来执行主从切换。

谁来作为候选者呢？

哪个哨兵节点判断主节点为「客观下线」，这个哨兵节点就是候选者，所谓的候选者就是想当 Leader 的哨兵。

候选者如何选举成为 Leader？

候选者会向其他哨兵发送命令，表明希望成为 Leader 来执行主从切换，并让所有其他哨兵对它进行投票。

每个哨兵只有一次投票机会，如果用完后就不能参与投票了，可以投给自己或投给别人，但是只有候选者才能把票投给自己。

在投票过程中，任何一个「候选者」，要满足两个条件：

• 第一，拿到半数以上的赞成票；
• 第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

举个例子，假设哨兵节点有 3 个，quorum 设置为 2，那么任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票，就可以选举成功了。如果没有满足条件，就需要重新进行选举。

为什么哨兵节点至少要有 3 个？

如果哨兵集群中只有 2 个哨兵节点，此时如果一个哨兵想要成功成为 Leader，必须获得 2 票，而不是 1 票。

所以，如果哨兵集群中有个哨兵挂掉了，那么就只剩一个哨兵了，如果这个哨兵想要成为 Leader，这时票数就没办法达到 2 票，就无法成功成为 Leader，这时是无法进行主从节点切换的。

因此，通常我们至少会配置 3 个哨兵节点。这时，如果哨兵集群中有个哨兵挂掉了，那么还剩下两个哨兵，如果这个哨兵想要成为 Leader，这时还是有机会达到 2 票的，所以还是可以选举成功的，不会导致无法进行主从节点切换。

当然，你要问，如果 3 个哨兵节点，挂了 2 个怎么办？这个时候得人为介入了，或者增加多一点哨兵节点。

---

Redis 1 主 4 从，5 个哨兵，quorum 设置为 3，如果 2 个哨兵故障，当主节点宕机时，哨兵能否判断主节点“客观下线”？主从能否自动切换？

• 哨兵集群可以判定主节点“客观下线”。哨兵集群还剩下 3 个哨兵，当一个哨兵判断主节点“主观下线”后，询问另外 2 个哨兵后，有可能能拿到 3 张赞同票，这时就达到了 quorum 的值，因此，哨兵集群可以判定主节点为“客观下线”。
• 哨兵集群可以完成主从切换。当有个哨兵标记主节点为「客观下线」后，就会进行选举 Leader 的过程，因为此时哨兵集群还剩下 3 个哨兵，那么还是可以拿到半数以上（5/2+1=3）的票，而且也达到了 quorum 值，满足了选举 Leader 的两个条件，所以就能选举成功，因此哨兵集群可以完成主从切换。

如果 quorum 设置为 2，并且如果有 3 个哨兵故障的话。此时哨兵集群还是可以判定主节点为“客观下线”，但是哨兵不能完成主从切换了，大家可以自己推演下。5/2+1=3，2<3,不能进行主从切换

如果 quorum 设置为 3，并且如果有 3 个哨兵故障的话，哨兵集群即不能判定主节点为“客观下线”，也不能完成主从切换了。

可以看到，quorum 为 2 的时候，并且如果有 3 个哨兵故障的话，虽然可以判定主节点为“客观下线”，但是不能完成主从切换，这样感觉「判定主节点为客观下线」这件事情白做了一样，既然这样，还不如不要做，quorum 为 3 的时候，就可以避免这种无用功。

所以，quorum 的值建议设置为哨兵个数的二分之一加 1，例如 3 个哨兵就设置 2，5 个哨兵设置为 3，而且哨兵节点的数量应该是奇数。

主从故障转移的过程是怎样的？

主从故障转移操作包含以下四个步骤：

• 第一步：在已下线主节点（旧主节点）属下的所有「从节点」里面，挑选出一个从节点，并将其转换为主节点。
• 第二步：让已下线主节点属下的所有「从节点」修改复制目标，修改为复制「新主节点」；
• 第三步：将新主节点的 IP 地址和信息，通过「发布者/订阅者机制」通知给客户端；
• 第四步：继续监视旧主节点，当这个旧主节点重新上线时，将它设置为新主节点的从节点；

步骤一：选出新主节点

首先要把网络状态不好的从节点给过滤掉；

过滤掉已经离线的从节点。

向这个「从节点」发送 SLAVEOF no one 命令，将这个「从节点」转换为「主节点」
Redis 有个叫 down-after-milliseconds * 10 配置项，其 down-after-milliseconds 是主从节点断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从节点的网络状况不好，不适合作为新主节点。

第一轮考察：优先级最高的从节点胜出

Redis 有个叫 slave-priority 配置项，可以给从节点设置优先级。
可以根据服务器性能配置来设置从节点的优先级。
比如，如果「A 从节点」的物理内存是所有从节点中最大的，那么我们可以把「A 从节点」的优先级设置成最高。这样当哨兵进行第一轮考虑的时候，优先级最高的 A 从节点就会优先胜出，于是就会成为新主节点。

第二轮考察：复制进度最靠前的从节点胜出

如果在第一轮考察中，发现优先级最高的从节点有两个，那么就会进行第二轮考察，比较两个从节点哪个复制进度。
什么是复制进度？主从架构中，主节点会将写操作同步给从节点，在这个过程中，主节点会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置（如下图中的「主服务器已经写入的数据」的位置），而从节点会用 slave_repl_offset 这个值记录当前的复制进度（如下图中的「从服务器要读的位置」的位置）。

如果某个从节点的 slave_repl_offset 最接近 master_repl_offset，说明它的复制进度是最靠前的，于是就可以将它选为新主节点。

第三轮考察：ID 号小的从节点胜出

如果第二轮考察中，发现有两个从节点优先级和复制进度是一样的，那么就会进行第三轮考察，比较两个从节点的 ID 号，ID 号小的从节点胜出。
什么是 ID 号？每个从节点都有一个编号，这个编号就是 ID 号，是用来唯一标识从节点的。

步骤二：将从节点指向新主节点

让已下线主节点属下的所有「从节点」指向「新主节点」，可以通过哨兵 leader 向「从节点」发送 SLAVEOF 命令来实现。

步骤三：通知客户的主节点已更换

每个哨兵节点提供发布者/订阅者机制，客户端可以从哨兵订阅消息。

客户端和哨兵建立连接后，客户端会订阅哨兵提供的频道。主从切换完成后，哨兵就会向 +switch-master 频道发布新主节点的 IP 地址和端口的消息，这个时候客户端就可以收到这条信息，然后用这里面的新主节点的 IP 地址和端口进行通信。

步骤四：将旧主节点变为从节点

继续监视旧主节点，当旧主节点重新上线时，哨兵集群就会向它发送 SLAVEOF 命令，让它成为新主节点的从节点。

哨兵集群是如何组成的？

在配置哨兵的信息时，设置主节点名字、主节点的 IP 地址和端口号以及 quorum 值。

sentinel monitor <master-name> <ip> <redis-port> <quorum> 

哨兵节点之间是通过 Redis 的发布者/订阅者机制来相互发现的。

在主从集群中，主节点上有一个名为__sentinel__:hello的频道，不同哨兵就是通过它来相互发现，实现互相通信的。

在下图中，哨兵 A 把自己的 IP 地址和端口的信息发布到__sentinel__:hello 频道上，哨兵 B 和 C 订阅了该频道。那么此时，哨兵 B 和 C 就可以从这个频道直接获取哨兵 A 的 IP 地址和端口号。然后，哨兵 B、C 可以和哨兵 A 建立网络连接。

通过这个方式，哨兵 B 和 C 也可以建立网络连接，这样一来，哨兵集群就形成了。

哨兵集群如何知道「从节点」的信息

主节点知道所有「从节点」的信息，所以哨兵会每 10 秒一次的频率向主节点发送 INFO 命令来获取所有「从节点」的信息。

哨兵 B 给主节点发送 INFO 命令，主节点接受到这个命令后，就会把从节点列表返回给哨兵。接着，哨兵就可以根据从节点列表中的连接信息，和每个从节点建立连接，并在这个连接上持续地对从节点进行监控。哨兵 A 和 C 可以通过相同的方法和从节点建立连接。

• 通过 Redis 的发布者/订阅者机制，哨兵之间可以相互感知，然后组成集群，
• 同哨兵又通过 INFO 命令，在主节点里获得了所有从节点连接信息，于是就能和从节点建立连接，并进行监控。

情景篇

数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的数据都是热点数据 ?

可以使用 allkeys-lru （挑选最近最少使用的数据淘汰）淘汰策略，那留下来的都是经常访问的热点数据

怎么保证Redis的高并发高可用

首先可以搭建主从集群，再加上使用redis中的哨兵模式，

哨兵模式 可以实现主从集群的自动故障恢复，里面就包含了对主从服务的监控、自动 故障恢复、通知；如果master故障，Sentinel会将一个slave提升为master。 当故障实例恢复后也以新的master为主；同时Sentinel也充当Redis客户端的 服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户 端，

所以一般项目都会采用哨兵的模式来保证redis的高并发高可用

你们使用redis是单点还是集群，哪种集群

我们当时使用的是主从（1主1从）加哨兵。一般单节点不超 过10G内存，如果Redis内存不足则可以给不同服务分配独立的Redis主从节 点。尽量不做分片集群。因为集群维护起来比较麻烦，并且集群之间的心跳 检测和数据通信会消耗大量的网络带宽，也没有办法使用lua脚本和事务

计算机基础

网络分层模型

OSI 七层模型

TCP/IP 四层模型 是目前被广泛采用的一种模型,可以将 TCP / IP 模型看作是 OSI 七层模型的精简版本，由以下 4 层组成：

• 应用层

应用层只需要专注于为用户提供应用功能，比如 HTTP、FTP、Telnet、DNS、SMTP等。

TCP 相比 UDP 多了很多特性，比如流量控制、超时重传、拥塞控制等，这些都是为了保证数据包能可靠地传输给对方。
UDP 相对来说就很简单，简单到只负责发送数据包，不保证数据包是否能抵达对方，但它实时性相对更好，传输效率也高。
  应用需要传输的数据可能会非常大，如果直接传输就不好控制，因此当传输层的数据包大小超过 MSS（TCP 最大报文段长度） ，就要将数据包分块，这样即使中途有一个分块丢失或损坏了，只需要重新发送这一个分块，而不用重新发送整个数据包。在 TCP 协议中，我们把每个分块称为一个 TCP 段（TCP Segment）。
  当设备作为接收方时，传输层则要负责把数据包传给应用，但是一台设备上可能会有很多应用在接收或者传输数据，因此需要用一个编号将应用区分开来，这个编号就是端口。

• 传输层

在传输层会有两个传输协议，分别是 TCP 和 UDP。

网络层最常使用的是 IP 协议（Internet Protocol），IP 协议会将传输层的报文作为数据部分，再加上 IP 包头组装成 IP 报文，如果 IP 报文大小超过 MTU（以太网中一般为 1500 字节）就会再次进行分片，得到一个即将发送到网络的 IP 报文。

• 网络层

IP 协议寻址能力、路由。

所以，IP 协议的寻址作用是告诉我们去往下一个目的地该朝哪个方向走，路由则是根据「下一个目的地」选择路径。寻址更像在导航，路由更像在操作方向盘。

• 网络接口层

生成了 IP 头部之后，接下来要交给网络接口层（Link Layer）在 IP 头部的前面加上 MAC 头部，并封装成数据帧（Data frame）发送到网络上。

在以太网进行通讯要用到 MAC 地址，MAC 头部是以太网使用的头部，它包含了接收方和发送方的 MAC 地址等信息，我们可以通过 ARP 协议获取对方的 MAC 地址。

每一层的封装格式：

网络接口层的传输单位是帧（frame），IP 层的传输单位是包（packet），TCP 层的传输单位是段（segment），HTTP 的传输单位则是消息或报文（message）。但这些名词并没有什么本质的区分，可以统称为数据包。

---

需要注意，不能将 TCP/IP 四层模型 和 OSI 七层模型完全精确地匹配起来，不过可以简单将两者对应起来，如下图所示：

TCP/IP 四层模型

---

常见网络协议

应用层常见协议

应用层常见协议 - **HTTP（Hypertext Transfer Protocol，超文本传输协议）**：基于 TCP 协议，是一种用于传输超文本和多媒体内容的协议，主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的。 - **SMTP（Simple Mail Transfer Protocol，简单邮件发送协议）**：基于 TCP 协议，是一种用于发送电子邮件的协议。注意 ⚠️：SMTP 协议只负责邮件的发送，而不是接收。要从邮件服务器接收邮件，需要使用 POP3 或 IMAP 协议。 - **POP3/IMAP（邮件接收协议）**：基于 TCP 协议，两者都是负责邮件接收的协议。IMAP 协议是比 POP3 更新的协议，它在功能和性能上都更加强大。IMAP 支持邮件搜索、标记、分类、归档等高级功能，而且可以在多个设备之间同步邮件状态。几乎所有现代电子邮件客户端和服务器都支持 IMAP。 - **FTP（File Transfer Protocol，文件传输协议）** : 基于 TCP 协议，是一种用于在计算机之间传输文件的协议，可以屏蔽操作系统和文件存储方式。注意 ⚠️：FTP 是一种不安全的协议，因为它在传输过程中不会对数据进行加密。建议在传输敏感数据时使用更安全的协议，如 SFTP。 - **Telnet（远程登陆协议）**：基于 TCP 协议，用于通过一个终端登陆到其他服务器。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用 Telnet，而是使用一种称为 SSH 的非常安全的网络传输协议的主要原因。 - **SSH（Secure Shell Protocol，安全的网络传输协议）**：基于 TCP 协议，通过加密和认证机制实现安全的访问和文件传输等业务 - **RTP（Real-time Transport Protocol，实时传输协议）**：通常基于 UDP 协议，但也支持 TCP 协议。它提供了端到端的实时传输数据的功能，但不包含资源预留存、不保证实时传输质量，这些功能由 WebRTC 实现。 - **DNS（Domain Name System，域名管理系统）**: 基于 UDP 协议，用于解决域名和 IP 地址的映射问题。

传输层常见协议

• TCP（Transmission Control Protocol，传输控制协议 ）：提供 面向连接 的，可靠 的数据传输服务。
• UDP（User Datagram Protocol，用户数据协议）：提供 无连接 的，尽最大努力 的数据传输服务（不保证数据传输的可靠性），简单高效。

网络层常见协议

IP（Internet Protocol，网际协议）：TCP/IP 协议中最重要的协议之一，属于网络层的协议，主要作用是定义数据包的格式、对数据包进行路由和寻址，以便它们可以跨网络传播并到达正确的目的地。目前 IP 协议主要分为两种，一种是过去的 IPv4，另一种是较新的 IPv6，目前这两种协议都在使用，但后者已经被提议来取代前者。

• ARP（Address Resolution Protocol，地址解析协议）：ARP 协议解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。
• ICMP（Internet Control Message Protocol，互联网控制报文协议）：一种用于传输网络状态和错误消息的协议，常用于网络诊断和故障排除。例如，Ping 工具就使用了 ICMP 协议来测试网络连通性。
• NAT（Network Address Translation，网络地址转换协议）：NAT 协议的应用场景如同它的名称——网络地址转换，应用于内部网到外部网的地址转换过程中。具体地说，在一个小的子网（局域网，LAN）内，各主机使用的是同一个 LAN 下的 IP 地址，但在该 LAN 以外，在广域网（WAN）中，需要一个统一的 IP 地址来标识该 LAN 在整个 Internet 上的位置。
• OSPF（Open Shortest Path First，开放式最短路径优先））：一种内部网关协议（Interior Gateway Protocol，IGP），也是广泛使用的一种动态路由协议，基于链路状态算法，考虑了链路的带宽、延迟等因素来选择最佳路径。
• RIP(Routing Information Protocol，路由信息协议）：一种内部网关协议（Interior Gateway Protocol，IGP），也是一种动态路由协议，基于距离向量算法，使用固定的跳数作为度量标准，选择跳数最少的路径作为最佳路径。
• BGP（Border Gateway Protocol，边界网关协议）：一种用来在路由选择域之间交换网络层可达性信息（Network Layer Reachability Information，NLRI）的路由选择协议，具有高度的灵活性和可扩展性。

---

HTTP

Hyper Text Transfer Protocol，超文本传输协议，规定了浏览器和服务器之间数据传输的规则。

从输入 URL 到页面展示到底发生了什么？

非常重要

类似的问题：打开一个网页，整个过程会使用哪些协议？

URL → IP 地址

1. 浏览器解析URL，确定了 Web 服务器和文件名
2. 根据 Web 服务器和文件名生成 HTTP 请求消息
3. 查询服务器域名对应的 IP 地址
4. 委托操作系统将消息发送给 Web 服务器

HTTP

基于TCP协议：面向连接，安全

基于请求-响应模型的：一次请求对应一次响应

HTTP协议是无状态的协议：对于事务处理没有记忆能力。每次请求-响应都是独立的。

• 缺点：多次请求间不能共享数据。
• 优点：速度快

DNS

DNS 中的域名都是用句点来分隔的，比如 www.server.com，这里的句点代表了不同层次之间的界限。

在域名中，越靠右的位置表示其层级越高。

实际上域名最后还有一个点，比如 www.server.com.，这个最后的一个点代表根域名。

也就是，. 根域是在最顶层，它的下一层就是 .com 顶级域，再下面是 server.com。

域名解析的工作流程

1. 客户端首先会发出一个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。
2. 本地域名服务器收到客户端的请求后，如果缓存里的表格能找到 www.server.com，则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器：“老大， 能告诉我 www.server.com 的 IP 地址吗？” 根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。
3. 根 DNS 收到来自本地 DNS 的请求后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域管理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。”
4. 本地 DNS 收到顶级域名服务器的地址后，发起请求问“老二， 你能告诉我 www.server.com 的 IP 地址吗？”
5. 顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
6. 本地 DNS 于是转向问权威 DNS 服务器：“老三，www.server.com对应的IP是啥呀？” server.com 的权威 DNS 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
7. 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
8. 本地 DNS 再将 IP 地址返回客户端，客户端和目标建立连接。

---

浏览器会先看自身有没有对这个域名的缓存，如果有，就直接返回，如果没有，就去问操作系统，操作系统也会去看自己的缓存，如果有，就直接返回，如果没有，再去 hosts 文件看，也没有，才会去问「本地 DNS 服务器」。

协议栈

应用程序（浏览器）通过调用 Socket 库，来委托协议栈工作。

• 协议栈的上半部分有两块，分别是负责收发数据的 TCP 和 UDP 协议，这两个传输协议会接受应用层的委托执行收发数据的操作。
• 协议栈的下面一半是用 IP 协议控制网络包收发操作，在互联网上传数据时，数据会被切分成一块块的网络包，而将网络包发送给对方的操作就是由 IP 负责的。

此外 IP 中还包括 ICMP 协议和 ARP 协议。

• ICMP 用于告知网络包传送过程中产生的错误以及各种控制信息。
• ARP 用于根据 IP 地址查询相应的以太网 MAC 地址。

IP 下面的网卡驱动程序负责控制网卡硬件，而最下面的网卡则负责完成实际的收发操作，也就是对网线中的信号执行发送和接收操作。

TCP

HTTP 是基于 TCP 协议传输的。

TCP 报文头部格式

首先，源端口号和目标端口号是不可少的，如果没有这两个端口号，数据就不知道应该发给哪个应用。

接下来有包的序号，这个是为了解决包乱序的问题。

还有应该有的是确认号，目的是确认发出去对方是否有收到。如果没有收到就应该重新发送，直到送达，这个是为了解决丢包的问题。

接下来还有一些状态位。例如 SYN 是发起一个连接，ACK 是回复，RST 是重新连接，FIN 是结束连接等。TCP 是面向连接的，因而双方要维护连接的状态，这些带状态位的包的发送，会引起双方的状态变更。

还有一个重要的就是窗口大小。TCP 要做流量控制，通信双方各声明一个窗口（缓存大小），标识自己当前能够的处理能力，别发送的太快，撑死我，也别发的太慢，饿死我。

除了做流量控制以外，TCP还会做拥塞控制，对于真正的通路堵车不堵车，它无能为力，唯一能做的就是控制自己，也即控制发送的速度。不能改变世界，就改变自己嘛。

三次握手

在 HTTP 传输数据之前，首先需要 TCP 建立连接，TCP 连接的建立，通常称为三次握手。

• 客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。
• 客户端主动发起连接 SYN，之后处于 SYN-SENT 状态。
• 服务端收到发起的连接，返回 SYN，并且 ACK 客户端的 SYN，之后处于 SYN-RCVD 状态。
• 客户端收到服务端发送的 SYN 和 ACK 之后，发送对 SYN 确认的 ACK，之后处于 ESTABLISHED 状态，因为它一发一收成功了。
• 服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态，因为它也一发一收了。

四次挥手

• 客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
• 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSE_WAIT 状态。
• 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
• 等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
• 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
• 服务端收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。
• 客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

TCP连接状态查看

TCP 的连接状态查看，在 Linux 可以通过 netstat -napt 命令查看。

TCP分割数据

• MTU：一个网络包的最大长度，以太网中一般为 1500 字节。
• MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度。

数据会被以 MSS 的长度为单位进行拆分。

TCP报文生成

TCP 协议里面会有两个端口，一个是浏览器监听的端口（通常是随机生成的）

一个是 Web 服务器监听的端口（HTTP 默认端口号是 80， HTTPS 默认端口号是 443）。

IP

目标地址和子网掩码都是 0.0.0.0，这表示默认网关，如果其他所有条目都无法匹配，就会自动匹配这一行。并且后续就把包发给路由器，Gateway 即是路由器的 IP 地址。

MAC

ARP协议

在发包时：

• 先查询 ARP 缓存，如果其中已经保存了对方的 MAC 地址，就不需要发送 ARP 查询，直接使用 ARP 缓存中的地址。
• 而当 ARP 缓存中不存在对方 MAC 地址时，则发送 ARP 广播查询。

网卡

网络包只是存放在内存中的一串二进制数字信息，要将数字信息转换为电信号，才能在网线上传输。

负责执行这一操作的是网卡，要控制网卡还需要靠网卡驱动程序。

• 起始帧分界符是一个用来表示包起始位置的标记
• 末尾的 FCS（帧校验序列）用来检查包传输过程是否有损坏

交换机

交换机的包接收操作

交换机的设计是将网络包原样转发到目的地，工作在 MAC 层。

首先，电信号到达网线接口，交换机里的模块将电信号转换为数字信号。

然后通过包末尾的 FCS 校验错误，如果没问题则放到缓冲区。

交换机的端口不核对接收方 MAC 地址，而是直接接收所有的包并存放到缓冲区中。

接下来需要查询一下这个包的接收方 MAC 地址是否已经在 MAC 地址表中有记录了。

交换机根据 MAC 地址表查找 MAC 地址，然后将信号发送到相应的端口。

交换机的 MAC 地址表主要包含两个信息：

1. 一个是设备的 MAC 地址，
2. 另一个是该设备连接在交换机的哪个端口上。

地址表中找不到指定的 MAC 地址:

交换机无法判断应该把包转发到哪个端口，只能将包转发到除了源端口之外的所有端口上

只有相应的接收者才接收包，而其他设备则会忽略这个包。

发送了包之后目标设备会作出响应，只要返回了响应包，交换机就可以将它的地址写入 MAC 地址表。

如果接收方 MAC 地址是一个广播地址，那么交换机会将包发送到除源端口之外的所有端口。

以下两个属于广播地址：

• MAC 地址中的 FF:FF:FF:FF:FF:FF
• IP 地址中的 255.255.255.255

路由器

• 路由器是基于 IP 设计的，俗称三层网络设备，路由器的各个端口都具有 MAC 地址和 IP 地址；
• 交换机是基于以太网设计的，俗称二层网络设备，交换机的端口不具有 MAC 地址。

路由器的包接收操作

电信号到达网线接口部分，路由器中的模块会将电信号转成数字信号，然后通过包末尾的 FCS 进行错误校验。

如果没问题则检查 MAC 头部中的接收方 MAC 地址，看看是不是发给自己的包，如果是就放到接收缓冲区中，否则就丢弃这个包。

查询路由表确定输出端口

完成包接收操作之后，路由器就会去掉包开头的 MAC 头部。

MAC 头部的作用就是将包送达路由器，其中的接收方 MAC 地址就是路由器端口的 MAC 地址。因此，当包到达路由器之后，MAC 头部的任务就完成了，于是 MAC 头部就会被丢弃。

实在找不到匹配路由时，就会选择默认路由，路由表中子网掩码为 0.0.0.0 的记录表示「默认路由」

路由器的发送操作

首先，根据路由表的网关列判断对方的地址。

• 如果网关是一个 IP 地址，则这个IP 地址就是我们要转发到的目标地址，还未抵达终点，还需继续需要路由器转发。
• 如果网关为空，则 IP 头部中的接收方 IP 地址就是要转发到的目标地址，也是就终于找到 IP 包头里的目标地址了，说明已抵达终点。

然后通过 ARP 协议根据 IP 地址查询 MAC 地址，并将查询的结果作为接收方 MAC 地址。

路由器也有 ARP 缓存，因此首先会在 ARP 缓存中查询，如果找不到则发送 ARP 查询请求。

接下来是发送方 MAC 地址字段，这里填写输出端口的 MAC 地址。还有一个以太类型字段，填写 0800 （十六进制）表示 IP 协议。

发送出去的网络包会通过交换机到达下一个路由器。

接下来，下一个路由器会将包转发给再下一个路由器，经过层层转发之后，网络包就到达了最终的目的地。

在网络包传输的过程中，源 IP 和目标 IP 始终是不会变的，一直变化的是 MAC 地址，因为需要 MAC 地址在以太网内进行两个设备之间的包传输。

服务器和客户端

数据包抵达服务器后

1. 服务器会先扒开数据包的 MAC 头部，查看是否和服务器自己的 MAC 地址符合，符合就将包收起来。
2. 扒开数据包的 IP 头，发现 IP 地址符合，根据 IP 头中协议项，知道自己上层是 TCP 协议。
3. 扒开 TCP 的头部，里面有序列号，看一看序列包是不是我想要的，如果是就放入缓存中然后返回一个 ACK，如果不是就丢弃。TCP头部里面还有端口号， HTTP 的服务器正在监听这个端口号，于是就将包发给 HTTP 进程。
4. 服务器的 HTTP 进程看到，原来这个请求是要访问一个页面，于是就把这个网页封装在 HTTP 响应报文里。

HTTP 响应报文也需要穿上 TCP、IP、MAC 头部，目的地址是客户端 IP 地址。

最后，向服务器发起了 TCP 四次挥手，至此双方的连接就断开了。

---

“请问公网服务器的 Mac 地址是在什么时机通过什么方式获取到的？我看 arp 获取Mac地址只能获取到内网机器的 Mac 地址吧？”

在发送数据包时，如果目标主机不是本地局域网，填入的MAC地址是路由器，也就是把数据包转发给路由器，路由器一直转发下一个路由器，直到转发到目标主机的路由器，发现 IP 地址是自己局域网内的主机，就会 arp 请求获取目标主机的 MAC 地址，从而转发到这个服务器主机。

---

1. 在浏览器中输入指定网页的 URL。
2. 浏览器通过 DNS 协议，获取域名对应的 IP 地址。
3. 浏览器根据 IP 地址和端口号，向目标服务器发起一个 TCP 连接请求。
4. 浏览器在 TCP 连接上，向服务器发送一个 HTTP 请求报文，请求获取网页的内容。
5. 服务器收到 HTTP 请求报文后，处理请求，并返回 HTTP 响应报文给浏览器。
6. 浏览器收到 HTTP 响应报文后，解析响应体中的 HTML 代码，渲染网页的结构和样式，同时根据 HTML 中的其他资源的 URL（如图片、CSS、JS 等），再次发起 HTTP 请求，获取这些资源的内容，直到网页完全加载显示。
7. 浏览器在不需要和服务器通信时，可以主动关闭 TCP 连接，或者等待服务器的关闭请求。

详细介绍可以查看这篇文章：访问网页的全过程（知识串联）（强烈推荐）。

---

HTTP 状态码有哪些

HTTP 状态码更详细的总结：HTTP 常见状态码总结（应用层）。

状态码由3位数字组成，第一个数字定义了响应的类别：

1xx：指示信息，表示请求已接收，继续处理

2xx：成功，表示请求已被成功接受，处理。

3xx：重定向。命令浏览器重定向到一个新的URL。

4xx：客户端错误

5xx：服务器端错误，服务器未能实现合法的请求。

HTTP 和 HTTPS 区别？（重要）

• 端口号：HTTP 默认是 80，HTTPS 默认是 443。

• URL 前缀：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。

• 安全性和资源消耗：

  HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。

  HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。

  所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

• SEO（搜索引擎优化）：搜索引擎通常会更青睐使用 HTTPS 协议的网站，因为 HTTPS 能够提供更高的安全性和用户隐私保护。使用 HTTPS 协议的网站在搜索结果中可能会被优先显示，从而对 SEO 产生影响。

关于 HTTP 和 HTTPS 更详细的对比总结，可以看我写的这篇文章：HTTP vs HTTPS（应用层） 。

---

HTTP 是不保存状态的协议, 如何保存用户状态?

HTTP 是无状态协议，不对请求和响应之间的通信状态进行保存。

Session 机制通过服务端保存用户状态。

典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Session 存放在服务器端，我们大都通过在 Cookie 中附加一个 Session ID 来方式来实现 Session 跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

---

URI 和 URL 的区别

• URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
• URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

---

Cookie 和 Session 区别

这个问题属于认证授权的范畴，你可以在 认证授权基础概念详解 这篇文章中找到详细的答案。

---

GET 和 POST 区别

1. 参数传递方式:
   • GET: 参数通过 URL 的查询字符串传递，放在 URL 的后面，例如：http://example.com/path?param1=value1&param2=value2。
   • POST: 参数通过请求体body传递，放在 HTTP 请求的消息体中。
2. 安全性:
   • GET: 请求参数附加在 URL 上，会被保存在浏览器的历史记录、服务器的日志中，可能会暴露敏感信息。由于 URL 长度限制，适合传递少量非敏感信息。
   • POST: 参数在请求体中，相对安全，适合传递敏感信息和大量数据。
3. 请求语义:
   • GET: 表示获取/查询资源，不应该对服务器端产生副作用。在浏览器中刷新页面、点击链接、访问书签等都属于 GET 请求。
   • POST: 表示向服务器创建/修改数据，可能对服务器端产生副作用，如修改数据库内容。通常用于表单提交。
4. 幂等性:
   • GET: 幂等，多次请求结果相同。即多次重复执行不会改变资源的状态
   • POST: 不幂等，多次请求可能产生不同的结果。即每次执行可能会产生不同的结果或影响资源的状态。
5. 缓存:
   • GET: 可以被浏览器缓存。由于 GET 请求是幂等的，它可以被浏览器或其他中间节点（如代理、网关）缓存起来，以提高性能和效率。
   • POST: 默认不被浏览器缓存，除非显式指定。因为它可能有副作用，每次执行可能需要实时的响应。
6. 使用场景:
   • GET: 适合获取资源，请求参数少且不敏感。
   • POST: 适合提交数据，请求参数较多或包含敏感信息。

---

WebSocket

WebSocket 是一种基于 TCP 连接的全双工通信协议，即客户端和服务器可以同时发送和接收数据。

WebSocket 协议本质上是应用层的协议，用于弥补 HTTP 协议在持久通信能力上的不足。客户端和服务器仅需一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

WebSocket 和 HTTP 有什么区别？

WebSocket 和 HTTP 两者都是基于 TCP 的应用层协议，都可以在网络中传输数据。

下面是二者的主要区别：

• WebSocket 是一种双向实时通信协议，而 HTTP 是一种单向通信协议。并且，HTTP 协议下的通信只能由客户端发起，服务器无法主动通知客户端。
• WebSocket 使用 ws:// 或 wss://（使用 SSL/TLS 加密后的协议，类似于 HTTP 和 HTTPS 的关系） 作为协议前缀，HTTP 使用 http:// 或 https:// 作为协议前缀。
• WebSocket 可以支持扩展，用户可以扩展协议，实现部分自定义的子协议，如支持压缩、加密等。
• WebSocket 通信数据格式比较轻量，用于协议控制的数据包头部相对较小，网络开销小，而 HTTP 通信每次都要携带完整的头部，网络开销较大（HTTP/2.0 使用二进制帧进行数据传输，还支持头部压缩，减少了网络开销）

WebSocket 的工作过程是什么样的？

WebSocket 的工作过程可以分为以下几个步骤：

1. 客户端向服务器发送一个 HTTP 请求，请求头中包含 Upgrade: websocket 和 Sec-WebSocket-Key 等字段，表示要求升级协议为 WebSocket；
2. 服务器收到这个请求后，会进行升级协议的操作，如果支持 WebSocket，它将回复一个 HTTP 101 状态码，响应头中包含 ，Connection: Upgrade和 Sec-WebSocket-Accept: xxx 等字段、表示成功升级到 WebSocket 协议。
3. 客户端和服务器之间建立了一个 WebSocket 连接，可以进行双向的数据传输。数据以帧（frames）的形式进行传送，WebSocket 的每条消息可能会被切分成多个数据帧（最小单位）。发送端会将消息切割成多个帧发送给接收端，接收端接收消息帧，并将关联的帧重新组装成完整的消息。
4. 客户端或服务器可以主动发送一个关闭帧，表示要断开连接。另一方收到后，也会回复一个关闭帧，然后双方关闭 TCP 连接。

另外，建立 WebSocket 连接之后，通过心跳机制来保持 WebSocket 连接的稳定性和活跃性。

PING

PING 命令是一种常用的网络诊断工具，经常用来测试网络中主机之间的连通性和网络延迟。

PING 基于网络层的 ICMP（Internet Control Message Protocol，互联网控制报文协议），其主要原理就是通过在网络上发送和接收 ICMP 报文实现的。

ICMP 报文的类型有很多种，但大致可以分为两类：

• 查询报文类型：向目标主机发送请求并期望得到响应。
• 差错报文类型：向源主机发送错误信息，用于报告网络中的错误情况。

PING 用到的 ICMP Echo Request（类型为 8 ） 和 ICMP Echo Reply（类型为 0） 属于查询报文类型 。

• PING 命令会向目标主机发送 ICMP Echo Request。
• 如果两个主机的连通性正常，目标主机会返回一个对应的 ICMP Echo Reply。

DNS

DNS作用

DNS（Domain Name System）域名管理系统，是当用户使用浏览器访问网址之后，使用的第一个重要协议。DNS 要解决的是域名和 IP 地址的映射问题。

DNS 是应用层协议，它可以在 UDP 或 TCP 协议之上运行，端口为 53 。

---

DNS 解析的过程

DNS 域名系统详解（应用层）

DNS 劫持，如何应对？

DNS 劫持是一种网络攻击，它通过修改 DNS 服务器的解析结果，使用户访问的域名指向错误的 IP 地址。

黑客技术？没你想象的那么难！——DNS 劫持篇open in new window。

TCP与UDP

TCP 与 UDP 的区别和应用场景

是否面向连接：

• UDP 在传送数据之前不需要先建立连接。
• TCP 提供面向连接的服务，在传送数据之前必须先建立连接，数据传送结束后要释放连接。

可靠性：

• UDP 是尽最大努力交付，不保证可靠交付数据，不保证是否顺序到达。
• TCP 提供可靠的传输服务。TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制。确保数据的可靠传输。数据可以无差错、不丢失、不重复、按序到达。

拥塞控制、流量控制

• TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
• UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

是否有状态：

TCP 传输是有状态的，这个有状态说的是 TCP 会去记录自己发送消息的状态比如消息是否发送了、是否被接收了等等。为此 ，TCP 需要维持复杂的连接状态表。

而 UDP 是无状态服务，简单来说就是不管发出去之后的事情了（这很渣男！）。

传输效率：由于使用 TCP 进行传输的时候多了连接、确认、重传等机制，所以 TCP 的传输效率要比 UDP 低很多。

传输形式：TCP 是面向字节流的，UDP 是面向报文的。

• TCP: 面向字节流，数据是以流的方式传输的，没有边界，但保证顺序和可靠。
• UDP: 面向数据报，每个数据包都是独立的，是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

首部开销：TCP 首部开销（20 ～ 60 字节）比 UDP 首部开销（8 字节）要大。

是否提供广播或多播服务：

• TCP 只支持点对点通信
• UDP 支持一对一、一对多、多对一、多对多；

---

TCP 和 UDP 应用场景：

由于 TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：

• FTP 文件传输、发送和接收邮件、远程登录
• HTTP / HTTPS；

由于 UDP 面向无连接，它可以随时发送数据，再加上 UDP 本身的处理既简单又高效，因此经常用于即时通信，传输数据的准确性要求不是特别高：

• 包总量较少的通信，如 DNS 、SNMP 等；
• 语音、 视频、直播等多媒体通信；
• 广播通信；

为什么 UDP 头部没有「首部长度」字段，而 TCP 头部有「首部长度」字段呢？

原因是 TCP 有可变长的「选项」字段，而 UDP 头部长度则是不会变化的，无需多一个字段去记录 UDP 的首部长度。

TCP 和 UDP 可以使用同一个端口吗？

---

HTTP 基于 TCP 还是 UDP？

HTTP/3.0 之前是基于 TCP 协议的，而 HTTP/3.0 将弃用 TCP，改用 基于 UDP 的 QUIC 协议 。

---

使用 TCP /UDP的协议

运行于 TCP 协议之上的协议：

HTTP 协议（HTTP/3.0 之前）：超文本传输协议（HTTP，HyperText Transfer Protocol)是一种用于传输超文本和多媒体内容的协议，主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的。

HTTPS 协议：更安全的超文本传输协议(HTTPS,Hypertext Transfer Protocol Secure)，身披 SSL 外衣的 HTTP 协议

FTP 协议：文件传输协议 FTP（File Transfer Protocol）是一种用于在计算机之间传输文件的协议，可以屏蔽操作系统和文件存储方式。注意 ⚠️：FTP 是一种不安全的协议，因为它在传输过程中不会对数据进行加密。建议在传输敏感数据时使用更安全的协议，如 SFTP。

SMTP 协议：简单邮件传输协议（SMTP，Simple Mail Transfer Protocol）的缩写，是一种用于发送电子邮件的协议。注意 ⚠️：SMTP 协议只负责邮件的发送，而不是接收。要从邮件服务器接收邮件，需要使用 POP3 或 IMAP 协议。

POP3/IMAP 协议：两者都是负责邮件接收的协议。IMAP 协议是比 POP3 更新的协议，它在功能和性能上都更加强大。IMAP 支持邮件搜索、标记、分类、归档等高级功能，而且可以在多个设备之间同步邮件状态。几乎所有现代电子邮件客户端和服务器都支持 IMAP。

Telnet 协议：用于通过一个终端登陆到其他服务器。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用 Telnet，而是使用一种称为 SSH 的非常安全的网络传输协议的主要原因。

SSH 协议 : SSH（ Secure Shell）是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH 建立在可靠的传输协议 TCP 之上。

运行于 UDP 协议之上的协议：

HTTP 协议（HTTP/3.0 ）： HTTP/3.0 弃用 TCP，改用基于 UDP 的 QUIC 协议 。

DHCP 协议：动态主机配置协议，动态配置 IP 地址

DNS：域名系统（DNS，Domain Name System）将人类可读的域名 (例如，www.baidu.comopen in new window) 转换为机器可读的 IP 地址 (例如，220.181.38.148)。 我们可以将其理解为专为互联网设计的电话薄。实际上，DNS 同时支持 UDP 和 TCP 协议。

---

TCP 三次握手和四次挥手（非常重要)

参考牛客网面经答案

相关面试题：

• 为什么要三次握手?
• 第 2 次握手传回了 ACK，为什么还要传回 SYN？
• 为什么要四次挥手？
• 为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？
• 如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？
• 为什么第四次挥手客户端需要等待 2*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？

参考答案：TCP 三次握手和四次挥手（传输层） 。

---

TCP 如何保证传输的可靠性？

TCP 传输可靠性保障（传输层）

TCP

TCP基本认识

TCP 头格式有哪些？

序列号：在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。

确认应答号：指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。

控制位：

• ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。
• RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
• SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
• FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

为什么需要 TCP 协议？ TCP 工作在哪一层？

IP 层是「不可靠」的，它不保证网络包的交付、不保证网络包的按序交付、也不保证网络包中的数据的完整性。

因为 TCP 是一个工作在传输层的可靠数据传输的服务，它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。

什么是 TCP ？

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

• 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
• 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
• 字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法读出一个有效的用户消息的。并且 TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。

什么是 TCP 连接？

简单来说就是，用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括 Socket、序列号和窗口大小称为连接。

建立一个 TCP 连接是需要客户端与服务端达成上述三个信息的共识。

• Socket：由 IP 地址和端口号组成
• 序列号：用来解决乱序问题等
• 窗口大小：用来做流量控制

如何唯一确定一个 TCP 连接呢？

TCP 四元组可以唯一的确定一个连接，四元组包括如下：

• 源地址
• 源端口
• 目的地址
• 目的端口

源地址和目的地址的字段（32 位）是在 IP 头部中，作用是通过 IP 协议发送报文给对方主机。

源端口和目的端口的字段（16 位）是在 TCP 头部中，作用是告诉 TCP 协议应该把报文发给哪个进程。

有一个 IP 的服务端监听了一个端口，它的 TCP 的最大连接数是多少？

服务端通常固定在某个本地端口上监听，等待客户端的连接请求。

因此，客户端 IP 和端口是可变的，其理论值计算公式如下:

对 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数，约为 2 的 48 次方。

TCP连接建立

TCP连接断开

TCP 是通过序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输的。

TCP 重传

TCP 实现可靠传输的方式之一，是通过序列号与确认应答。

在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。

超时重传

重传机制的其中一个方式，就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据，也就是我们常说的超时重传。

TCP 会在以下两种情况发生超时重传：

• 数据包丢失
• 确认应答丢失

RTT 指的是数据发送时刻到接收到确认的时刻的差值，也就是包的往返时间。

超时重传时间是以 RTO （Retransmission Timeout 超时重传时间）表示。

上图中有两种超时时间不同的情况：

• 当超时时间 RTO 较大时，重发就慢，丢了老半天才重发，没有效率，性能差；
• 当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。

超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。

每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。

超时触发重传存在的问题是，超时周期可能相对较长。那是不是可以有更快的方式呢？

于是就可以用「快速重传」机制来解决超时重发的时间等待。快速重传

快速重传

TCP 还有另外一种快速重传（Fast Retransmit）机制，它不以时间为驱动，而是以数据驱动重传。

发送方发出了 1，2，3，4，5 份数据：

• 第一份 Seq1 先送到了，于是就 Ack 回 2；
• 结果 Seq2 因为某些原因没收到，Seq3 到达了，于是还是 Ack 回 2；
• 后面的 Seq4 和 Seq5 都到了，但还是 Ack 回 2，因为 Seq2 还是没有收到；
• 发送端收到了三个 Ack = 2 的确认，知道了 Seq2 还没有收到，就会在定时器过期之前，重传丢失的 Seq2。
• 最后，收到了 Seq2，此时因为 Seq3，Seq4，Seq5 都收到了，于是 Ack 回 6 。

所以，快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。

快速重传机制只解决了一个问题，就是超时时间的问题，

但是它依然面临着另外一个问题。就是重传的时候，是重传一个，还是重传所有的问题。

举个例子，假设发送方发了 6 个数据，编号的顺序是 Seq1 ~ Seq6 ，但是 Seq2、Seq3 都丢失了，那么接收方在收到 Seq4、Seq5、Seq6 时，都是回复 ACK2 给发送方，但是发送方并不清楚这连续的 ACK2 是接收方收到哪个报文而回复的， 那是选择重传 Seq2 一个报文，还是重传 Seq2 之后已发送的所有报文呢（Seq2、Seq3、 Seq4、Seq5、 Seq6） 呢？

• 如果只选择重传 Seq2 一个报文，那么重传的效率很低。因为对于丢失的 Seq3 报文，还得在后续收到三个重复的 ACK3 才能触发重传。
• 如果选择重传 Seq2 之后已发送的所有报文，虽然能同时重传已丢失的 Seq2 和 Seq3 报文，但是 Seq4、Seq5、Seq6 的报文是已经被接收过了，对于重传 Seq4 ～Seq6 折部分数据相当于做了一次无用功，浪费资源。

可以看到，不管是重传一个报文，还是重传已发送的报文，都存在问题。

为了解决不知道该重传哪些 TCP 报文，于是就有 SACK 方法。

SACK 方法

SACK（ Selective Acknowledgment）， 选择性确认

需要在 TCP 头部「选项」字段里加一个 SACK 的东西，它可以将已收到的数据的信息发送给「发送方」，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

如下图，发送方收到了三次同样的 ACK 确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进行重复。

Duplicate SACK

栗子一号：ACK 丢包

• 「接收方」发给「发送方」的两个 ACK 确认应答都丢失了，所以发送方超时后，重传第一个数据包（3000 ~ 3499）
• 于是「接收方」发现数据是重复收到的，于是回了一个 SACK = 3000~3500，告诉「发送方」 3000~3500 的数据早已被接收了，因为 ACK 都到了 4000 了，已经意味着 4000 之前的所有数据都已收到，所以这个 SACK 就代表着 D-SACK。
• 这样「发送方」就知道了，数据没有丢，是「接收方」的 ACK 确认报文丢了。

栗子二号：网络延时

• 数据包（1000~1499） 被网络延迟了，导致「发送方」没有收到 Ack 1500 的确认报文。
• 而后面报文到达的三个相同的 ACK 确认报文，就触发了快速重传机制，但是在重传后，被延迟的数据包（1000~1499）又到了「接收方」；
• 所以「接收方」回了一个 SACK=1000~1500，因为 ACK 已经到了 3000，所以这个 SACK 是 D-SACK，表示收到了重复的包。
• 这样发送方就知道快速重传触发的原因不是发出去的包丢了，也不是因为回应的 ACK 包丢了，而是因为网络延迟了。

D-SACK 有这么几个好处：

1. 可以让「发送方」知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了;
2. 可以知道是不是「发送方」的数据包被网络延迟了;
3. 可以知道网络中是不是把「发送方」的数据包给复制了;

滑动窗口

TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了， 再发送下一个。

像我和你面对面聊天，你一句我一句。但这种方式的缺点是效率比较低的。

TCP 引入了窗口这个概念。即使在往返时间较长的情况下，它也不会降低网络通信的效率。

有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。

窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」。如下图：

图中的 ACK 600 确认应答报文丢失，也没关系，因为可以通过下一个确认应答进行确认，只要发送方收到了 ACK 700 确认应答，就意味着 700 之前的所有数据「接收方」都收到了。这个模式就叫累计确认或者累计应答。

接收端告诉发送端自己还有多少缓冲区可以接收数据。

于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

流量控制

如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。

为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。

拥塞控制

为什么要有拥塞控制呀，不是有流量控制了吗？

前面的流量控制是避免「发送方」的数据填满「接收方」的缓存，但是并不知道网络的中发生了什么。

一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。

在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大....

所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。

于是，就有了拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络。

为了在「发送方」调节所要发送数据的量，定义了一个叫做「拥塞窗口」的概念。

什么是拥塞窗口？和发送窗口有什么关系呢？

拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。

我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系。

那么由于加入了拥塞窗口的概念后，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值。

拥塞窗口 cwnd 变化的规则：

• 只要网络中没有出现拥塞，cwnd 就会增大；
• 但网络中出现了拥塞，cwnd 就减少；

怎么知道当前网络是否出现了拥塞呢？

只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。

拥塞控制有哪些控制算法？

慢启动

TCP 在刚建立连接完成后，首先是有个慢启动的过程，一点一点的提高发送数据包的数量。

慢启动的算法记住一个规则就行：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。

慢启动算法，发包的个数是指数性的增长。

慢启动涨到什么时候是个头呢？

有一个叫慢启动门限 ssthresh （slow start threshold）状态变量。

• 当 cwnd < ssthresh 时，使用慢启动算法。
• 当 cwnd >= ssthresh 时，就会使用「拥塞避免算法」。

一般来说 ssthresh 的大小是 65535 字节。

拥塞避免

进入拥塞避免算法后，规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。

接上前面的慢启动的栗子，现假定 ssthresh 为 8：

• 当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9 个 MSS 大小的数据，变成了线性增长。

拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长，增长速度缓慢了一些。

拥塞发生

当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：

• 超时重传
• 快速重传

这两种使用的拥塞发送算法是不同的。

发生超时重传的拥塞发生算法

当发生了「超时重传」，则就会使用拥塞发生算法。

这个时候，ssthresh 和 cwnd 的值会发生变化：

• ssthresh 设为 cwnd/2，
• cwnd 重置为 1 （是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1）

接着，就重新开始慢启动，慢启动是会突然减少数据流的。这真是一旦「超时重传」，马上回到解放前。

这种方式太激进了，反应也很强烈，会造成网络卡顿。

发生快速重传的拥塞发生算法

当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。

TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则 ssthresh 和 cwnd 变化如下：

• cwnd = cwnd/2 ，也就是设置为原来的一半;
• ssthresh = cwnd;
• 进入快速恢复算法

快速恢复

正如前面所说，进入快速恢复之前，cwnd 和 ssthresh 已被更新了：

• cwnd = cwnd/2 ，也就是设置为原来的一半;
• ssthresh = cwnd;

然后，进入快速恢复算法如下：

• 拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
• 重传丢失的数据包；
• 如果再收到重复的 ACK，那么 cwnd 增加 1；
• 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；

快速恢复算法过程中，为什么收到新的数据后，cwnd 设置回了 ssthresh ？

我的理解是：

1. 在快速恢复的过程中，首先 ssthresh = cwnd/2，然后 cwnd = ssthresh + 3，表示网络可能出现了阻塞，所以需要减小 cwnd 以避免，加 3 代表快速重传时已经确认接收到了 3 个重复的数据包；
2. 随后继续重传丢失的数据包，如果再收到重复的 ACK，那么 cwnd 增加 1。加 1 代表每个收到的重复的 ACK 包，都已经离开了网络。这个过程的目的是尽快将丢失的数据包发给目标。
3. 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，恢复过程结束。

首先，快速恢复是拥塞发生后慢启动的优化，其首要目的仍然是降低 cwnd 来减缓拥塞，所以必然会出现 cwnd 从大到小的改变。

其次，过程2（cwnd逐渐加1）的存在是为了尽快将丢失的数据包发给目标，从而解决拥塞的根本问题（三次相同的 ACK 导致的快速重传），所以这一过程中 cwnd 反而是逐渐增大的。

IP

IP 协议作用

IP（Internet Protocol，网际协议） 是 TCP/IP 协议中最重要的协议之一，属于网络层的协议，主要作用是定义数据包的格式、对数据包进行路由和寻址，以便它们可以跨网络传播并到达正确的目的地。

目前 IP 协议主要分为两种，一种是过去的 IPv4，另一种是较新的 IPv6。

---

IP 地址和MAC地址区别

如何获取客户端真实 IP

应用层方法 ：

通过 X-Forwarded-For请求头获取，简单方便。不过，这种方法无法保证获取到的是真实 IP，这是因为 X-Forwarded-For 字段可能会被伪造。如果经过多个代理服务器，X-Forwarded-For 字段可能会有多个值（附带了整个请求链中的所有代理服务器 IP 地址）。并且，这种方法只适用于 HTTP 和 SMTP 协议。

传输层方法：

利用 TCP Options 字段承载真实源 IP 信息。这种方法适用于任何基于 TCP 的协议，不受应用层的限制。不过，这并非是 TCP 标准所支持的，所以需要通信双方都进行改造。也就是：对于发送方来说，需要有能力把真实源 IP 插入到 TCP Options 里面。对于接收方来说，需要有能力把 TCP Options 里面的 IP 地址读取出来。

也可以通过 Proxy Protocol 协议来传递客户端 IP 和 Port 信息。这种方法可以利用 Nginx 或者其他支持该协议的反向代理服务器来获取真实 IP 或者在业务服务器解析真实 IP。

网络层方法：

隧道 +DSR 模式。这种方法可以适用于任何协议，就是实施起来会比较麻烦，也存在一定限制，实际应用中一般不会使用这种方法。

NAT作用

NAT（Network Address Translation，网络地址转换） 主要用于在不同网络之间转换 IP 地址。它允许将私有 IP 地址（如在局域网中使用的 IP 地址）映射为公有 IP 地址（在互联网中使用的 IP 地址）或者反向映射，从而实现局域网内的多个设备通过单一公有 IP 地址访问互联网。

NAT 不光可以缓解 IPv4 地址资源短缺的问题，还可以隐藏内部网络的实际拓扑结构，使得外部网络无法直接访问内部网络中的设备，从而提高了内部网络的安全性。

ARP

Mac地址

MAC 地址的全称是 媒体访问控制地址（Media Access Control Address）。

如果说，互联网中每一个资源都由 IP 地址唯一标识（IP 协议内容），那么一切网络设备都由 MAC 地址唯一标识。

---

ARP协议

ARP 协议的工作原理

ARP 协议， 地址解析协议（Address Resolution Protocol），

解决的是网络层地址和链路层地址之间的转换问题。

因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。

ARP 协议详解(网络层)

---

三次握手的过程，以及为什么是三次，而不是四次，两次？

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

1. 第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
2. 第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
3. 第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

三次握手就能确认双方收发功能都正常，缺一不可。

四次挥手的过程，以及为什么是四次

断开一个 TCP 连接则需要“四次挥手”，缺一不可：

1. 第一次挥手：客户端发送一个 FIN（SEQ=x） 标志的数据包->服务端，用来关闭客户端到服务端的数据传送。然后客户端进入 FIN-WAIT-1 状态。
2. 第二次挥手：服务端收到这个 FIN（SEQ=X） 标志的数据包，它发送一个 ACK （ACK=x+1）标志的数据包->客户端 。然后服务端进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态。
3. 第三次挥手：服务端发送一个 FIN (SEQ=y)标志的数据包->客户端，请求关闭连接，然后服务端进入 LAST-ACK 状态。
4. 第四次挥手：客户端发送 ACK (ACK=y+1)标志的数据包->服务端，然后客户端进入TIME-WAIT状态，服务端在收到 ACK (ACK=y+1)标志的数据包后进入 CLOSE 状态。此时如果客户端等待 2MSL 后依然没有收到回复，就证明服务端已正常关闭，随后客户端也可以关闭连接了。

只要四次挥手没有结束，客户端和服务端就可以继续传输数据！

TCP 是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。

举个例子：A 和 B 打电话，通话即将结束后。

1. 第一次挥手：A 说“我没啥要说的了”
2. 第二次挥手：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
3. 第三次挥手：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”
4. 第四次挥手：A 回答“知道了”，这样通话才算结束。

TCP与UDP的概念，特点，区别和对应的使用场景

HTTP请求常见的状态码和字段

2xx Success（成功状态码）

• 200 OK：请求被成功处理。比如我们发送一个查询用户数据的 HTTP 请求到服务端，服务端正确返回了用户数据。这个是我们平时最常见的一个 HTTP 状态码。
• 201 Created：请求被成功处理并且在服务端创建了一个新的资源。比如我们通过 POST 请求创建一个新的用户。
• 202 Accepted：服务端已经接收到了请求，但是还未处理。
• 204 No Content：服务端已经成功处理了请求，但是没有返回任何内容。

简单来说，204 状态码描述的是我们向服务端发送 HTTP 请求之后，只关注处理结果是否成功的场景。也就是说我们需要的就是一个结果：true/false。

举个例子：你要追一个女孩子，你问女孩子：“我能追你吗？”，女孩子回答：“好！”。我们把这个女孩子当做是服务端就很好理解 204 状态码了。

3xx Redirection（重定向状态码）

• 301 Moved Permanently：资源被永久重定向了。比如你的网站的网址更换了。
• 302 Found：资源被临时重定向了。比如你的网站的某些资源被暂时转移到另外一个网址。

4xx Client Error（客户端错误状态码

• 400 Bad Request：发送的 HTTP 请求存在问题。比如请求参数不合法、请求方法错误。
• 401 Unauthorized：未认证却请求需要认证之后才能访问的资源。
• 403 Forbidden：直接拒绝 HTTP 请求，不处理。一般用来针对非法请求。
• 404 Not Found：你请求的资源未在服务端找到。比如你请求某个用户的信息，服务端并没有找到指定的用户。
• 409 Conflict：表示请求的资源与服务端当前的状态存在冲突，请求无法被处理。

5xx Server Error（服务端错误状态码）

• 500 Internal Server Error：服务端出问题了（通常是服务端出 Bug 了）。比如你服务端处理请求的时候突然抛出异常，但是异常并未在服务端被正确处理。
• 502 Bad Gateway：我们的网关将请求转发到服务端，但是服务端返回的却是一个错误的响应。

常见的请求方式？GET和POST请求的区别

强缓存和协商缓存

HTTPS的工作原理？(https是怎么建立连接的）

HTTPS与HTTP的区别

• 端口号：HTTP 默认是 80，HTTPS 默认是 443。
• URL 前缀：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。
• 安全性和资源消耗：HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
• SEO（搜索引擎优化）：搜索引擎通常会更青睐使用 HTTPS 协议的网站，因为 HTTPS 能够提供更高的安全性和用户隐私保护。使用 HTTPS 协议的网站在搜索结果中可能会被优先显示，从而对 SEO 产生影响。

HTTP 是不保存状态的协议, 如何保存用户状态?

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们如何保存用户状态呢？

Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。相对来说 Session 安全性更高。如果使用 Cookie 的一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

那么，如何使用 Session 进行身份验证？

如何使用 Session-Cookie 方案进行身份验证？

很多时候我们都是通过 SessionID 来实现特定的用户，SessionID 一般会选择存放在 Redis 中。举个例子：

1. 用户成功登陆系统，然后返回给客户端具有 SessionID 的 Cookie 。
2. 当用户向后端发起请求的时候会把 SessionID 带上，这样后端就知道你的身份状态了。

关于这种认证方式更详细的过程如下：

1. 用户向服务器发送用户名、密码、验证码用于登陆系统。
2. 服务器验证通过后，服务器为用户创建一个 Session，并将 Session 信息存储起来。
3. 服务器向用户返回一个 SessionID，写入用户的 Cookie。
4. 当用户保持登录状态时，Cookie 将与每个后续请求一起被发送出去。
5. 服务器可以将存储在 Cookie 上的 SessionID 与存储在内存中或者数据库中的 Session 信息进行比较，以验证用户的身份，返回给用户客户端响应信息的时候会附带用户当前的状态。

使用 Session 的时候需要注意下面几个点：

• 依赖 Session 的关键业务一定要确保客户端开启了 Cookie。
• 注意 Session 的过期时间。

HTTP多个TCP连接怎么实现

TCP 的 Keepalive 和 HTTP 的 Keep-Alive 是⼀个东西吗？

TCP连接如何确保可靠性

拥塞控制是怎么实现的嘛

Cookie和Session是什么？有什么区别？

什么是 Cookie ? Cookie 的作用是什么?

Cookie 存放在客户端，一般用来保存用户信息。

Cookie 和 Session 都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

操作系统

进程和线程的区别

进程调度算法

进程间有哪些通信方式

什么是死锁？如何避免死锁？

什么是虚拟内存？为什么需要虚拟内存？

什么是虚拟内存？为什么需要虚拟内存？

解释⼀下用户态和核心态

解释⼀下页面置换算法，例如LRU（最近最少使用）、FIFO（先进先出）等

解释⼀下进程同步和互斥，以及解决方法

什么是中断和异常？有何区别

介绍⼀下几种典型的锁

线程同步的方式有哪些

算法

算法

查找

二分查找

排序

冒泡排序

选择排序

插入排序

快速排序

外卖项目

苍穹外卖面试题准备（持续更新-CSDN博客

看一下JAVAWEB的ppt

Entity	实体，通常和数据库中的表对应
DTO	数据传输对象，通常用于程序中各层之间传递数据
VO	视图对象，为前端展示数据提供的对象
POJO	普通Java对象，只有属性和对应的getter和setter / Plain Ordinary（Old）Java Object

项目介绍：

这个项目最初是我参与制作的开源项目，设定目标是一款为学生提供校园外卖送至宿舍服务的软件，包含系统管理后台和小程序端两部分。其中系统管理后台主要提供给食堂内部员工使用，可以对食堂各个窗口、员工、订单、菜品等进行维护管理；小程序端可以在线浏览菜品、添加购物车、下单等，由学生兼职做跑腿送餐上门服务。这是个前后端分离的项目，我主要是负责后端的用户登录、员工管理，菜品管理，订单管理模块的编码实现。

项目部署

拆分为前后端分离的项目后，最终部署时，后端工程会打成一个jar包，运行在Tomcat中 (springboot内嵌的tomcat)。

前端工程的静态资源，会直接部署在Nginx中进行访问。

每张表的说明：

1	employee	员工表
2	category	分类表
3	dish	菜品表
4	dish_flavor	菜品口味表
5	setmeal	套餐表
6	setmeal_dish	套餐菜品关系表
7	user	用户表
8	address_book	地址表
9	shopping_cart	购物车表
10	orders	订单表
11	order_detail	订单明细表

employee表结构：

id	bigint	主键	自增
name	varchar(32)	姓名
username	varchar(32)	用户名	唯一
password	varchar(64)	密码
phone	varchar(11)	手机号
sex	varchar(2)	性别
id_number	varchar(18)	身份证号
status	Int	账号状态	1正常 0锁定
create_time	Datetime	创建时间
update_time	datetime	最后修改时间
create_user	bigint	创建人id
update_user	bigint	最后修改人id

Redis

Redis的Java客户端

Redis 的 Java 客户端很多，常用的几种：

Jedis、Lettuce、Spring Data Redis

Spring Data Redis 是 Spring 的一部分，对 Redis 底层开发包进行了高度封装。

在 Spring 项目中，可以使用Spring Data Redis来简化操作。

redis在项目中作用

Redis 是高性能的，基于键值对的，写入缓存的内存存储系统。

支持多种数据结构如字符串、哈希表、列表、集合、有序集合等，并提供了丰富的操作命令。

项目中引入 Redis 的地方是：查询店铺营业状态 ，像这种店铺营业状态，本项目无非就两个状态：营业中/打样。而且它属于高频查询。只要用户浏览到这个店铺，前端就要自动发送请求到后端查询店铺状态。

Redis 是基于键值对这种形式存储的，而且 Redis 也把将数据放到缓存中，而不是磁盘，有效缓解了这种高频查询给磁盘带来的压力。

缓存菜品 用户端小程序展示的菜品数据都是通过查询数据库获得，如果用户端访问量比较大，数据库访问压力随之增大。

结果：系统响应慢、用户体验差。通过Redis来缓存菜品数据，减少数据库查询操作。
缓存套餐（用到的是Spring Cache)

MySQL 与 redis 的双写一致性/同步

1. redisson读写锁解决

用户在查看店铺状态时，需要让数据库与 redis 高度保持一致，因为如果店铺没有营业的话就不能点单了，所以它要求时效性比较高，所以采用的读写锁保证的强一致性。

采用的是 redisson 实现的读写锁

• 在读的时候添加共享锁，可以保证读读不互斥，读写互斥。
• 更新数据的时候，添加排他锁，它是读写，读读都互斥，这样就能保证在写数据的同时是不会让其他线程读数据的，避免了脏数据。

这里面需要注意的是读方法和写方法上需要使用同一把锁才行。

排他锁保证互斥

排他锁底层使用也是setnx，保证了同时只能有一个线程操作锁住的方法

延时双删

延迟双删，如果是写操作，我们先把缓存中的数据删除，然后更新数据库，最后再延时删除缓存中的数据。

其中这个延时多久不太好确定，在延时的过程中可能会出现脏数据，并不能保证强一致性，所以没有采用它。|

一致性:

• 强一致性：任何一次读都能读到某个数据的最近一次写的数据。

• 弱一致性：数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。

  解决双写一致性方案:

  • 延迟双删
    延迟双删策略是分布式系统中数据库存储和缓存数据保持一致性的常用策略，但它不是强一致。

    实现思路:先删除缓存然后更新DB在最后延迟N秒去再去执行一次缓存删除。

    弊端:小概率会出现不一致情况、耦合程度高

  • 通过MQ进行重试删除
    更新完DB之后进行删除，如果删除失败则向MQ发送一条消息，然后消费者不断进行删除尝试。

  • binlog异步删除
    实现思路:低耦合的解决方案是使用canal。canal伪装成mysql的从机，监听主机mysqlI的二进制文件，当数据发生变化时发送给MQ。最终消费进行删除。

2. 采用旁路缓存模式

如果不想加锁的话，可以采用旁路缓存模式,先更新 db，后删除 cache

理论上来说还是可能会出现数据不一致性的问题，不过概率非常小，因为缓存的写入速度是比数据库的写入速度快很多。举例：请求 1 先读数据 A，请求 2 随后写数据 A，并且数据 A 在请求 1 请求之前不在缓存中的话，也有可能产生数据不一致性的问题。

大概过程是：请求 1 从 db 读数据 A-> 请求 2 更新 db 中的数据 A（此时缓存中无数据 A ，故不用执行删除缓存操作 ） -> 请求 1 将数据 A 写入 cache

在写数据的过程中，可以先删除 cache ，后更新 db 么？

不行，因为这样可能会造成 数据库（db）和缓存（Cache）数据不一致的问题。

举例：请求 1 先写数据 A，请求 2 随后读数据 A 的话，就很有可能产生数据不一致性的问题。

过程如下：请求 1 先把 cache 中的 A 数据删除 -> 请求 2 从 db 中读取数据->请求 1 再把 db 中的 A 数据更新。

如果 Redis 宕机，怎么保证数据库和缓存的一致性

1. 双写策略：在更新数据库时，同时更新 Redis 缓存。这样可以保证数据库和缓存 中的数据保持一致。在 Redis 宕机后，可以通过从数据库中获取数据来保证一致 性。
2. 定时同步数据：定时将数据库中的数据同步到 Redis 缓存中，保证数据库和缓存中的数据保持一致。即使 Redis 宕机，也可以通过定时同步任务来恢复一致性。
3. 使用备份数据：如果 Redis 配置了持久化机制，可以在 Redis 宕机后从持久化文 件中恢复数据，然后重新加载到缓存中。这样可以保证数据库和缓存中的数据一致 性。
4. 使用缓存雪崩方案：在 Redis 宕机后，可以使用缓存雪崩方案，即使用热点数据 预热或者懒加载等方式，来减少对数据库的压力，保证系统的稳定性和可用性。
5. 使用分布式锁：在更新缓存数据时，使用分布式锁来保证数据的一致性。即使 Redis 宕机，也可以通过数据库的更新操作来获取锁并保证数据一致性。
6. 监控和报警：及时监控 Redis 的运行状态，一旦发现 Redis 宕机，立即通知相关 人员进行处理，采取相应的应对措施，以减少数据不一致的影响。

缓存穿透

• 缓存穿透是指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。这种情况大概率是遭到了攻击。

• 使用布隆过滤器来解决缓存穿透：主要是用于检索一个元素是否在一个集合中。

  我们当时使用的是 redisson 实现的布隆过滤器。它的底层主要是先去初始化一个比较大数组，里面存放的二进制 0 或 1。在一开始都是 0，当一个 key 来了之后经过 3 次 hash 计算，模于数组长度找到数据的下标然后把数组中原来的 0 改为 1，这样的话，三个数组的位置就能标明一个 key 的存在。查找的过程也是一样的。

  当然是有缺点的，布隆过滤器有可能会产生一定的误判，我们一般可以设置这个误判率，大概不会超过 5%，其实这个误判是必然存在的，要不就得增加数组的长度，其实已经算是很划分了，5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库。

redis 的内存淘汰机制

• 数据的淘汰策略：当 Redis 中的内存不够用时，此时在向 Redis 中添加新的 key，那么 Redis 就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。

• 这个在 redis 中提供了很多种

  默认是 noeviction，不淘汰任何 key，但是内存满时不允许写入新数据。

  随机淘汰以及 LRU（最少最近使用）

  LFU（最少频率使用）等等。

redis 的 IO 多路复用是什么？

允许 Redis 同时监听多个客户端连接，并在有数据到达时及时处理，提高了 IO 效率和性能。

它通过一种机制来管理和处理多个连接，使得 Redis 能够高效地处理大量客户端请求。

redis为什么采用一主两从+哨兵的集群方案（解决高并发高可用问题）

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

我们项目的redis采用一主二从的集群方案，主节点负责写数据，从节点负责读数据，主节点写入数据之后，需要把数据同步到从节点中，实现了读写分离，解决了高并发问题。

普通的主从模式，当主数据库崩溃时，需要手动切换从数据库成为主数据库:，这就需要人工干预，费事费力，还会造成一段时间内服务不可用，即存在高可用问题。我们又使用了哨兵。哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送ping命令，等待Redis服务器响应，从而监控运行的多个Redis实例。哨兵可以实现自动故障修复，当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换master。同时那台有问题的旧主节点也会变为新主节点的从节点，也就是说当旧的主即使恢复时，并不会恢复原来的主身份，而是作为新主的一个从。

怎么保证Redis的高并发高可用

主从复制保证高并发，哨兵保证高可用

首先可以搭建主从集群，再加上使用redis中的哨兵模式，哨兵模式可以实现主从集群的自动故障恢复，里面就包含了对主从服务的监控、自动故障恢复、通知；如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主；同时Sentinel也充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端，所以一般项目都会采用哨兵的模式来保证redis的高并发高可用。

幂等性校验

幂等性问题：同一个接口，多次发出同一个请求，必须保证操作只执行一次。

解决幂等性问题有很多方法，比如:用防重token,设置提交按钮一段时间只能提交一次，使用唯一索引防止新增脏数据。

幂等性校验具体流程

生成订单时，为了防止重复提交，可以通过Redis结合防重Token和Lua脚本来实现幂等性校验。具体流程如下：

1. 生成Token：用户发起请求时，服务端生成一个唯一的Token，这个Token可以是一个随机字符串或者包含时间戳等信息的凭证。
2. 存储Token：将这个Token存入Redis中，以Token为键，可以设置一个过期时间来自动清理旧的Token，防止Redis内存溢出。
3. 传递Token：将Token返回给客户端，客户端在后续的请求中需要携带这个Token，可以放在Header或者作为请求参数。
4. 校验Token：服务端接收到请求后，从Redis中查询Token。这一步通常通过执行Lua脚本来完成，Lua脚本可以实现原子性的查询并删除操作，确保即使多个请求同时到达，也只有一个请求能够成功删除Token。Lua脚本的作用是检查Redis中是否存在指定的Token，如果存在则删除该Token并返回1，表示校验通过；如果不存在则返回0，表示校验失败。
5. 处理请求：如果Token存在且成功被删除，说明是第一次请求，服务器正常处理业务逻辑，如生成订单。如果Token不存在，说明是重复请求，服务器返回提示信息，如“请勿重复操作”。
6. 删除Token：在处理完请求后，无论成功与否，都从Redis中删除该Token，避免后续的重复校验。

MySQL

约束	描述	关键字
非空约束	限制该字段值不能为null	not null
唯一约束	保证字段的所有数据都是唯一、不重复的	unique
主键约束	主键是一行数据的唯一标识，要求非空且唯一	primary key
默认约束	保存数据时，如果未指定该字段值，则采用默认值	default
外键约束	让两张表的数据建立连接，保证数据的一致性和完整性	foreign key

聚合函数:

函数	功能
count	统计数量
max	最大值
min	最小值
avg	平均值
sum	求和

where与having区别：

1. 执行时机不同：where是分组之前进行过滤，不满足where条件，不参与分组；而having是分组之后对结果进行过滤。
2. 判断条件不同：where不能对聚合函数进行判断，而having可以。

分组之后，查询的字段一般为聚合函数和分组字段，查询其他字段无任何意义。

执行顺序: where > 聚合函数 > having 。

假设我们有一个包含销售记录的表Sales，结构如下：

Id	Product	Amount	Salesperson
1	A	100	John
2	B	200	John
3	A	150	Jane
4	B	300	Jane
5	A	250	John
6	B	400	Jane

使用 WHERE 子句

如果我们想过滤出销售金额大于100的记录，然后按Product分组并计算总销售金额，我们可以这样做：

SELECT Product, SUM(Amount) as TotalAmount
FROM Sales
WHERE Amount > 100
GROUP BY Product;

上述查询先过滤出Amount大于100的记录：

Id	Product	Amount	Salesperson
2	B	200	John
3	A	150	Jane
4	B	300	Jane
5	A	250	John
6	B	400	Jane

然后按Product分组并计算总销售金额：

Product	TotalAmount
A	400
B	900

使用 HAVING 子句

如果我们想计算每个产品的总销售金额，并且只保留总销售金额大于500的产品，我们可以这样做：

SELECT Product, SUM(Amount) as TotalAmount
FROM Sales
GROUP BY Product
HAVING SUM(Amount) > 500;

上述查询先按Product分组并计算总销售金额：

Product	TotalAmount
A	500
B	900

然后使用HAVING子句过滤总销售金额大于500的组：

Product	TotalAmount
B	900

---

1. 一对多
   在多的一方添加外键，关联另外一方的主键。
2. 一对一
   任意一方，添加外键，关联另外一方的主键。
3. 多对多
   通过中间表来维护，中间表的两个外键，分别关联另外两张表的主键

连接查询

内连接：相当于查询A、B交集部分数据 inner join

外连接

​ 左外连接：查询左表所有数据(包括两张表交集部分数据) left join

​ 右外连接：查询右表所有数据(包括两张表交集部分数据) right join

子查询

SQL语句中嵌套select语句，称为嵌套查询，又称子查询。

数据库连接池

是个容器，负责分配、管理数据库连接(Connection)

它允许应用程序重复使用一个现有的数据库连接，而不是再重新建立一个

接口：DataSource; 产品：Druid（德鲁伊）

怎么保证在同时操作多张数据库表出现程序错误时，保证数据的一致性？

我在涉及多表操作时使用了事务（Transaction）： 将涉及到的数据库操作封装在一个事务中。

在事务中，要么所有的数据库操作都成功提交，要么全部失败回滚，保证了数据的一致性。

如果发生异常，可以通过捕获异常并执行回滚操作来保证数据的一致性。
具体操作

在启动类上方添加@EnableTransactionManagement
开启事务注解之后，我们只需要在需要捆绑成为一个事务的方法上添加@Transactional
这样就把对两张表的操作捆绑成为了一个事务。
项目具体用处
在用户下单功能的serviceImpl中
出现的问题是在order表中插入数据成功而因为在orderDetail的mapper.xml中sql语句编写的错误导致orderDetail表中插入数据失败，因此此时需要事务回滚

框架

注解

@RequestParam注解

假设有一个HTTP GET请求URL如下：

http://example.com/api/user?userId=123&userName=John

// 方法形参名称与请求参数名称一致
@GetMapping("/api/user")
public String getUser(@RequestParam("userId") int id, @RequestParam("userName") String name) {
    return "User ID: " + id + ", User Name: " + name;
}

@RequestParam注解用于将HTTP请求中的参数userId和userName分别映射到方法的参数id和name上。

该注解的required属性默认是true，代表请求参数必须传递。

集合参数：请求参数名与形参集合名称相同且请求参数为多个，@RequestParam 绑定参数关系。

@RequestMapping("/listParam")
 public String listParam(@RequestParam List<String> hobby){
   System.*out*.println(hobby);
   return "OK";
 }

@DateTimeFormat 注解

**日期参数：使用 @DateTimeFormat 注解完成日期参数格式转换 **

@RequestMapping("/dateParam")
 public String dateParam(@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss") LocalDateTime updateTime){
   System.*out*.println(updateTime);
   return "OK";
 }

@RequestBody

JSON参数：JSON数据键名与形参对象属性名相同，定义POJO类型形参即可接收参数，需要使用 @RequestBody 标识

@PathVariable

路径参数：通过请求URL直接传递参数，使用{…}来标识该路径参数，需要使用 @PathVariable 获取路径参数

URL：http://localhost:8080/path/100
@RequestMapping("/path/{id}")
 public String pathParam(@PathVariable Integer id){
   System.*out*.println(id);
   return "OK";
 }

URL：http://localhost:8080/path/1/TOM
@RequestMapping("/path/{id}/{name}")
 public String pathParam2(@PathVariable Integer id, @PathVariable String name){
   System.*out*.println(id+ " : " +name);
   return "OK";
 }

@ResponseBody

将方法返回值直接响应，如果返回值类型是 实体对象/集合 ，将会转换为JSON格式响应

@RestControlle

@RestController = @Controller + @ResponseBody ;

@Resource 与 @Autowired区别

@Autowired 是spring框架提供的注解，而@Resource是JDK提供的注解。

@Autowired 默认是按照类型注入，而@Resource默认是按照名称注入。

@ConfigurationProperties 与 @Value

相同点：

都是用来注入外部配置的属性的。

不同点：

@Value注解只能一个一个的进行外部属性的注入。

@ConfigurationProperties可以批量的将外部的属性配置注入到bean对象的属性中。

@RestControllerAdvice

@RestControllerAdvice = @ControllerAdvice + @ResponseBody

全局异常处理器

@Component 及衍生注解 与 @Bean注解使用场景？

@Configuration

声明Bean: 使用@Component注解的类会被Spring自动检测并注册为Bean。在配置文件中不需要显式地定义这个Bean。

自动扫描和注入: Spring会自动扫描使用了@Component注解的类，并将其实例化，放入Spring的应用上下文中。这样，可以使用依赖注入（Dependency Injection, DI）机制来管理对象之间的依赖关系。

如果要管理的bean对象来自于第三方（不是自定义的），是无法用 @Component 及衍生注解声明bean的，就需要用到 @Bean注解。

若要管理的第三方bean对象，建议对这些bean进行集中分类配置，可以通过 @Configuration 注解声明一个配置类。

三层架构

前端NGNIX 后端Tomcat

复用性强、便于维护、利于拓展

• controller：控制层，接收前端发送的请求，对请求进行处理，并响应数据。
• service：业务逻辑层，处理具体的业务逻辑。
• dao：数据访问层(Data Access Object)（持久层），负责数据访问操作，包括数据的增、删、改、查。 Mapper接口

控制反转： Inversion Of Control，简称IOC。对象的创建控制权由程序自身转移到外部（容器），这种思想称为控制反转。

依赖注入： Dependency Injection，简称DI。容器为应用程序提供运行时，所依赖的资源，称之为依赖注入。

Bean对象：IOC容器中创建、管理的对象，称之为bean。

①. Service层 及 Dao层的实现类，交给IOC容器管理。

②. 为Controller及Service注入运行时，依赖的对象。

Bean的声明

要把某个对象交给IOC容器管理，需要在对应的类上加上如下注解之一

注解	说明	位置
@Component	声明bean的基础注解	不属于以下三类时，用此注解
@Controller	@Component的衍生注解	标注在控制器类上
@Service	@Component的衍生注解	标注在业务类上
@Repository	@Component的衍生注解	标注在数据访问类上（由于与mybatis整合，用的少）

• 声明bean的时候，可以通过value属性指定bean的名字，如果没有指定，默认为类名首字母小写。
• 使用以上四个注解都可以声明bean，但是在springboot集成web开发中，声明控制器bean只能用@Controller。

Bean注入

@Autowired注解，默认是按照类型进行，如果存在多个相同类型的bean，将会报出如下错误：

如果同类型的bean存在多个：

@Primary

@Autowired + @Qualifier("bean的名称")

@Resource(name="bean的名称")

默认情况下，Spring项目启动时，会把bean都创建好放在IOC容器中。

bean作用域

作用域	说明
singleton	容器内同 名称 的 bean 只有一个实例（单例）（默认）
prototype	每次使用该 bean 时会创建新的实例（非单例）
request	每个请求范围内会创建新的实例（web环境中，了解）
session	每个会话范围内会创建新的实例（web环境中，了解）
application	每个应用范围内会创建新的实例（web环境中，了解）

可以通过 @Scope 注解来进行配置作用域：

• 默认singleton的bean，在容器启动时被创建，可以使用@Lazy注解来延迟初始化（延迟到第一次使用时）。
• prototype的bean，每一次使用该bean的时候都会创建一个新的实例。
• 实际开发当中，绝大部分的Bean是单例的，也就是说绝大部分Bean不需要配置scope属性。

员工登录流程

1. 前端在登录页面登录，发送请求
2. 进入拦截器，拦截器放行所有登录页面的请求
3. 进入三层架构，查询用户是否存在，若存在，则加密，返回JWT token，存放在请求头部。用户不存在，则不能登录。
4. 当客户端需要访问资源时,通常会在请求头中携带JWT,放置在 Authorization头部中的Bearer字段中。

Spring Task 处理定时任务

Spring Task 是Spring框架提供的任务调度工具，可以按照约定的时间自动执行某个代码逻辑。

在苍穹外卖项目中使用 Spring task

1. 通过定时任务每分钟检查一次是否存在支付超时订单，如果存在则修改订单状态为“已取消”

2. 通过定时任务每天凌晨1点检查一次是否存在“派送中”的订单，如果存在则修改订单状态为“已完成”

应用场景：

• 信用卡每月还款提醒
• 银行贷款每月还款提醒
• 火车票售票系统处理未支付订单
• 入职纪念日为用户发送通知

通过cron表达式可以定义任务触发的时间

Spring事务管理

注解：@Transactional

位置：业务（service）层的方法上、类上、接口上

作用：将当前方法交给spring进行事务管理，方法执行前，开启事务；成功执行完毕，提交事务；出现异常，回滚事务

默认情况下，只有出现 RuntimeException 才回滚异常。rollbackFor属性用于控制出现何种异常类型，回滚事务。

事务传播行为：指的就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行事务控制。propagation

事务属性-传播行为

属性值	含义
REQUIRED	【默认值】需要事务，有则加入，无则创建新事务
REQUIRES_NEW	需要新事务，无论有无，总是创建新事务

• REQUIRED ：大部分情况下都是用该传播行为即可。
• REQUIRES_NEW ：当我们不希望事务之间相互影响时，可以使用该传播行为。比如：下订单前需要记录日志，不论订单保存成功与否，都需要保证日志记录能够记录成功。

AOP

AOP（Aspect-Oriented Programming，面向切面编程）

Controller、Service、Mapper

场景：

案例部分功能运行较慢，定位执行耗时较长的业务方法，此时需要统计每一个业务方法的执行耗时

记录操作日志、权限控制、事务管理

优势：

代码无侵入、减少重复代码、提高开发效率、维护方便

实现：

动态代理是面向切面编程最主流的实现。而SpringAOP是Spring框架的高级技术，旨在管理bean对象的过程中，主要通过底层的动态代理机制，对特定的方法进行编程。

AOP核心概念

连接点：JoinPoint，可以被AOP控制的方法（暗含方法执行时的相关信息）
通知：Advice，指哪些重复的逻辑，也就是共性功能（最终体现为一个方法）
切入点：PointCut，匹配连接点的条件，通知仅会在切入点方法执行时被应用
切面：Aspect，描述通知与切入点的对应关系（通知+切入点）
目标对象：Target，通知所应用的对象

AOP执行流程

通知类型

@Around：环绕通知，此注解标注的通知方法在目标方法前、后都被执行

@Before：前置通知，此注解标注的通知方法在目标方法前被执行

@After ：后置通知，此注解标注的通知方法在目标方法后被执行，无论是否有异常都会执行

@AfterReturning ： 返回后通知，此注解标注的通知方法在目标方法后被执行，有异常不会执行

@AfterThrowing ： 异常后通知，此注解标注的通知方法发生异常后执行

---

@PointCut:

该注解的作用是将公共的切点表达式抽取出来，需要用到时引用该切点表达式即可。

通知顺序

当有多个切面的切入点都匹配到了目标方法，目标方法运行时，多个通知方法都会被执行。

不同切面类中，默认按照切面类的类名字母排序：
1. 目标方法前的通知方法：字母排名靠前的先执行
2. 目标方法后的通知方法：字母排名靠前的后执行
用 @Order(数字) 加在切面类上来控制顺序
1. 目标方法前的通知方法：数字小的先执行
2. 目标方法后的通知方法：数字小的后执行

切入点表达式

切入点表达式：描述切入点方法的一种表达式

作用：主要用来决定项目中的哪些方法需要加入通知

常见形式：

1. execution(……)：根据方法的签名来匹配

2. @annotation(……) ：根据注解匹配

execution(访问修饰符?  返回值  包名.类名.?方法名(方法参数) throws 异常?)

其中带 ? 的表示可以省略的部分

@annotation 切入点表达式，用于匹配标识有特定注解的方法。

@annotation(注解全类名)

AOP案列

• 需要对所有业务类中的增、删、改 方法添加统一功能，使用 AOP 技术最为方便
• 由于增、删、改 方法名没有规律，可以自定义 @Log 注解完成目标方法匹配

场景

网络

MD5加密

将密码加密后存储，提高安全性
使用MD5加密方式对明文密码加密

Tomcat

是一个开源免费的轻量级Web服务器。

Web服务器是一个软件程序，对HTTP协议的操作进行封装，使得程序员不必直接对协议进行操作，让Web开发更加便捷。主要功能是 "提供网上信息浏览服务" 。

nginx反向代理与负载均衡

前端工程基于 nginx 运行

浏览器 http://localhost/api/employee/login --> NGNIX --> http://localhost:8080/admin/employee/login Tomcat

为什么不直接通过浏览器直接请求后台服务端，需要通过nginx反向代理呢?

nginx 反向代理，就是将前端发送的动态请求由 nginx 转发到后端服务器

nginx反向代理的好处:

• 提高访问速度

因为nginx本身可以进行缓存，如果访问的同一接口，并且做了数据缓存，nginx就直接可把数据返回，不需要真正地访问服务端，从而提高访问速度。

• 进行负载均衡

把大量的请求按照我们指定的方式均衡的分配给集群中的每台服务器。

负载策略策略

在nginx的配置文件设置负载均衡策略。

比如轮询，weight权重方式,url分配方式，我们项目用的是轮询方式，共有3台后端服务器。

• 保证后端服务安全

因为一般后台服务地址不会暴露，所以使用浏览器不能直接访问。

可以把nginx作为请求访问的入口，请求到达nginx后转发到具体的服务中，从而保证后端服务的安全。

• 正向代理：

  正向代理是客户端发送请求后通过代理服务器访问目标服务器，代理服务器代表客户端发送请求并将响应返回给客户端。正向代理隐藏了客户端的真实身份和位置信息，为客户端提供代理访问互联网的功能。

  正向代理：用来代理客户端，对服务器发起请求，服务器不知道哪个客户端发来的请求，只清楚是代理服务器发过来的

  eg：我们常用的魔法；

• 反向代理：

  反向代理是指代理服务器接收客户端的请求，然后将请求转发给后端服务器，并将后端服务器的响应返回给客户端。反向代理隐藏了服务器的真实身份和位置信息，客户端只知道与反向代理进行通信，而不知道真正的服务器。

​ 反向代理：代理服务器将服务端的服务器隐藏起来，充当代理，客户端的请求会发送到代理服务器上。

session和cookie区别

彻底了解Cookie和Session的区别（面试）_session和cookie的区别-CSDN博客

Cookie和Session都是用于在Web应用中跟踪用户状态的技术。

1. 存储位置：Cookie是存储在客户端浏览器中的小型文本文件，而Session是存储在服务器端的一段内存空间。
2. 生命周期：Cookie的生命周期可以是长期的，甚至可以设置为几年，或者直到用户手动删除为止。相比之下，Session的生命周期通常较短，当用户关闭浏览器或者会话超时后，Session就会失效。
3. 数据容量：Cookie由于存储在客户端，其容量受到浏览器的限制，一般较小（4KB左右）。Session存储在服务器端，因此可以存储更多的数据。
4. 安全性：Session因为存储在服务器端，相对于Cookie来说更安全，不容易被篡改。Cookie中的信息可能会被截获或修改，存在一定的安全风险。
5. 性能影响：使用Session时，每个用户的会话信息都保存在服务器内存中，如果用户数量非常多，可能会对服务器性能产生影响。而Cookie则不会直接影响服务器性能。
6. 适用场景：Cookie适用于需要长期跟踪用户偏好的情况，如记住登录状态、购物车信息等。Session适用于需要在服务器端临时保存用户状态的场景，如在线考试、购物流程中等。

Session 的工作原理

1. 创建会话：

   • 当用户第一次访问 Web 应用时，服务器创建一个新的 Session 对象，并生成一个唯一的 Session ID。

2. 存储会话数据：

   • 服务器将与用户相关的数据存储在 Session 对象中，并将 Session 对象存储在服务器端存储介质中（如内存、数据库、缓存等）。

3. 发送 Session ID：

   • 服务器将 Session ID 通过 HTTP 响应发送给客户端，通常使用 Cookie 来保存 Session ID。

4. 会话保持：

   • 在后续请求中，客户端会将 Session ID 通过 Cookie 发送给服务器，服务器根据 Session ID 找到对应的 Session 数据，从而保持会话状态。

JWT优点

为什么不用Session用JWT

传统的Session用户认证方案:

1. 用户向服务器发送用户名和密码。
2. 服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
3. 服务器向用户返回一个 session_id，写入用户的 Cookie。
4. 用户随后的每一次请求，都会通过 Cookie将 session_id 传回服务器。
5. 服务器收到 session_id，找到对应的session并获取前期保存的数据，由此得知用户的身份。

传统的通过session的方式适用于前后端不分离的情况，因为session是保存在服务器端，因此对于跨域或服务器集群的情况很不友好。

为了解决传统用户认证的问题，就出现了JWT(JSON Web Token)这一种方案。

可以简单的理解为session变为了保存在客户端而不是保存在服务器端了，用户每次请求都会携其内容。因此也就解决了跨域问题。

jwt的优点:

1. jwt基于json，数据处理方便。
2. 可以在令牌（token）中自定义内容，容易扩展。
3. 使用非对称加密和签名技术，安全性高。
4. 资源服务使用JWT，可不依赖认证服务即可完成授权。

jwt缺点:JWT令牌较长，占用存储空间较大。

JWT

Header 和 Payload 都是 JSON 格式的数据，Signature 由 Payload、Header 和 Secret(密钥)通过特定的计算公式和加密算法得到。

JWT 是目前最流行的跨域认证解决方案，是一种基于 Token 的认证授权机制。 从 JWT 的全称可以看出，JWT 本身也是 Token，一种规范化之后的 JSON 结构的 Token。

JWT 自身包含了身份验证所需要的所有信息，因此，我们的服务器不需要存储 Session 信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力。

Header 通常由两部分组成：

• typ（Type）：令牌类型，也就是 JWT。
• alg（Algorithm）：签名算法，比如 HS256。

如何基于 JWT 进行身份验证

在基于 JWT 进行身份验证的的应用程序中，服务器通过 Payload、Header 和 Secret(密钥)创建 JWT 并将 JWT 发送给客户端。客户端接收到 JWT 之后，会将其保存在 Cookie 或者 localStorage 里面，以后客户端发出的所有请求都会携带这个令牌。

①登录成功后，生成令牌

②后续每个请求，都要携带JWT令牌，系统在每次请求处理之前，先校验令牌，通过后，再处理

简化后的步骤如下：

1. 用户向服务器发送用户名、密码以及验证码用于登陆系统。
2. 如果用户用户名、密码以及验证码校验正确的话，服务端会返回已经签名的 Token，也就是 JWT。
3. 用户以后每次向后端发请求都在 Header 中带上这个 JWT 。
4. 服务端检查 JWT 并从中获取用户相关信息。

两点建议：

1. 建议将 JWT 存放在 localStorage 中，放在 Cookie 中会有 CSRF 风险。
2. 请求服务端并携带 JWT 的常见做法是将其放在 HTTP Header 的 Authorization 字段中（Authorization: Bearer Token）。

在登录校验中，JWT发挥了什么作用?

1. 先检查有无令牌，没有令牌就没登录，去登录。
2. 登录后才有令牌，有令牌，再校验，无效了再去登录

ThreadLocal存储用户id

用户登录 – 认证通过 – 生成jwt token返回给前端 – 前端发起请求时携带token – 拦截器请求验证token – 放行/不放行

客户端发起的每一次请求都是一个单独的线程
拦截器验证通过 将用户id通过TreadLocal放入内存，在serviceImpl阶段使用时从内存中拿出获取用户id

使用JWT令牌技术及使用，用自定义拦截器(使用方法)完成用户认证，通过ThreadLocal优化鉴权逻辑。

详细解释:

这句话描述了一种使用JWT令牌技术进行用户认证的方法，并通过自定义拦截器和ThreadLocal来优化鉴权逻辑。

1. JWT（JSON Web Token）一种用于在网络应用间传递信息的安全方式。

   由三部分组成：头部、载荷和签名。

   用户在登录成功后，服务器会生成一个JWT令牌并返回给客户端。

   客户端在后续的请求中将该令牌携带在请求的Authorization头部中。

2. 自定义拦截器是一种在请求到达处理程序之前或之后执行特定功能的机制。

   自定义拦截器可以用于验证请求中的JWT令牌的有效性和完整性。

   如果JWT令牌有效，则允许请求继续进行处理，否则拒绝请求或返回错误响应。

3. 优化鉴权逻辑怎样做？可以使用ThreadLocal。

   ThreadLocal是Java中的一个线程级别的变量，它可以在当前线程中存储数据，并且只有当前线程可以访问和修改这些数据。

   可以使用ThreadLocal来存储解析后的JWT令牌中的用户信息，例如用户ID、角色等。这样，在后续的请求处理过程中，可以直接从ThreadLocal中获取用户信息，避免了多次解析JWT令牌的性能开销。

---

jwt和过滤器解决了什么问题？ 答：登录校验 -> 只有登陆后才能进行后续操作

介绍单点登录的解决方案，以JWT为例

1. 用户访问其他系统，会在网关判断token是否有效
2. 如果token无效则会返回401（认证失败）前端跳转到登录页面
3. 用户发送登录请求，返回浏览器一个token，浏览器把token保存到cookie
4. 再去访问其他服务的时候，都需要携带token，由网关统一验证后路由到目标服务

JWT登录流程

使用JWT令牌和自定义拦截器完成用户认证的流程如下：

1. 用户登录时，客户端发送用户名和密码给服务器向服务器请求令牌,服务器验证用户的用户名和密码。如果验证成功，服务器生成一个包含用户信息的JWT令牌，并将其发送给客户端。
2. 客户端收到JWT令牌后，将其存储在本地（例如localStorage或cookie）。
3. 当客户端发起请求时，将JWT令牌添加到请求头中
4. 服务器端的自定义拦截器会拦截所有请求，从请求头中提取JWT令牌。
5. 拦截器解析JWT令牌，获取用户信息，并将其存储在ThreadLocal中,以避免在每次请求时都去解析JWT令牌。
6. 拦截器可以检查用户是否已经通过认证。如果用户未通过认证，拦截器将拒绝请求并返回相应的错误信息。如果用户已通过认证，拦截器将继续处理请求，并将用户信息传递给后续的处理逻辑。
7. 请求处理完成后，拦截器使用remove()清除ThreadLocal中的用户信息，以避免内存泄漏。

过滤器Filter

Filter 过滤器，是 JavaWeb 三大组件(Servlet、Filter、Listener)之一。

过滤器可以把对资源的请求拦截下来，从而实现一些特殊的功能。

过滤器一般完成一些通用的操作，比如：登录校验、统一编码处理、敏感字符处理等。

1. 定义Filter：定义一个类，实现 Filter 接口，并重写其所有方法。

2. 配置Filter：Filter类上加 @WebFilter 注解，配置拦截资源的路径。引导类上加 @ServletComponentScan 开启Servlet组件支持

拦截路径	urlPatterns值	含义
拦截具体路径	/login	只有访问 /login 路径时，才会被拦截
目录拦截	/emps/*	访问/emps下的所有资源，都会被拦截
拦截所有	/*	访问所有资源，都会被拦截

• 所有的请求，拦截到了之后，都需要校验令牌吗？有一个例外，登录请求
• 拦截到请求后，什么情况下才可以放行，执行业务操作？有令牌，且令牌校验通过（合法）；否则都返回未登录错误结果

登录校验Filter-流程

1. 获取请求url。
2. 判断请求url中是否包含login，如果包含，说明是登录操作，放行。
3. 获取请求头中的令牌（token）。
4. 判断令牌是否存在，如果不存在，返回错误结果（未登录）。
5. 解析token，如果解析失败，返回错误结果（未登录）。
6. 放行。

拦截器Interceptor

概念：是一种动态拦截方法调用的机制，类似于过滤器。Spring框架中提供的，用来动态拦截控制器方法的执行。

作用：拦截请求，在指定的方法调用前后，根据业务需要执行预先设定的代码。

拦截路径	含义	举例
/*	一级路径	能匹配/depts，/emps，/login，不能匹配 /depts/1
/**	任意级路径	能匹配/depts，/depts/1，/depts/1/2
/depts/*	/depts下的一级路径	能匹配/depts/1，不能匹配/depts/1/2，/depts
/depts/**	/depts下的任意级路径	能匹配/depts，/depts/1，/depts/1/2，不能匹配/emps/1

登录校验Interceptor

1. 获取请求url。
2. 判断请求url中是否包含login，如果包含，说明是登录操作，放行。
3. 获取请求头中的令牌（token）。
4. 判断令牌是否存在，如果不存在，返回错误结果（未登录）。
5. 解析token，如果解析失败，返回错误结果（未登录）。
6. 放行。

拦截器

拦截器的作用是校验JWT令牌 并将用户id通过ThreadLocal放入内存。

ThreadLocal

在对 JWT 令牌进行解析，获得当前请求的用户 ID 以后将该 ID 保存至 ThreadLocal 中，以便在之后的操作中查看当前用户。

ThreadLocal 并不是一个Thread，而是Thread的局部变量。

ThreadLocal为每个线程提供单独一份存储空间，具有线程隔离的效果，只有在线程内才能获取到对应的值，线程外则不能访问，以保证线程安全。

为什么要用ThreadLocal？

ThreadLocal是 Java中的一个类，用于在多线程环境下保存线程局部变量。

它提供了一种线程安全的方式，让每个线程都拥有自己独立的变量副本，从而避免了线程间的数据共享和竞争。

使用ThreadLocal是来存储在多个方法中需要共享的数据，具体来说就是项目中的用户ld，其他方法需要调用这个参数，我们就不用显示传递给它了。

注意：客户端发送的每次请求，后端的Tomcat服务器都会分配一个单独的线程来处理请求

Threadlocal的底层原理。

【黑马程序员Java基础教程由浅入深全面解析threadlocal】 https://www.bilibili.com/video/BV1N741127FH/?share_source=copy_web&vd_source=f53af8c9157589f9aac8ed85ad47fba5

1. ThreadLocalMap：每个线程内部都有一个ThreadLocalMap对象，用于存储线程本地变量。ThreadLocalMap是一个Entry数组，每个Entry包含了一个ThreadLocal对象和对应的值。当通过ThreadLocal对象设置或获取值时，实际上是在当前线程的ThreadLocalMap中进行操作。

2. ThreadLocal：ThreadLocal类提供了访问线程本地变量的方法，并且每个ThreadLocal实例都是线程独立的。当使用ThreadLocal的set()方法设置值时，会将当前ThreadLocal对象作为key，值作为value存储到当前线程的ThreadLocalMap中；使用get()方法获取值时，会根据当前ThreadLocal对象在ThreadLocalMap中查找对应的值。

3. 具体的实现原理可以简单描述为：每个线程都有自己的ThreadLocalMap对象，用于存储线程本地变量；通过ThreadLocal对象设置或获取值时，实际上是通过ThreadLocal对象在ThreadLocalMap中寻找对应的值。由于每个线程有自己独立的ThreadLocalMap，所以不同线程之间的ThreadLocal变量不会相互干扰，保证了线程之间的数据隔离性。

4. 总的来说，ThreadLocal通过利用每个线程内部的ThreadLocalMap来实现线程本地变量的存储和访问，从而实现了线程间数据的隔离，避免了多线程环境下的数据共享问题。

ThreadLocal 的底层原理是通过一个ThreadLocalMap来实现的，类似于HashMap。在每个线程中都有一个ThreadLocalMap，用于存储线程局部变量。ThreadLocalMap中的键是ThreadLocal对象，值是对应线程的变量副本。当一个线程需要获取变量值时.它首先会获取自己线程的ThreadLocalMap，并根据 ThreadLocal 对象获取对应的变量副本。这样就实现了每个线程都拥有自己独立的变量副本，互不影响。这样可以保证线程之间的数据隔离，避免了线程安全问题。

用ThreadLocal出现脏读，变量是怎么清除 ?

脏读是? 脏读是如何造成的?

当使用ThreadLocal来存储数据时，每个线程都有自己的ThreadLocal副本，这意味着不同线程中的ThreadLocal变量是相互隔离的。

这种特性使得ThreadLocal非常适合在多线程环境下存储线程相关的数据，例如用户身份信息、数据库连接等。

然而，如果在使用ThreadLocal存储数据后没有及时清除，就可能导致脏读问题和内存泄漏。

具体来说，如果在处理完某个请求或任务后没有清除ThreadLocal中的数据，那么下一个请求或任务可能会复用同一个线程，此时ThreadLocal中仍然保留着上一次请求或任务的数据，从而可能导致下一个请求或任务读取到错误的数据，称为脏读。

另外，如果长时间保留大量数据在ThreadLocal中而不清除，就可能导致内存泄漏问题。因为即使线程执行完毕，ThreadLocal中的数据仍然保留在内存中，不会被自动清理，如果这种情况持续发生，就会造成内存资源的浪费和性能问题。

因此，为了避免脏读问题和内存泄漏，需要在合适的时机手动调用ThreadLocal.remove()方法来清除ThreadLocal中的数据。这样可以确保每个请求或任务开始时ThreadLocal中不会包含上一次请求或任务的数据，从而保证了数据的独立性和正确性。

变量是怎么清除的?

在Java中，可以使用ThreadLocal.remove()方法来清除ThreadLocal变量。

当使用ThreadLocal存储数据时，每个线程都有自己的ThreadLocal副本，并且在不需要时应该及时清除，以避免脏读、内存泄漏或其他问题。

在处理完某个请求或任务后，需要手动调用ThreadLocal.remove()来清除ThreadLocal中的数据，确保不会影响下一次请求或任务的数据处理过程。这样可以有效地避免脏读问题和内存泄漏。

另外，确保在使用ThreadLocal存储数据时，要在合适的地方进行初始化和清理，避免数据残留造成意外的影响。

ThreadLocal-内存泄露问题是怎么导致的？

每个线程都有⼀个ThreadLocalMap的内部属性，map的key是ThreaLocal，定义为弱引用，value是强引用类型。垃圾回收的时候会⾃动回收key，而value的回收取决于Thread对象的生命周期。一般会通过线程池的方式复用线程节省资源，这也就导致了线程对象的生命周期比较长，这样便一直存在一条强引用链的关系：Thread --> ThreadLocalMap-->Entry-->Value，随着任务的执行，value就有可能越来越多且无法释放，最终导致内存泄漏。

解决⽅法：每次使⽤完ThreadLocal就调⽤它的remove()⽅法，手动将对应的键值对删除，从⽽避免内存泄漏

Java对象中的四种引用类型：强引用、软引用、弱引用、虚引用

• 强引用：最为普通的引用方式，表示一个对象处于有用且必须的状态，如果一个对象具有强引用，则GC并不会回收它。即便堆中内存不足了，宁可出现OOM，也不会对其进行回收
• 弱引用：表示一个对象处于可能有用且非必须的状态。在GC线程扫描内存区域时，一旦发现弱引用，就会回收到弱引用相关联的对象。对于弱引用的回收，无关内存区域是否足够，一旦发现则会被回收

浮点数精度丢失问题考虑过吗？ 浮点数为什么会精度丢失？如何解决精度丢失问题？

【黑马程序员Java项目实战微服务项目《黑马头条》开发全套视频教程，基于SpringBoot+SpringCloud+Nacos等企业级微服务架构项目解决方案- long类型****精度丢失问题解决】

https://www.bilibili.com/video/BV1Qs4y1v7x4/?p=132&share_source=copy_web&vd_source=f53af8c9157589f9aac8ed85ad47fba5

那么，后端传给前端，这个数字的精度会丢失。

【JavaScript浮点精度丢失问题 - Web前端工程师面试题讲解】 https://www.bilibili.com/video/BV1Ji4y1t7DY/?share_source=copy_web&vd_source=f53af8c9157589f9aac8ed85ad47fba5

浮点数精度丢失问题是什么？浮点数为什么会精度丢失？

浮点数精度丢失问题是指在计算机中使用浮点数表示实数时，由于浮点数的存储方式和精度有限，导致一些实数无法被准确表示，从而造成计算结果的误差。

这种精度丢失问题主要源于计算机采用二进制形式表示浮点数，而很多带浮点的实数在二进制下是无限循环的，无法精确表示。因此，在进行浮点数计算时，可能会出现舍入误差和截断误差，最终影响计算结果的准确性。

如何解决精度丢失问题？

在Java中，开发者可以使用BigDecimal类来实现高精度的浮点数运算，从而减少精度丢失的可能性。BigDecimal类提供了任意精度的十进制数值表示，并支持基本的算术运算。 Decimal (十进制)

以下是一个简单的示例，展示如何在Java中使用BigDecimal类进行高精度计算：

javaCopy Codeimport java.math.BigDecimal;

public class HighPrecisionCalculation {
    public static void main(String[] args) {
        BigDecimal num1 = new BigDecimal("0.1");
        BigDecimal num2 = new BigDecimal("0.2");

        // 使用BigDecimal进行加法运算
        BigDecimal result = num1.add(num2);

        System.out.println("Result of addition: " + result);
    }
}

在这个示例中，我们使用BigDecimal类创建了两个BigDecimal对象来表示0.1和0.2这两个浮点数。然后，通过调用add()方法进行加法运算，得到了精确的结果。相比使用普通的浮点数类型（如double）进行计算，使用BigDecimal类可以避免由于浮点数精度问题引起的误差。

工具

Swagger 作用

使用Swagger你只需要按照它的规范去定义接口及接口相关的信息，就可以做到生成接口文档，以及在线接口调试页面。

Knife 4 j

Knife4j是为Java MVC框架集成Swagger生成Api文档的增强解决方案。

通过 Swagger 就可以生成接口文档，就不需要 Yapi 了？

1、Yapi 是设计阶段使用的工具，管理和维护接口

2、Swagger 在开发阶段使用的框架，帮助后端开发人员做后端的接口测试

什么是 Httpclient

HttpClient是Apache的一个子项目，是高效的、功能丰富的支持HTTP协议的客户端编程工具包。

HttpClient作用：

• 发送HTTP请求
• 接收响应数据

Pagehelper 如何实现分页查询？

PageHelper是MyBatis的一个插件，内部实现了一个PageInterceptor拦截器。Mybatis会加载这个拦截器到拦截器链中。在我们使用过程中先使用PageHelper.startPage这样的语句在当前线程上下文中设置一个ThreadLocal变量，再利用PageInterceptor这个分页拦截器拦截，从ThreadLocal中拿到分页的信息，如果有分页信息拼装分页SQL（limit语句等）进行分页查询，最后再把ThreadLocal中的东西清除掉。

1. 设置分页参数：在执行查询之前，首先通过 PageHelper.startPage(int pageNum, int pageSize) 方法设置分页的参数，调用该方法时，通过 ThreadLocal 存储分页信息。
2. 拦截查询语句：PageHelper 利用 MyBatis 提供的插件 API（Interceptor 接口）来拦截原始的查询语句。MyBatis 执行任何 SQL 语句前，都会先通过其插件体系中的拦截器链，PageHelper 正是在这个环节介入的。
3. 修改原始 SQL 语句：在拦截原始查询语句后，PageHelper 会根据分页参数动态地重写或添加 SQL 语句，使其成为一个分页查询。
4. 执行分页查询：修改后的 SQL 语句被执行，返回当前页的数据。
5. 查询总记录数（可选）：如果需要获取总记录数，PageHelper 会自动执行一个派生的查询，以计算原始查询（不包含分页参数）的总记录数。这通常通过移除原始 SQL 的排序（ORDER BY）和分页（LIMIT、OFFSET 等）条件，加上 COUNT(*) 的包装来实现。
6. 返回分页信息：查询结果被封装在 PageInfo 对象中（或其他形式的分页结果对象），这个对象除了包含当前页的数据列表外，还提供了总记录数、总页数、当前页码等分页相关的信息，方便在应用程序中使用。

公共字段自动填充（涉及到枚举，注解，AOP，反射

问题：代码冗余、不便于后期维护

• 自定义注解 AutoFill，用于标识需要进行公共字段自动填充的方法

• 自定义切面类 AutoFillAspect，统一拦截加入了 AutoFill 注解的方法，通过反射为公共字段赋值

• 在 Mapper 的方法上加入 AutoFill 注解

技术点：枚举、注解、AOP、反射

后端如何与商家端建立链接，实现实时通信？

WebSocket 是一种在 Web 应用程序中实现双向通信的协议。它允许客户端和服务器之间建立持久的、双向的通信通道，使得服务器可以主动向客户端推送消息，而无需客户端发送请求。
客户端和服务器之间可以实时地发送消息和接收消息，不需要频繁地发起请求。这样可以减少网络流量和延迟，并提供更好的用户体验。

相比传统的 HTTP请求-响应模式，WebSocket的持久连接减少了每次通信的开销。不需要在每次通信时都重新建立连接，减少了通信的延迟和资源消耗。

在我们项目中就是支持用户端以及商家管理端与服务器进行双向通信。

通过WebSocket实现管理端页面和服务端保持长连接状态

用户下单并且支付成功后，需要第一时间通知外卖商家。
来单提醒

用户在小程序中点击催单按钮后，需要第一时间通知外卖商家。
客户催单

Websocket 与 HTTP 区别？

WebSocket 是基于 TCP 的一种新的网络协议。

实现了浏览器与服务器全双工通信—浏览器和服务器只需要完成一次握手，两者之间就可以创建持久性的连接， 并进行双向数据传输。

HTTP 协议和 WebSocket 协议对比：

• HTTP 是短连接、WebSocket 是长连接

• HTTP 通信是单向的，基于请求响应模式；WebSocket 支持双向通信

• HTTP 和 WebSocket 底层都是 TCP 连接

应用场景：

• 视频弹幕
• 网页聊天
• 体育实况更新
• 股票基金报价实时更新

可以基于 WebSocket 开发所有的业务功能？

WebSocket缺点：

• 服务器长期维护长连接需要一定的成本
• 各个浏览器支持程度不一
• WebSocket 是长连接，受网络限制比较大，需要处理好重连

结论：WebSocket并不能完全取代HTTP，它只适合在特定的场景下使用

Apache POI

Apache POI 是一个处理Miscrosoft Office各种文件格式的开源项目。

简单来说就是，我们可以使用 POI 在 Java 程序中对Miscrosoft Office各种文件进行读写操作。
一般情况下，POI 都是用于操作 Excel 文件。

导出运营数据Excel报表

SpringCache

项目中的应用

存在问题： 用户端小程序展示的菜品数据都是通过查询数据库获得，如果用户端访问量比较大，数据库访问压力随之增大。
结果： 系统响应慢、用户体验差
通过Redis来缓存菜品数据，减少数据库查询操作。
Spring Cache 是一个框架，实现了基于注解的缓存功能，只需要简单地加一个注解，就能实现缓存功能=。

具体的实现思路如下：
1. 导入Spring Cache和Redis相关maven坐标
2. 在启动类上加入@EnableCaching注解，开启缓存注解功能
3. 在用户端接口SetmealController的 list 方法上加入@Cacheable注解
4. 在管理端接口SetmealController的 save、delete、update、startOrStop等方法上加入CacheEvict注解

springboot 全局异常处理器

软件开发springboot项目过程中，不可避免的需要处理各种异常，spring mvc架构中各层会出现大量的try{...} catch{...} finally{...} 代码块，不仅有大量的冗余代码，而且还影响代码的可读性。这样就需要定义个全局统一异常处理器，以便业务层再也不必处理异常。

@ControllerAdvice注解可以把异常处理器应用到所有控制器，而不是单个控制器。借助该注解，我们可以实现:在独立的某个地方，比如单独的一个类，定义一套对各章异常的处理机制，然后在类的签名加上注解@ControllerAdvice，统一对不同阶段的，不同异常进行处理。这就是统一异常处理的原理。

Apache ECharts

Apache ECharts 是一款基于 Javascript 的数据可视化图表库，提供直观，生动，可交互，可个性化定制的数据可视化图表。

lombok

Lombok是一个实用的Java类库，能通过注解的形式自动生成构造器、getter/setter、equals、hashcode、toString等方法，并可以自动化生成日志变量，简化java开发、提高效率。

你在项目中遇到了什么困难？

解决前端时间属性显示问题

解决新增员工时，创建人id和修改人id都为固定值的问题

处理分页查询问题

处理公共字段的填充

设计模式

怎么用的设计模式？

使用工厂模式和策略模式实现布隆过滤器的大概流程如下：

1. 定义布隆过滤器接口：首先定义一个布隆过滤器接口，包括添加元素和判断元素是否存在两个基本操作。
2. 实现具体的布隆过滤器类：创建一个具体的布隆过滤器类，实现布隆过滤器接口中的方法。在这个类中，需要定义布隆过滗器的数据结构（比如位数组）、大小等属性。
3. 定义哈希策略接口：定义一个哈希策略接口，包含计算哈希值的方法。
4. 实现具体的哈希策略类：创建多个具体的哈希策略类，实现哈希策略接口中的方法，每个类对应一种哈希函数的计算方法。
5. 创建布隆过滤器工厂类：定义一个布隆过滤器工厂类，其中包含一个用于创建布隆过滤器对象的工厂方法。工厂方法接受布隆过滤器的大小和哈希策略对象作为参数，并返回一个具体的布隆过滤器对象。
6. 使用布隆过滤器工厂：在需要创建布隆过滤器对象的地方，调用布隆过滤器工厂的工厂方法来创建布隆过滤器对象，并传入相应的哈希策略对象。

使用工厂和策略设计模式的好处？

使用工厂模式和策略模式来实现布隆过滤器带来以下好处：

1. 解耦性：工厂模式和策略模式的结合可以将对象的创建和哈希函数的选择分离，使得各部分之间的耦合度降低。这样在需要修改布隆过滤器的具体实现或者切换哈希函数时，只需要修改相应的工厂类或策略类，而不影响其他部分。
2. 可扩展性：通过工厂模式和策略模式，我们可以方便地添加新的布隆过滤器实现类和哈希函数策略类，而不需要修改现有代码。这样在需要增加新的布隆过滤器类型或者新的哈希函数时，只需添加相应的类即可。
3. 代码复用：工厂模式和策略模式可以提高代码的复用性。通过工厂模式，我们可以在不同地方调用工厂方法来创建布隆过滤器对象，避免重复的创建逻辑。通过策略模式，不同的哈希函数策略可以被多个布隆过滤器共享使用。
4. 易于维护：将对象的创建和哈希函数的选择分开管理，使得代码结构清晰，易于维护和理解。当需要修改布隆过滤器的实现或者哈希函数时，只需修改相应的工厂类或策略类，而不会对其他部分造成影响。

点评

https://www.hongxiac.com/docs/redis/hmdp-interview-v1.html

1.Redis哪些数据结构？选择原因

在这个项目中，我使用了Redis的以下数据结构：

String：用于存储短信验证码、用户信息等简单的键值对数据。

Hash：用于存储商家信息、优惠券信息等结构化数据。

List：用于存储点赞列表、消息队列等有序列表数据。

Set：用于存储用户关注列表、共同关注列表等无序集合数据。

Sorted Set：用于存储点赞排行榜、优惠券领取排行榜等有序集合数据。

Geo：用于存储商家的地理位置信息，实现附近商家查询和按距离排序。

HyperLogLog：统计1天内同一个用户多次访问该网站，只记录1次。

BitMap：通过位运算来实现用户签到，而无需使用循环遍历等操作，从而提高计算效率。

我选择这些数据结构的原因是它们能够很好地满足项目中的需求，比如String可以用于存储简单的键值对数据，Hash可以用于存储结构化数据，List可以用于存储有序列表数据等等。同时，这些数据结构在Redis中的实现也非常高效，能够满足高并发的需求。

2.优惠卷秒杀中，使用Lua脚本，解释原理和优势？

需要在Redis中执行一些复杂的操作时，

比如需要对多个键进行操作，或者需要进行一些复杂的计算，使用Lua脚本可以帮助我们实现这些操作。

Lua脚本是一种脚本语言，它可以在Redis中直接执行。在执行Lua脚本时，Redis会将脚本发送给Lua解释器进行解释和执行，然后将执行结果返回给Redis。

使用Lua脚本的优势主要有以下几点：

原子性：Lua脚本可以保证多个Redis命令的原子性，避免了在多个命令之间出现竞态条件的问题。

高性能：由于Lua脚本是在Redis服务器端执行的，所以可以减少网络传输的开销，提高执行效率。

灵活性：Lua脚本可以实现复杂的逻辑，可以对多个键进行操作，可以进行复杂的计算，可以实现更加灵活的业务逻辑。

在优惠卷秒杀部分，我使用Lua脚本来实现 库存预检 和 订单异步 创建。

具体来说，我使用Lua脚本来对优惠券的库存进行预检，避免了超卖的问题；同时，我使用Lua脚本来将订单信息写入消息队列，实现了订单的异步创建，提高了系统的并发能力和性能。

3.在附近的商户部分，使用GeoHash数据结构来存储地理坐标，解释一下原理和应用场景

当我们需要对地理位置进行排序或者查询时，传统的关系型数据库往往无法满足我们的需求。

而Redis的GeoHash数据结构则可以很好地解决这个问题。

GeoHash是一种将 二维的经纬度坐标 转换为 一维的字符串编码 的方法。它将地球表面划分为多个矩形区域，并为每个矩形区域分配一个唯一的字符串编码。这样，我们就可以将地理位置转换为字符串，然后使用字符串比较的方式来进行排序和查询。

使用GeoAdd命令将地理位置添加到GeoHash数据结构中

使用GeoRadius命令按距离排序查询附近的地理位置

使用GeoHash命令获取地理位置的GeoHash值等等。

GeoHash的应用场景非常广泛，比如附近的商户查询、地理位置推荐、地理位置统计等等。

它可以帮助我们更方便地处理地理位置相关的业务需求，提升系统的性能和用户体验。

4.缓存的更新策略和缓存的失效机制？

当我们使用Redis来缓存数据时，需要考虑缓存的更新策略和缓存的失效机制，以保证缓存数据的及时性和准确性。

缓存的更新策略

业务场景：

• 低一致性需求：使用内存淘汰机制。例如店铺类型的查询缓存
• 高一致性需求：主动更新，并以超时剔除作为兜底方案。例如店铺详情查询的缓存

主动更新策略

Cache Aside：由缓存的调用者，在更新数据库的同时更新缓存

• 更新缓存还是删除缓存？

  • 更新缓存会产生无效更新，并且存在较大的线程安全问题（如果对数据进行了上百次修改，则数据库和Redis都要进行修改，如果这是是写多少的场景，则是对缓存做的都是无效的操作）
  • 删除缓存本质是延迟更新，没有无效更新，线程安全问题相对较低

• 先操作数据库还是缓存？

  • 先更新数据库，再删除缓存
    • 在满足原子性的情况下，安全问题概率较低
  • 先删除缓存，再更新数据库
    • 安全问题概率较高（1删除缓存较快，4更新数据库较慢，2查询缓存，3写入缓存较快）

• 如何确保数据库与缓存操作原子性？

  • 单体系统

    • 利用事务机制

  • 分布式系统

    • 利用分布式事务机制

5.在好友关注部分，使用了Redis的Set数据结构来实现关注和取消关注，如何处理大量的关注和取消关注操作？

当处理大量的关注和取消关注操作时，Redis的Set数据结构可能会出现性能瓶颈。

考虑使用Redis的HyperLogLog数据结构来进行去重，这样可以减少Set数据结构的大小，提高性能。

同时，可以使用Redis的Lua脚本来批量处理关注和取消关注操作，减少网络开销和Redis的调用次数。

此外，可以使用Redis的Pipeline功能来批量执行多个操作，进一步提高性能。

最后，可以使用Redis的持久化功能来保证数据的可靠性和持久性。

6.在达人探店部分，使用Redis的Pub/Sub功能来实现点赞列表的实时更新，如何处理大量的点赞操作和实时更新的性能问题？

当处理大量的点赞操作和实时更新时，Redis的Pub/Sub功能可能会出现性能瓶颈。

使用Redis的 Stream数据结构 来存储点赞信息，将点赞时间作为ID，点赞用户ID和被点赞用户ID作为字段，这样可以实现按时间排序的功能，并且可以支持多个消费者同时消费。

同时，可以使用Redis的Pipeline技术来批量执行点赞操作和实时更新操作，减少网络开销和Redis的响应时间。

另外，可以考虑使用Redis的Lua脚本来实现复杂的点赞逻辑，减少网络传输和Redis的响应时间。

最后，可以使用Redis的持久化功能来保证数据的可靠性和持久性。

7.缓存击穿、缓存穿透、缓存雪崩

缓存击穿：

指缓存中不存在但数据库中存在的数据，这时大量请求会直接打到数据库上，导致数据库压力过大。

缓存击穿问题也叫热点Key问题，一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击

解决方案：

• 互斥锁

  使用互斥锁或分布式锁，保证只有一个线程去查询数据库，其他线程等待查询结果。同时，可以设置短期内的缓存过期时间，避免缓存失效后大量请求打到数据库上。

  核心思路：相较于原来从缓存中查询不到数据后直接查询数据库而言，现在的方案是 进行查询之后，如果从缓存没有查询到数据，则进行互斥锁的获取，获取互斥锁后， 判断是否获得到了锁，如果没有获得到，则休眠，过一会再进行尝试，直到获取到锁 为止，才能进行查询

  ​ 如果获取到了锁的线程，再去进行查询，查询后将数据写入 redis，再释放锁，返回数据，利用互斥锁就能保证只有一个线程去执行操作数据库的逻辑，防止缓存击穿

  

• 逻辑过期

思路分析：当用户开始查询 redis 时，判断是否命中，如果没有命中则直接返回空数据，不查询数据库，而一旦命中后，将 value 取出，判断 value 中的过期时间是否满足，如果没有过期，则直接返回 redis 中的数据，如果过期，则在开启独立线程后直接返回之前的数据，独立线程去重构数据，重构完成后释放互斥锁。

缓存击穿的解决方案的优缺点

缓存穿透：

指查询一个不存在的数据，由于缓存中没有，每次请求都会打到数据库上，导致数据库压力过大。

解决方案：可以使用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。

解决方案：

缓存空对象：

优点：实现简单，维护方便

缺点：

• 额外的内存消耗
• 可能造成短期的不一致

缓存空对象

具体实现：首先前端提交商铺 id，从 redis 中查询商铺缓存，再判断缓存是否命中。如果命中：需要判断缓存是否为空值，如果是空值，那就结束，如果不是空值，返回商铺信息 再结束；如果缓存未命中，就根据 id 去查询数据库，判断商铺是否存在，如果存在就将商铺数据写入 redis，而如果不存在，就将空值写入 redis。

布隆过滤器：

优点：内存占用较少，没有多余key

缺点：

• 实现复杂
• 存在误判可能

布隆过滤器的原理

基于“哈希映射”，它通过多个哈希函数将输入映射到一个位数组中的多个位置，从而实现高效的成员存在性检查。

下面是布隆过滤器的基本原理：

1. 位数组（Bit Array）：布隆过滰器使用一个包含大量二进制位的位数组，初始时所有位都被置为0。这个位数组通常会消耗一定数量的内存空间。

2. 多个哈希函数（Hash Functions）：布隆过滤器会预先定义若干个哈希函数，这些哈希函数可以将输入的元素映射到位数组中的不同位置。通常情况下，这些哈希函数会是独立且均匀分布的。

3. 插入操作：当一个新的元素需要加入布隆过滤器时，该元素会经过多个哈希函数计算得到多个哈希值，然后将位数组中对应的位置设为1。

4. 成员存在性检查：当需要检查一个元素是否在布隆过滤器中时，同样会对这个元素进行多次哈希计算，然后检查对应位置上的值。如果所有的位置都为1，则认为该元素可能存在于集合中；如果存在任何一个位置为0，则可以肯定该元素不存在于集合中。

   由于多个元素可能映射到位数组中的相同位置，因此布隆过滤器可能会出现“误伤”的情况，即某个元素被错误地判断为存在于集合中（false positive）。这种误判主要是由于哈希冲突引起的。

总的来说，布隆过滤器通过牺牲一定的准确性来换取内存占用和查询速度上的优势，因此在设计和使用时需要权衡误判率和内存消耗。

缓存雪崩：

指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方案：

• 给不同的Key的TTL添加随机值，避免所有缓存同时失效。
• 利用Redis集群提高服务的可用性
• 给缓存业务添加降级限流策略
• 给业务添加多级缓存

缓存过期时间的设置

1. 根据业务需求设置过期时间：

   对于优惠券信息，可以设置一个相对较长的过期时间，比如几个小时或一天，因为优惠券的信息一般不会频繁变动。 o

   对于秒杀商品的库存信息，由于库存数量会随着用户的购买而减少，因此需要设置一 个较短的过期时间，比如几分钟或几秒钟，以确保库存信息的实时性。

2. 使用 Redis 的过期策略：

   在 Redis 中，可以使用 EXPIRE 命令为指定的 key 设置过期时间，单位为秒。例如， EXPIRE key 300 表示 300 秒后 key 将过期。

   还可以使用 SET 命令的 EX 参数来设置 key 的过期时间。例如，SET key value EX 10 表示 key 将在 10 秒后过期。

3. 动态调整过期时间：

   根据秒杀活动的进度和流量情况，可以动态地调整缓存的过期时间。例如，在秒杀开始的前几分钟，可以缩短库存信息的过期时间，以确保用户看到的库存数量是最新的。

8.分布式锁和消息队列的原理和应用场景？

当多个进程或线程同时访问共享资源时，可能会出现数据竞争和并发问题，这时候就需要使用锁来保证数据的一致性和正确性。

在分布式系统中，由于多个节点之间需要共享数据和资源，因此也需要使用分布式锁来保证数据的一致性和正确性。

分布式锁的原理是通过共享资源来实现，

比如使用Redis的SETNX命令来实现互斥锁。当一个进程或线程需要获取锁时，它会尝试在Redis中创建一个指定名称的键值对，如果该键值对不存在，则创建成功，表示获取锁成功；否则，表示获取锁失败。

当进程或线程完成任务后，需要释放锁，即删除该键值对。

由于redis的单线程的，用了命令之后，只能有一个客户端对某一个key设置值，在没有过期或删除key的时候是其他客户端是不能设置这个key的

消息队列的原理是通过异步通信来实现，比如使用Redis的LIST数据结构来实现。当一个进程或线程需要向消息队列中发送消息时，它会将消息写入Redis的LIST中；而另一个进程或线程则可以从LIST中读取消息并进行处理。这样可以实现解耦和异步处理，提高系统的可伸缩性和可靠性。

分布式锁的应用场景包括：秒杀系统、分布式任务调度、分布式事务等。

消息队列的应用场景包括：异步任务处理、日志收集、事件驱动等。

9.统计UV和独立用户数量，如何实现？

当需要统计UV和独立用户数量时，可以使用Redis的HyperLogLog数据结构。

HyperLogLog是一种基数统计算法，可以用来统计大数据集合中的独立元素数量，而且占用的空间非常小，只需要12KB的空间就可以统计2^64个元素。

在项目中，可以使用Redis的PFADD命令来将用户的访问记录添加到HyperLogLog中，例如： PFADD uv:20220101 192.168.0.1 这条命令将IP地址为192.168.0.1的用户添加到名为uv:20220101的HyperLogLog中，表示该用户在2022年1月1日访问了网站。

当需要统计UV时，可以使用Redis的PFCOUNT命令来获取HyperLogLog中的独立元素数量，例如： PFCOUNT uv:20220101 这条命令将返回2022年1月1日的UV数量。

当需要统计独立用户数量时，可以将每个用户的访问记录添加到不同的HyperLogLog中，例如： PFADD uv:20220101:192.168.0.1 20220101 这条命令将IP地址为192.168.0.1的用户在2022年1月1日的访问记录添加到名为uv:20220101:192.168.0.1的HyperLogLog中，表示该用户在该日期访问了网站。

当需要统计独立用户数量时，可以使用Redis的PFMERGE命令将多个HyperLogLog合并为一个，例如： PFMERGE uv:20220101 uv:20220101:192.168.0.1 uv:20220101:192.168.0.2 这条命令将名为uv:20220101、uv:20220101:192.168.0.1和uv:20220101:192.168.0.2的三个HyperLogLog合并为一个，表示2022年1月1日的独立用户数量。

使用HyperLogLog可以快速、准确地统计UV和独立用户数量，而且占用的空间非常小，非常适合大数据集合的统计。

10.存储用户签到信息，如何使用BitField数据结构实现签到统计和查询？

当然可以。Redis的BitField数据结构可以用来存储和操作二进制位，可以用来实现类似于位图的功能。在用户签到的场景中，我们可以使用BitField来存储用户签到信息。

具体来说，我们可以使用以下命令来设置用户签到信息：

BITFIELD user:1 SET u32 #offset 1

user:1是用户的标识符，#offset是签到日期相对于当前日期的偏移量，1表示用户已经签到。如果用户没签到，则将值设置为0。

我们可以使用以下命令来查询用户的签到信息： BITFIELD user:1 GET u32 #offset 其中，GET命令用来获取指定偏移量的值，u32表示使用32位无符号整数来存储值，#offset是签到日期相对于当前日期的偏移量。

如果我们想要统计用户的连续签到天数，可以使用以下命令： BITFIELD user:1 GET u32 0 #count 其中，#count是签到天数，0表示从第0位开始计算。这个命令会返回一个数组，数组中的每个元素表示一个连续的签到周期，如果某个元素的值为0，则表示该周期内用户没有签到，否则表示用户签到了。

11. 如何控制Redis实现分布式锁有效时长

redis的setnx指令不好控制这个问题，我们当时采用的 redis的一个框架redisson实现的。

在redisson中需要手动加锁，并且可以控制锁的失效时间和等待时间，当锁住的一个业务还没有执行完成的时候，在redisson中引入了一个看门狗机制。

每隔一段时间就检查当前业务是否还持有锁，如果持有就增加加锁的持有时间，当业务执行完成之后需要使用释放锁

还有一个好处就是，在高并发下，一个业务有可能会执行很快，先客户1持 有锁的时候，客户2来了以后并不会马上拒绝，它会自旋不断尝试获取锁， 如果客户1释放之后，客户2就可以马上持有锁，性能也得到了提升。

12. redisson实现的分布式锁是可重入的

可以重入的。

这样做是为了避免死锁的产生。这个重入其实在内部就是

判断是否是当前线程持有的锁，如果是当前线程持有的锁就会计数，如果释放锁就会在计算上减一。

在存储数据的时候采用的hash结构，大 key可以按照自己的业务进行定制，其中小key是当前线程的唯一标识，value 是当前线程重入的次数 。

13. redisson实现的分布式锁不能解决主从一致性

不能的，

当线程1加锁成功后，master节点数据会异步复制到slave节点，此时当前持有Redis锁的master节点宕机，slave节点被提升为新的master节点，假如现在来了一个线程2，再次加锁，会在新的 master节点上加锁成功，这个时候就会出现两个节点同时持有一把锁的问题。

违反了分布式锁的基本原则，即在同一时间只能有一个客户端持有锁。

多个客户端同时持有锁可能会导致数据竞争和不一致，进而破坏数据的完整性和一致性。

我们可以利用redisson提供的红锁来解决这个问题，它的主要作用是，不能 只在一个redis实例上创建锁，应该是在多个redis实例上创建锁，并且要求在 大多数redis节点上都成功创建锁，红锁中要求是redis的节点数量要过半。这 样就能避免线程1加锁成功后master节点宕机导致线程2成功加锁到新的 master节点上的问题了。

但是，如果使用了红锁，因为需要同时在多个节点上都添加锁，性能就变的很低了，并且运维维护成本也非常高，

所以，我们一般在项目中也不会直接使用红锁，并且官方也暂时废弃了这个红锁

14.业务非要保证数据的强一致性，怎么解决呢？

redis本身就是支持高可用的。

做到强一致性，就非常影响性能，如果有强一致性要求高的业务，建议使用zookeeper实现的分布式锁，可以保证强一致性的。

基于 Session 的短信登录

发送短信验证码。

​ 保存验证码到session。

短信验证码登录、注册。

​ 用户将验证码和手机号进行输入，后台从 session 中拿到当前验证码，然后和用户输入的验证码进行校验。

​ 无论是否存在， 都会将用户信息保存到 session 中，方便后续获得当前登录信息。

后续用 redis 替代 session 实现登录注册功能

检验登录状态

在随后的请求中，客户端浏览器会自动将 Cookie（包括 JSESSIONID）附加到每个请求中，发送给服务器。

后台通过 JsessionId 从 Session 中获取用户信息。

如果 Session 中存在用户信息，则将用户信息保存到 threadLocal 中并放行请求；如果不存在，则进行拦截或重定向到登录页面。

​ 有了拦截器之后，用户的各种请求就不用直接访 问 Controller，必须先经过拦截器，判断是否放行。可以把用户校验登录的功能交给拦截器做，但是需要把拦截器中拿到的用户信息传递到各个 Controller 层去，传递的过程中还需注意线程安全问题。那么在拦截器中拦截到的用户信息，可以保存到 ThreadLocal 中。

为什么要把用户信息保存到 ThreadLocal 中去？

​ 在 Web 应用中，将用户信息保存到 ThreadLocal 中的主要目的是为了在当前处理的线程中方便、 快捷地获取用户相关信息，而不需要频繁地从Session 或其他存储中检索。这样做有以下几个好处：

1. 线程安全：ThreadLocal 为每个线程提供了其自己的变量副本。这意味着一个线程不能访问或修改另一个线程的 ThreadLocal 变量。这在多线程环境中特别有用，因为它避免了共享数据时的同步问题。
2. 性能优化：从 Session 或其他存储中检索用户信息可能涉及数据库查询或网络调用，这可能会消耗相对较多的时间和资源。通过将用户信息保存在 ThreadLocal 中，可以在需要时快速访问，减少了不必要的查找和等待时间。
3. 代码简化：当在一个请求的处理流程中需要多次使用用户信息时，如果每次都需要从 Session 中获取，那么代码会变得冗长和重复。通过将用户信息保存在 ThreadLocal 中，可 以在任何需要的地方方便地访问它，从而简化了代码。
4. 请求作用域数据的传递：在 Web 应用中，一个请求通常由多个过滤器、拦截器、服务层方法等共同处理。使用 ThreadLocal 可以确保这些组件在处理请求时都能访问到相同的用户信息，而不需要显式地传递数据。
5. 避免潜在的并发问题：如果不使用 ThreadLocal，而是将用户信息作为方法参数或类成员变量传递，那么在并发环境下可能会遇到数据污染或数据不一致的问题。使用 ThreadLocal 可 以确保每个线程都有自己的数据副本，从而避免了这些问题。

​ 需要注意的是，ThreadLocal 的生命周期与线程的生命周期绑定。当线程结束时，其 ThreadLocal 变量也会被垃圾回收。因此，在使用 ThreadLocal 时，要确保在请求处理完毕后及时清理其中的数据，避免内存泄漏。这通常通过在请求处理完毕后调用 ThreadLocal 的 remove() 方法来实现。

使用拦截器实现用户的登录校验和权限刷新

问题：只有⼀个登陆拦截器 A，该拦截器上进行获取 token、查询 Redis用户、刷新 token 有效期的操作。而该拦截器只对需要登陆路径进行拦截。此时就有问题了。当用户访问不需要登陆的路径时，就不会刷新 token 有效期，30 分 钟后，token 会自动过期。

解决：在这个拦截器 A 前再加⼀个拦截器 B，用于拦截⼀切路径，把获取 token、查 询 Redis⽤户、刷新 token 有效期 的操作放到这个拦截器 B 上做。而拦截需要登陆的 路径的拦截器 A 只需要判断 ThreadLocal 中有没有用户即可。

session 共享问题

加入A用户访问第一个Tomcat服务器，并且把自己的信息存放到A服务器的 session 中。

第2次A用户访问另外一个Tomcat服务器，肯定没有A服务器存放的 session，所以此时整个登录拦截功能就会出现问题。

多台 Tomcat 并不共享 session 存储空间，当请求切换到不同 Tomcat 服务时导致数据丢失。

早期解决方案：

​ session 拷贝，就是说虽然每个 tomcat 上都有不同的 session，但是每当任意一台服务器的 session 修改时，都会同步给其他的 Tomcat 服务器的 session，可以实现 session 的共享。

这种方案具有两个大问题

• 每台服务器中都有完整的一份 session 数据，服务器压力过大。
• session 拷贝数据时，可能会出现延迟

所以采用的方案都是基于 redis 来完成，我们把 session 换成 redis，redis 数据本身就是共享的，就可以避免 session 共享的问题。

使用redis实现共享session登录，主要是为了解决在分布式系统中，用户 session 无法共享的问题

任何一台 Tomcat 都可以访问到 Redis，所以 就可以实现数据共享。

用 redis 替代 session 实现登录注册功能的好处

• 性能优势： Redis 是一个内存数据库，读写速度非常快，相比传统的基于文件或 者数据库的 Session 存储方式更高效。这意味着在高并发的情况下，Redis 能够 更好地处理大量的用户请求，提高系统的响应速度和并发处理能力。
• 扩展性： Redis 支持分布式部署，可以很容易地进行横向扩展，通过增加节点来扩展系统的容量和性能。这使得系统能够更好地应对持续增长的用户量和数据量。
• 灵活性： Redis 提供了丰富的数据结构和操作命令，可以灵活地处理各种数据存 储和操作需求。在实现登录注册功能时，可以利用 Redis 的字符串、哈希表、列 表等数据结构来存储用户信息、会话数据等，以及利用 Redis 的原子操作来实现 并发安全的会话管理。
• 持久化支持： Redis 提供了多种持久化方式，可以将数据持久化到磁盘上，确保 数据不会因为系统故障或者重启而丢失。这种持久化支持可以保证用户的登录状态 等重要信息不会丢失，增强了系统的稳定性和可靠性。
• 生态丰富： Redis 生态系统非常丰富，有大量的客户端库和工具可供选择，可以 方便地集成到各种不同的应用和框架中。同时，Redis 也有很多成熟的解决方案和 最佳实践，可以帮助开发者更快地构建稳健的系统。

全局唯一ID

（Globally Unique Identifier）

用于 确保在一个特定的环境中生成的所有 ID 都是唯一的，不会有重复的。这种唯一性不仅限于单 个系统或应用，而是跨多个系统、应用或数据库的全局唯一。

订单表如果使用数据库自增 ID 就存在问题：

• id 的规律性太明显，容易泄漏信息
• 受单表数据量的限制（数据量过大），订单 id 不应该重复

mysql 的单表的容量不宜超过 500W，数据量过大 后，进行拆库拆表。

但拆分表了之后，他们从逻辑上讲他们是同一张表，所以他们的 id 是不能一样的， 于是乎我们需要保证 id 的唯一性。

优惠卷秒杀下单

超卖问题

出现原因：

• 正常情况下：线程 1 先执行下单的逻辑：首先要进行查询操作，库存为 1 的话，查询到 的结果就为 1，接下来判断库存是否足够，1>0 所以执行扣减操作。此时库存变为 0。此 时如果线程 2 来查询，那么查询到的库存就为 0，不满足库存充足的条件，报错。
• 高并发情况下：线程 1 先执行查询库存的操作，查询到的为 1，此时线程 1 该去判断库 存是否>0，就在同时线程 2 在 线程 1 尚未扣减库存的时候进入，查询到的库存也是 1。 故两个线程都会去扣减库存，此时就产生了超卖问题，库存从 0 变成-1 这种情况下

解决的最好方式是加锁

超卖问题是个典型的多线程安全问题。

• 悲观锁： 在商品购买过程中，使用悲观锁（Pessimistic Locking）对库存进行加锁，确保同一时间只有一个用户可以执行减库存操作，避免并发冲突导致的超卖问题。例如，在数据库层面使用数据库行级锁或者事务进行控制。

• 乐观锁： 使用乐观锁（Optimistic Locking）进行并发控制。在购买商品时，先查询当前库存数量，然后在更新库存时进行版本号比对，如果版本号一致才执行更新操作，否则返回库存不足错误。这种方式适用于读多写少的场景。

• 分布式锁： 在分布式系统中，使用分布式锁对库存进行加锁，确保同一时间只有一个节点可以执行库存减少操作，避免多个节点之间的并发冲突。

• Redis原子操作 Redis与Lua预防库存超卖。Lua可以将redis的多个操作合成一个脚本，然后整体执行，在脚本的执行中，不会出现资源竞争的情况，即保证了操作的原子性。

乐观锁和悲观锁

乐观锁比较适合更新数据，悲观锁比较适合插入数据

悲观锁

是一种对数据的修改持有悲观态度的并发控制方式。总是假设最坏的情况，每次读取数据的时候都默认其他线程会更改数据，因此需要进行加锁操作，当其他线程想要访问数据时，都需要阻塞挂起。所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。

悲观锁的实现：

1. 传统的关系型数据库使用这种锁机制，比如行锁、表锁、读锁、写锁等，都是在操作之前先上锁。

2. Java 里面的同步 synchronized 关键字的实现。

乐观锁

乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证数据是否被其它线程修改。如果在更新数据的时候发现数据版本与当前版本不一致，就认为数据被其他线程修改过，更新操作失败，需要进行重试或者放弃操作。

CAS 实现

Compare and Swap

每次都要查询，库存和版本都要查，CAS用库存量代替版本号，在执行操作时判断 where 用的库存量和在最初查询的时候，是否相等。

​ （用数据本身判断是否有变化，来判断线程是否安全） 所以就有了简化的 CAS法 。

CAS 的思想很简单，就是用一个预期值和要更新的变量值进行比较，两值相等才会进行更新。

实现思路：

• 读取库存：当用户发起秒杀请求时，首先读取库存数量。

• 计算新库存：根据用户的购买数量，计算出新的库存数量。

• CAS 操作：使用 CAS 算法尝试更新库存。CAS 操作包含三个参数——内存位置（V）、期望的原值（A）和新值（B）。当内存位置 V 的值等于期望原值 A 时，将内存位置 V 的值设置为新值 B。否则，不做任何操作。在库存扣减的场景中，内存位置 V 是库存数量，期望的原值 A 是读取到的库存数量，新值 B 是计算出的新库存数量。

• 循环重试：如果 CAS 操作失败（即库存数量已被其他用户修改），则重新读取库存数量， 并重复 CAS 操作，直到成功为止。

自旋： 不停的判断比较，看能否将值交换

在CAS操作中，自旋的概念指的是当线程发现无法立即完成操作时，不会让出CPU时间片，而是继续循环尝试，直到成功为止。这种机制可以避免线程频繁地挂起和恢复，减少了线程切换的开销，提高了效率。

自旋锁通常适用于锁被占用的时间较短的场景，因为长时间的自旋会导致CPU资源的浪费。

总的来说，CAS的自旋是通过不断循环尝试来实现的一种锁优化机制，它在多线程编程中用于保证操作的原子性和提高性能。

乐观锁方案的问题成功率太低

• 解决方案：无需判断库存是否与查到的相等，只需判断库存>0 就行。

版本号控制

一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会 +1。当线程 A 要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值与当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

对比

• 使用悲观锁：添加同步锁，让线程串行执行；

  优点：简单粗暴

  缺点：性能一般

  悲观锁适合写操作多的场景。

• 使用乐观锁：不加锁，在更新的时候判断是否有其他线程在修改

  优点：性能好（无阻塞：乐观锁不会在获取锁时阻塞线程，而是在更新数据时检查数据的版本号，这样可以减少线程的等待时间，提高系统的并发性能，减少了因为锁争用导致的性能下降）

  缺点：存在成功率低的问题（并发冲突：在高并发环境下，由于多个线程同时读取和修改数据，可能会导致数据竞争和冲突，从而造成更新失败。）

​ 乐观锁适合读操作多的场景，不加锁可以提升读操作的性能。

一人一单

一人一单的并发安全问题

• 乐观锁：适合读多写少的场景，通过版本号或时间戳来实现，在更新数据时检查数据是否被修改。适合更新数据
• 悲观锁：适合并发写入较多的场景，通过锁定资源来防止并发冲突，在插入数据时使用悲观锁可以确保唯一性和数据一致性。适合插入数据

单机情况

public synchronized Result createVoucherOrder(Long voucherId){

}

1 这样添加锁，锁的粒度太粗，会导致每个线程进来都会锁住，所以我们需要去控制锁的粒度。

intern() 这个方法是从常量池中拿到数据，如果我们直接使用 userId.toString() 他拿到的对象实际上是不同的对象，new 出来的对象，我们使用锁必须保证锁必须是同一把，所以我们需要使用 intern()方法。

2 当前方法被 spring 的事务控制，如果你在方法内部加锁，可能会导致当前方法事务还没有提交，但是锁已经释放也会导致问题，所以我们选择将当前方法整体包裹起来，确保事务不会出现问题。

3 调用的方法，其实是 this.的方式调用的，事务想要生效，还得利用代理来生效，需要获得原始的事务对象， 来操作事务。

集群模式

通过加锁（sychronized）的方式可以解决单机情况下的一人一单安全问题。

但是在集群模式下就不行了。

在集群模式下（或分布式系统下）：有多个 JVM 的存在，每个 JVM 内部都有 自己的锁，导致每一个锁都会有自己的线程获取，于是出现了并行运行，会出现安全问题。

分布式锁解决集群下的一人一单

分布式锁：满足分布式系统或集群模式下多进程可见并且互斥的锁。

分布式锁满足条件

• 可见性：多个线程都能看到相同的结果，注意：这个地方说的可见性并不是并发编 程中指的内存可见性，只是说多个进程之间都能感知到变化的意思
• 互斥：互斥是分布式锁的最基本的条件，使得程序串行执行
• 高可用：程序不易崩溃，时时刻刻都保证较高的可用性
• 高性能：由于加锁本身就让性能降低，所有对于分布式锁本身需要他就较高的加锁性能和释放锁性能
• 安全性：安全也是程序中必不可少的一环

实现思路

1. 锁的标识： 为了确保锁的唯一性，我们需要为每个用户的下单操作生成一个唯一的锁标识。这个 标识可以基于用户 ID 和订单相关信息（如秒杀活动 ID）来构建。

2. 获取锁：

   ​ 当用户发起下单请求时，系统首先尝试从 Redis 中获取分布式锁。这通常通过调用 Redis 的 SETNX（set if not exists）命令来实现，该命令只有在键不存在时才设置键的值。如果设置成功，表示获取到了锁；如果设置失败，表示锁已被其他线程持有。

   ​ 为了防止死锁，我们还需要为锁设置一个过期时间（TTL），即使持有锁的线程因某种 原因崩溃而没有释放锁，锁也会在一段时间后自动释放。

3. 执行下单操作： 一旦获取到锁，系统就可以安全地执行下单操作。这包括检查库存、生成订单、扣减 库存等步骤。由于此时只有持有锁的线程能够执行这些操作，因此可以确保同一用户只能下一单。

4. 释放锁： 在下单操作完成后，无论成功还是失败，持有锁的线程都需要释放锁。这通常通过调 用 Redis 的 DEL 命令来删除锁标识实现。为了确保在异常情况下也能正确释放锁，可 以使用 try-finally 语句块来确保释放锁的代码总是被执行。

Redis 分布式锁的误删问题

• 假如现在有一个线程 1 执行过程中，首先会尝试获取锁，会发起请求来获取锁，由于是第一个来，所以会正确的获取，无任何阻拦，拿到锁之后就会去执行自己的业务。
• 但因为某种原因，业务产生了阻塞，这样一来锁的持久周期就会变长。但如果业务阻塞太久，超过了锁设置的过期时间，那么锁此时会自动超时释放（业务没结束，提前释放)
• 一旦提前释放，这时其他线程来获取锁的时候就能乘虚而入获取锁成功，比如线程 2，获取锁成功后就去执行自己的业务
• 在线程 2 获取锁之后，执行业务的过程中，线程 1 不阻塞了，重新执行自己的业务，当线程 1 业务完成后就会释放锁（DEL key）,但问题是，这个时候是线程 2 的锁被释放了！
• 则此时假设有一个线程 3 来了，首先获取锁，因为此时锁以及被删了，它也能获取成功，开始执行自己的业务！此时此刻同时有两个线程（2 和 3 ）都拿到了锁，都在执行业务，又一次出现了并行执行的情况，线程安全问题会再次发生

1.在获取锁时存入线程标示（可以用UUID表示）

2.在释放锁时先获取锁中的线程标示，判断是否与当前线程标示一致

• 如果一致则释放锁
• 如果不一致则不释放锁

分布式锁的原子性问题

• 假设线程 1 一上来先去申请锁，获取锁成功后，开始执行自己的业务。业务成功执行完后，进行释放锁：先判断锁标识，紧接着释放锁。
• 由于判断锁标识和释放锁是两个操作，此时假设就在释放锁的时候产生了阻塞（JVM 中有一个垃圾回收，当 JVM 去做 FullGC 的操作的时候，会阻塞所有的代码，这个时候就会阻塞。不是业务阻塞，而是 JVM 本身阻塞），一旦被阻塞了，锁就没有被释放。当阻塞时间足够长，就会触发锁的超时释放
• 锁一旦被超时释放，其他线程就又可以乘虚而入，比如线程 2，此时获取了锁，于是开始执行自己的业务
• 如果说此刻 GC 结束了，阻塞结束，线程 1 恢复运行，去执行释放锁的动作（此时判断以及执行过了，它认为锁还是自己的，但实际上已经不是了，直接执行释放锁）这个时候又一次把线程 2 的锁给误删掉了
• 此时如果再来一个线程 3，由于锁已经被释放，那么线程 3 可以轻而易举地获取锁，从而执行自己的业务，那么又出现了多个业务并行执行的场景，又会产生并发安全问题。

因为判断锁标识和释放锁是两 个动作，这两个动作之间产生了阻塞

要想避免这种问题的发生，必须确保判断锁标识 的动作和释放锁标识的动作是原子性的

Redis秒杀优化

异步读取队列中的信息，完成下单。

检验一人一单：（没有重复数据）将userId存入当前优惠券的set集合，确保一人一单

基于阻塞队列的异步秒杀存在哪些问题？

• 内存限制问题

高并发的时候，较多订单存到阻塞队列中去的话，容易导致内存泄漏的问题。

• 数据安全问题

jvm内存没有持久化机制，基于内存保存数据，如果内存突然宕机，则内存中所有的订单信息都丢失了，比如说用户已经完成下单付款，但后台没有订单信息；还有种情况，有个线程从阻塞队列中取出一个下单的任务，要去执行，就在此时发生了严重事故，这个任务没有被执行，而任务一旦取出队列就没有了。

Redis消息队列实现异步秒杀

消息队列是JVM以外的独立服务，不受JVM内存的限制。

消息队列不仅仅做数据存储，也有数据安全，会做消息持久化，并要求消费者消费消息后进行确认，才将任务从队列中删除。

1. 设计异步队列：首先，需要设计并实现一个异步队列，用于存储待处理的秒杀订单请求。 这个队列可以基于 Redis、RabbitMQ、Kafka 等消息中间件来实现，确保请求能够可靠地 存储和转发。
2. 接收用户请求：当用户发起秒杀请求时，系统首先会进行一系列的前端验证和风控检查， 确保请求的有效性。然后，将请求发送到异步队列中等待处理。
3. 后台异步处理：后台服务会不断从异步队列中取出请求进行处理。处理过程包括扣减库存、 创建订单、生成支付链接等。由于这些操作是异步进行的，因此不会阻塞用户的请求，提高了系统的响应速度。
4. 通知用户结果：当后台处理完请求后，会通过短信、邮件或应用内通知等方式告知用户秒 杀结果。如果用户秒杀成功，还会提供支付链接供用户完成支付。

Redis提供三种方式实现消息队列

• list结构：基于List结构模拟消息队列

Redis的list数据结构是一个双向链表，很容易模拟出队列效果。

队列是入口和出口不在一边，因此我们可以利用：LPUSH 结合 RPOP、或者 RPUSH 结合 LPOP来实现。

不过要注意的是，当队列中没有消息时RPOP或LPOP操作会返回null，并不像JVM的阻塞队列那样会阻塞并等待消息。

因此这里应该使用BRPOP或者BLPOP来实现阻塞效果。

优点：

•利用Redis存储，不受限于JVM内存上限

•基于Redis的持久化机制，数据安全性有保证

•可以满足消息有序性

缺点：

•无法避免消息丢失（消息取出队列中就没有了）

•只支持单消费者（一个消息一旦被一个消费者拿走了，别的消费者就不能消费了）

• PubSub：基本的点对点消息模型

消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息。

优点：

•采用发布订阅模型，支持多生产、多消费

缺点：

•不支持数据持久化

•无法避免消息丢失

•消息堆积有上限，超出时数据丢失

• Stream：比较完善的消息队列模型

Stream 是 Redis 5.0 引入的一种新数据类型，可以实现一个功能非常完善的消息队列。

基于 Stream 结构作为消息队列，实现异步秒杀下单的思路

首先，我们需要设计一个基于 Stream 的消息队列系统，它能够接收、存储和转发秒杀下单的 请求消息。这个系统可以依赖于成熟的消息队列中间件，如 Kafka 或 RabbitMQ，它们提供了 高可靠、高性能的消息传递机制。

当用户发起秒杀请求时，前端或 API 网关作为生产者，将请求封装成消息，并发送到消息队列 中。这一步确保了用户的请求能够迅速进入处理流程，而不会因为后端服务的处理瓶颈而阻塞。

在消息队列的另一端，后端服务作为消费者，负责从队列中拉取消息并进行处理。消费者可以 按需设置拉取消息的频率和批量大小，以平衡处理速度和系统负载。一旦获取到消息，消费者会进行一系列的业务处理，包括验证请求的有效性、执行库存扣减操作、生成订单等。这些操作都是在后台异步进行的，不会阻塞用户的请求。

处理完成后，消费者需要将结果通知给用户。这可以通过发送短信、邮件或应用内通知等方式 实现。同时，处理过程中的关键信息和日志也需要被妥善记录和保存，以便于后续的分析和排查问题。

在整个过程中，我们还需要考虑一些优化和扩展措施。例如，为了保证消息的顺序性，我们可以设置消息队列的分区和消费者组的配置；为了应对秒杀活动期间的流量高峰，我们可以利用消息队列的缓冲能力进行流量削峰；同时，建立完善的监控和告警机制也是必不可少的，它可 以帮助我们及时发现和处理系统中的异常和性能瓶颈。

综上所述，基于 Stream 结构作为消息队列实现异步秒杀下单的思路，主要是通过将用户的请 求封装成消息并发送到队列中，由后台服务异步处理这些请求，并在处理完成后通知用户。这 种方式不仅提高了系统的并发处理能力和响应速度，还增强了系统的稳定性和可扩展性。

=项目==

项目遇到了哪些棘手的问题

有4个方面可以回答，只要挑出一个回答就行了

设计模式

• 工厂模式+策略
• 责任链模式

回答思路 1，什么背景（技术问题） 2，过程（解决问题的过程） 3，最终落地方案

举例：

①：介绍登录业务（一开始没有用设计模式，所有的登录方式都柔和在一个业 务类中，不过，发现需求经常改）

②：登录方式经常会增加或更换，每次都要修改业务层代码，所以，经过我的设计，使用了工厂设计模式和策略模式，解决了，经常修改业务层代码的问题

③：详细介绍一下工厂模式和策略模式（参考前面设计模式的课程）

线上BUG

• CPU飙高
• 内存泄漏
• 线程死锁 ....

回答方式参考上面的回答思路，具体问题可以参考前面的课程（JVM和多线程相 关的面试题）

调优

• 慢接口
• 慢SQL
• 缓存方案

组件封装

• 分布式锁
• 接口幂等
• 分布式事务
• 支付通用

面试官（50%）

• 对眼，聊得如何
• 是否是个合格的面试官
• 运气

自己（50%）

表达沟通能力 + 逻辑性 (30%)

• 晚上把一天学的东西串起来。
• 对一个知识和技术栈有自己的知识脉络，有宏观的认识。

专业知识 (20%)

• 8股的积累，了解。

开放问题

如果问怎么自学的？

可以不用那么老实，我一般就说看书、看笔记、官方文档、谷歌、GPT。

最近在看的书（前沿和专业领域）

平时学习的方法习惯体系

人生发展、最近五年职业规划

你最大的优点/缺点

从长处来说，我相信我最大的优点是我有一丧高度理性的头脑， 能够从混乱中整理出头绪来。我最大的弱点是，对那些没有秩序感的人，可能缺 乏趍够的耐心。我相信我的组细才能可以帮劣企业更快地实现目标，而丏有旪候， 我处理复杂问题的能力也能影响我的同事。

最有成就感的事情/最丧的事情

你和同事们怎么相处

正确回答我一般都能与同事相处得很好。当然有时候也可能会同某人发生冲突。这时，我一般会注意寻找冲突的根源，而不是转移到对对方的攻击上（将问题和人格区别开来）。我发现这种方法非常有效，它可以使我同任何人都维持一种相互尊重的关系。另外，通过这样做，我往往都能解决问题，甚至会促进与同事的关系。

你认为自己最显著的成就是什么?为什么?

竞争对你的成就有什么积极或者消极的影响?是怎样影响的?

正确回答如果害怕竞争，我就不会申请这份工作。我知道竞争是始终存在的，对我来说最重要的是意识到竞争，清楚我们在为什么而竞争。当我处在竞争环境中时，我首先要确保自己头脑清醒，理解所处的危险处境。一旦我了解了竞争形势和规则，就会全身心地投入到竞争中去。在竞争中合作，努力实现团体利益的最大化。

你在找工作时最看重的是什么？为什么？

我希望找到的工作能发挥我的长处，比如.......(说出具体技能)我认为还有一件事情也很重要，那就是我在企业中的作用要与企业目标联系在一起。如果工作中偶尔有些挑战，让我超越自己目前的技能水平，那就再好不过了。

你怎样做出自己的职业选择？自己学的卫星，为什么选择是java开发，来运营商，互联网，银行

你是怎样准备这次面试的？

你个人的长期和短期目标分别是什么?你是如何确定这些目标的?你准备怎样实现这些目标?

​ 正确回答同所有现实目标一样，我的目标经常改变。不论在长期还是短期，我的个人策略是根据当前目标评价自己所处的位置，然后相应地修改自己的计划。比如，我每五年就制定一项个人计划，这个计划中包含一个总体目标和一系列短期目标。每6个月我就回顾一下自己的进展，然后做出必要的修改。很明显，我当前的计划就是实现职业转变，也就是找到更满意的工作。除此之外，我已经实现了近期制定的个人目标。每个人在一生中都会有几次机会，只要抓住，就可以比之前强大一些。

什么样的情形会让你感到沮丧?

面试者没有说出任何真正的致命弱点，这一点是对破坏了“不要打击别人”的法则,从而暴露了自己的弱点。
正确回答我认为会让我感到沮丧的是一件事情拖得太久，虽然这并不经常发生/虽然现在改善了很多。我认为，对于尚未解决的问题，并不是所有的成功企业都会有回旋的余地。我希望尽可能快地找到好的对策，这样我们就可以继续开展企业的业务。

当你确信自己是正确的，但是其他人却不赞同你时，你会怎样做?

首先，我会确保有足够的信息来支持自己。一旦我确信自己的观点是正确的，我就会密切关注反对者的具体反对理由。我将从他们的角度看待问题，并以此说服他们。由于互相尊重，我相信我们可以最终达成协议。

你能够在压力状态下工作得很好吗?

在从事有价值的工作时，任何人都会在工作中时不时地遇到压力。我能够应付一定量的压力，甚至在有些情况下还可以承受极大的压力。对我来说，应对压力的关键是找到一种方法控制形势，从而减轻压力的剧烈程度——通过这种方式，压力就不会影响我的生产力。我知道任何工作都有压力，如果必要的话，我会在压力下工作得很好。

常见项目问题：

• 你负责了项目的哪块内容？
• 项目的难点痛点/最有挑战的地方是什么？你们怎么解决的？
• 你使用XX技术栈的时候有没有什么坑，你们怎么解决的？
• 项目中遇到过什么印象比较深的Bug？
• 遇到XX情况么？怎么解决的，怎么优化的？能多说几种方案么？
• 你是根据哪些指标进行针对性优化的？
• 项目存在的问题和完善解决方案

收获

增长开发经验
提高业务分析能力
提高接口设计能力
提高编码能力
提高文档阅读能力
提高代码调试能力

反问：

正确的提问姿势

通过HR的回答其实也是对公司的一些了解和面试。

目的是为了体现自己对自我发展和公司的一个关注度。

一面

• 部门主营业务和使用的技术栈是什么？
• 您觉得我的专业能力有哪些需要提升的
• 刚才关于xx问题，我想问下您的思路。
• 面试一般多久会出通知和结果呢？
• 如果进入公司的话，我需要负责哪些业务呢
• 问清技术栈，该部门负责哪些业务？

二面

• 面试候选人，尤其是校招生的时候，最看重什么？
• 您对进入您团队的成员的要求是什么？或者说需要怎样的品质胜任这个职位？
• 我很好奇职位的晋升机制和发展路径。
• 公司对信任的培养是怎么样的
• 公司的新人培养机制如何

三面

• 企业文化
• 代表性产品
• 历年薪资