审核解析结果

返回队列

任务 ID: job_7e7cc4a6238b4ee3a725e6e0f19ea0a1
任务类型: 提取面经
状态: 已确认
尝试次数: 1

来源上下文

知识笔记来源已确认任务已确认

Java八股（数据库）.md

src_7c5d83a17c464c2a933b1a39d8150541

创建于 2026/03/29 00:41，最近更新时间 2026/04/07 12:16

公司岗位轮次标签

摘要原文

# MySQL
## 基础知识
### mysql基础架构？
mysql主要包括连接器、查询缓存、分析器、优化器、执行器和插件式存储引擎

+ 连接器：主要用于身份验证和权限管理
+ 查询缓存：用户的查询会首先在缓存中进行查询，如果命中则直接返回
+ 分析器：分析查询语句是想要做什么的，并检查语句正确性
+ 优化器：执行计划生产、索引选择
+ 执行器：执行语句，从存储引擎中返回数据
+ 插件式存储引擎：主要用于存储和读取数据，是插件式的，支持多种引擎，例如InnoDB，MyISAM等

### <font style="color:rgb(44, 62, 80);">MySQL 支持哪些存储引擎？默认使用哪个？</font>
支持innodb、myisam、memory等，默认使用innodb，以前默认是使用myisam，可以通过show engines查看

### <font style="color:rgb(44, 62, 80);">MySQL 存储引擎架构了解吗？</font>
MySQL采用插件式存储引擎，可以支持多种存储引擎，甚至可以为不同的数据库表设置不同的存储引擎以适应不同的场景需求。其存储引擎是基于表的，而不是数据库

### <font style="color:rgb(44, 62, 80);">MyISAM 和 InnoDB 有什么区别？</font>
innodb支持行级锁，而myisam只支持表级锁

myisam不支持事务，而innodb支持事务，实现了sql的四个隔离级别，默认是可重复读

myisam不支持外键，而innodb支持

myisam不支持mvcc，而innodb支持

两者都是采用B+树索引，但是他们的实现不太一样

myisam不支持数据库崩溃后的安全恢复，而innodb支持

innodb性能要比myisam好

### MyISAM适合MyISAM引擎在某些特定场景下可能更合适，但它也有一些限制和不足之处。以下是一些适合使用MyISAM引擎的场景：

1.  **读频繁、写较少的应用**：MyISAM引擎在读取大量数据时表现良好，适用于那些读操作比写操作频繁的应用。这是因为MyISAM使用表级锁，而不是行级锁，因此对于写操作并发度较低。
2.  **非事务性应用**：MyISAM引擎不支持事务，因此适用于不需要事务支持的应用，例如一些报表生成、日志记录等应用。
3.  **全文搜索**：MyISAM引擎提供了全文搜索功能，通过使用`FULLTEXT`索引，可以执行高效的文本搜索操作。
4.  **小型项目和原型**：对于小型项目、快速原型开发或测试数据库，MyISAM可能是一个简单而有效的选择。

然而，需要注意的是，MyISAM引擎也有一些重要的限制和不足之处，包括：

1.  **不支持事务**：MyISAM不支持事务，这意味着如果你的应用需要复杂的事务控制，那么应该选择InnoDB等支持事务的引擎。
2.  **不支持外键约束**：MyISAM不支持外键约束，这可能导致数据一致性问题，特别是在涉及到关联表的情况下。
3.  **表级锁**：MyISAM使用表级锁，这意味着在写操作时会锁定整个表，而不是单独的行，因此可能会导致并发性能问题。
4.  **不支持崩溃恢复**：MyISAM引擎不支持崩溃恢复，如果数据库发生崩溃，可能会导致数据损坏。

总之，选择是否使用MyISAM引擎取决于你的应用需求和性能要求。如果你需要事务支持、外键约束和更高的并发性能，那么InnoDB引擎通常是更好的选择。<font style="color:#DF2A3F;"> MyISAM通常适用于一些简单的、读密集的、非事务性质的应用</font>。但需要在选择之前仔细权衡其优缺点。注意，MySQL的默认存储引擎在不同的MySQL版本中可能有所不同，所以在创建表时要格外小心选择适合的存储引擎。

### MyISAM和InnoDB的索引有啥不一样的？
myisam的b+树叶子节点中记录的data是数据地址，也就是说它的索引文件和数据文件是分开的，查到了之后还要根据地址去查找响应的数据。而innodb记录的就是真实的数据，它是聚簇索引。

### 事务的四大特性？
1. 原子性：一个事务要么全部执行成功，要么全部不执行。undo log回滚保证
2. 一致性：事务执行前后，数据应保持一致
3. 隔离性：一个事务的操作不能够被另一个事务所影响。锁+mvcc
4. 持久性：一个事务提交后，他对数据库的数据的改变是持久的。redo log保证

### <font style="color:rgb(44, 62, 80);">并发事务带来了哪些问题?</font>
+ 脏读：一个事务读到另一个事务还未提交的数据
+ 不可重复读：一个事务重复读取同一个数据，结果不一样
+ 幻读：一个事务前后读取数据的数量不一样

### <font style="color:rgb(44, 62, 80);">不可重复读和幻读有什么区别？</font>
不可重复读主要针对于多次读取数据，数据的值改变或者记录减少，而幻读主要是查询的记录增加。区分两者的主要原因是两者的解决方案不一样。

### <font style="color:rgb(44, 62, 80);">SQL 标准定义了哪些事务隔离级别?</font>
+ 读未提交：能够读到还未提交的数据，会造成脏读、不可重复读和幻读
+ 读已提交：能够读到其他事务已经提交的数据，避免了脏读，但还有不可重复读和幻读
+ 可重复读：允许重复读取，保证结果一致，避免了脏读、不可重复读，但会有幻读
+ 串行化：事务依次执行，完全满足ACID

### <font style="color:rgb(44, 62, 80);">MySQL 的隔离级别是基于锁实现的吗？</font>
MySQL的隔离级别是基于锁和MVCC实现的，像读已提交和可重复读是通过MVCC来实现的，串行化是通过锁来实现的，而且innodb当中在可重复读的情况下，也可以使用加锁读来保证不会幻读。

### <font style="color:rgb(44, 62, 80);">并发事务的控制方式有哪些？</font>
MySQL并发事务控制主要依赖于锁和MVCC两种方式。

锁主要使用的是读写锁，即共享锁和排他锁，而更细粒度的还可以分为行级锁和表级锁，行级锁是针对一行数据进行加锁，相比于表级锁效率更高。

MVCC是多版本并发控制方法，一份数据会存储多个版本，通过事务的可见性来保证事务能够看到自己该看到的版本。通常会有一个全局的版本分配器来为每一行设置版本号。MVCC在MySQL中的主要实现手段包括：undo log、隐藏字段、read view

### 什么是查询缓存？
查询缓存就是MySQL在执行查询语句的时候，可以先到缓存当中查询，如果有则返回，没有的话就会再到数据库当中进行查询。查询缓存虽然能够提升数据库的查询性能，但是也会带来额外的开销，因为每次查询都需要添加缓存，而缓存失效了之后也要删除缓存。

### 执行一条select语句期间发生了什么？
1. 首先会和数据库通过TCP三次握手建立连接，然后进行用户验证和权限验证。
2. 然后数据库会先在缓存中进行查找，如果找到了就直接返回，如果没找到就开始下一步
3. 然后解析器会对sql语句进行解析，包括语法分析和词法分析，判断正确性，构建语法树
4. 接下来就进入执行阶段，主要包括三个步骤
    1. 预处理器进行预处理，例如将*好扩展为表上所有列
    2. 然后就交由优化器，指定执行计划，进行索引选择
    3. 最后就交给执行器，它和存储引擎直接交互，获得存储引擎返回的结果，并最后将结果展示。
5. 执行完毕，断开连接

### 执行器/存储引擎的执行方式有哪些?
1. 主键索引扫描：当使用等值查询对唯一主键进行查询时，会使用const作为查询方式，然后将条件交给存储引擎去查找第一条符合的记录，如果存储引擎没找到，则返回错误，如果存在则返回结果给执行器，执行器判断该记录是否符合，如果符合则返回，不符合的话会跳过该记录，然后由于访问类型为const，read record指针指向一个永远返回-1的函数，返回，结束。
2. 全表扫描：当查询的条件不是索引时，执行器会选择All的方式进行全表扫描。此时执行器先调用read first record，让存储引擎读取第一条记录，执行器会判断该记录是否符合，如果符合则发给用户，不符合则跳过。如此循环，直到存储引擎遍历结束，将全部结果返回给用户。
3. 索引下推：索引下推主要能够减少二级索引的回表次数。在没有索引下推的时候，如果对联合索引进行查找，根据最左匹配原则，执行器会调用存储引擎去查找第一个符合第一条件的记录，找到了之后根据主键进行回表查询，返回给执行器判断第二个条件是否符合，如果不符合则跳过，如此循环，直到结束。而当使用了索引下推，当存储引擎在二级索引中找到符合条件的记录的时候，会直接判断它是否符合第二个条件，如果不符合则直接跳过，如果符合则执行回表操作，返回数据。这样就减少了回表操作的次数。

### <font style="color:rgb(44, 62, 80);">表空间文件的结构是怎么样的？</font>
表空间主要有段、区、页、行组成。数据库表中的记录是按行存放的，而页是读写的基本单位，页是由行组成的，页的大小为16kb，区又是由64个页组成的，占1M的空间，主要就是按照区为单位进行空间分配。而表空间是由段组成的，段由多个区组成。主要包括索引段，数据段，回滚段。

### InnoDB的行格式有哪些
redundant、compact、dynamic、compressed

### <font style="color:rgb(44, 62, 80);">COMPACT 行格式长什么样？</font>
包括：变长字段长度列表、 null列表、记录头信息、row_id、trx_id、roll pointer、列1值、列2值......

<!-- 这是一张图片，ocr 内容为：变长字段长度列表 列1值 记录头信息 列N值 NULL值列表 列2值 TRX ID ROW ID ROLL_PTR 记录的真实数据 记录的额外信息 -->
![](https://cdn.nlark.com/yuque/0/2023/png/34998771/1679500029592-fbf74b99-f9df-472d-bf98-a152effa1b22.png)

### char和varchar有什么区别？
### 为什么「变长字段长度列表」的信息要按照逆序存放？
因为记录头信息的指针指向的是下一条记录的记录头信息和真实数据之间，这样做能够向左是记录头信息，向右是数据，比较方便。因此，变长字段长度列表逆序存放就可以保证靠前的数据和变长字段里的数据可以同时放在一个cpu cache line中，提高命中率

### 记录头信息有哪些内容？
+ delete_mask：记录这条信息是否被删除
+ next_record：指向下一条信息的指针
+ record_type：当前记录的类型，0表示普通记录，1表示b+树非叶子节点，2表示最小记录，3表示最大记录

### <font style="color:rgb(44, 62, 80);">varchar(n) 中 n 最大取值为多少？</font>
在MySQL中，除了TEXT、BLOBS这种大对象之外，一行数据不得超过65535字节，然后由于会有null列表和变长字段长度列表，因此还需要分别扣去1字节和2字节。

变长字段列表=“变长字段长度”总和

“变长字段长度”= n<=255 ？ 1字节 ：2字节；

最后，再将65532除以一个字符占的字节数，得到边长列表最大存储字符数。

### <font style="color:rgb(44, 62, 80);">行溢出后，MySQL 是怎么处理的？</font>
发生行溢出后，MySQL会把溢出的数据存储在额外的溢出页当中，并在当前行的话会有一个20字节的指针指向溢出页。

### MySQL 的 NULL 值是怎么存放的？
MySQL中，值为 null的列会在null值列表对应位置标记，但不会真正存在真实数据部分。而null值列表占1个字节，当所有字段都设置为非null时，就不会有null值列表。

### 数据页包含哪些部分？
文件头、页头、最大和最小记录、用户记录、空闲空间、页目录、文件尾

## 索引
### 什么是索引？有什么优缺点
索引就是用来进行快速检索的一种数据结构，我们可以为数据分配索引，来提升检索效率，也可以分配唯一性索引来保证数据的唯一性。

优点：索引的优点就是它的查询效率更快，且可以保证数据的唯一性

缺点：它的缺点就是创建索引和维护索引都需要额外的时间，同时索引需要存储，也需要额外的空间

### <font style="color:rgb(44, 62, 80);">索引的分类</font>
+ 按数据结构：B+树索引、hash索引
+ 按存储数据：聚簇索引、二级索引
+ 按字段特性：主键索引、唯一索引、普通索引、前缀索引
+ 按字段个数：单列索引、联合索引

### hash索引和b+索引有什么区别？
1. hash索引查询速度快，不发生哈希冲突时是O(1)的查询速度
2. 对于hash冲突严重的情况下，如重复值多的列，hash索引查询效率容易退化成O(n)
3. hash索引不适合范围查询，B+树适合
4. hash索引不支持联合索引

因此，数据库更适合使用b+树索引

### 什么是聚簇索引和非聚簇索引？
聚簇索引就是B+树的叶子节点存放的就是对应的数据，主键索引就是一种聚簇索引，而非聚簇索引则是叶子节点存放的是对应的主键值，可以根据其查询对应的主键值，再进行回表查询。二级索引就是非聚簇索引。

聚簇索引的优点就是查询速度很快，且能够对排序查找和范围查找进行优化，缺点就是依赖于有序数据，且更新的代价比较大。而非聚簇索引相比其优点就是更新的代价较小，缺点同样是依赖于有序数据，且需要回表查询。

### <font style="color:rgb(44, 62, 80);">B 树& B+树两者有何异同呢？为什么要选择B+树？</font>
1. B树的每个节点都存储索引和数据，而B+树只在叶子节点上存储数据，因此在数据量相同的情况下，B+树的非叶子节点可以存储更多的索引，使得整个树更矮胖，减少IO次数
2. B+树的每次查找过程都是从根节点到叶子节点的一条路径，相比于B树更加稳定，所有节点的查询效率都相当
3. B+树的叶子节点用双向链表连接起来，比起B树更适合范围查找

在选择索引的数据结构上，首先考虑的是降低查询的时间复杂度，而二分查找的复杂度为logn，相当于一颗二叉查找树，但如果每次插入都是最大的值，会导致二分查找树退化为链表，使得复杂的退化为On，因此需要使用平衡二叉查找树来解决。而对于数据库查询来说，树的高度就对应这磁盘IO的次数，因此我们需要降低树的高度，因此使用m叉树，将二叉树转为B树或B+树。

### 为什么不使用红黑树？为什么不使用跳表？
红黑树：

1. 红黑树依旧是个二叉树，相比于B+树它要更高，也就意味着查询时要做更多次IO操作，查询效率更低
2. 红黑树在维护上还需要进行颜色调整，对于频繁的修改操作，维护上更加耗时。

跳表：

跳表相对来说也是一个二分的思想，它的高度也会比B+树更高，所以对于MySQL来说，B+树更合适。

### <font style="color:rgb(44, 62, 80);">最左前缀匹配原则介绍一下</font>
最左前缀匹配原则主要是针对联合索引的，在创建联合索引的时候，会根据最左边的字段建立顺序索引，在查找联合索引的时候，则按照字段从左到右的顺序到查询条件中进行匹配，如果匹配到数据，则会进行过滤，当遇到<或>的时候，就会停止匹配，而遇到>=，<=，like，between操作则不会。因此，最好将区分度高的索引放在左边，这样效率更高，能够过滤更多的数据。

### 联合索引失效情况：
我们建立一个联合索引A, B, C

1. 查询条件是a、b、c时，无论是什么顺序，由于优化器优化，都会走INDEX_A_B_C联合索引；
2. 查询条件是a、b时，会走联合索引；
3. 查询条件是a、c时，也会走联合索引，只有a条件用到联合索引，但是c会触发索引下推
4. 查询条件是b、c时，不走联合索引；
5. 查询条件是a时，会走联合索引；
6. 查询条件是b时，不走联合索引；（在没有覆盖索引的情况下，如果只有abc，则会触发覆盖索引）
7. 查询条件是c时，不走联合索引；（在没有覆盖索引的情况下，如果只有abc，则会触发覆盖索引）

### 联合索引有长度限制吗？联合索引过长会有什么影响？
<font style="color:rgb(51, 51, 51);">mysql系统变量innodb_large_prefix未开启。如果系统变量innodb_large_prefix开启了，就会对使用dynamic或者是comperssed行格式的InnoD表，索引键长度限制为3072个字节了。如果没有开启这个，InnoDB会对，无论什么表索引键长度限制都是767了。</font>

<font style="color:rgb(51, 51, 51);">以下来自</font>在MySQL中，使用过长的联合索引会有以下影响：

1. <font style="color:rgb(51, 51, 51);"> </font>**磁盘空间消耗**<font style="color:rgb(51, 51, 51);">：较长的索引自然会占用更多的磁盘空间。尤其在大表中，索引可能会变得非常庞大。 </font>
2. <font style="color:rgb(51, 51, 51);"> </font>**插入速度降低**<font style="color:rgb(51, 51, 51);">：插入新记录时，MySQL需要更新索引结构。如果索引较长，这个过程会变得更加耗时，从而影响到插入性能。 </font>
3. <font style="color:rgb(51, 51, 51);"> </font>**更新开销**<font style="color:rgb(51, 51, 51);">：如果对涉及到索引列的数据进行修改，索引结构也需要相应地被修改，这会进一步影响到数据库的性能。 </font>
4. <font style="color:rgb(51, 51, 51);"> </font>**缓存效率下降**<font style="color:rgb(51, 51, 51);">：MySQL使用InnoDB引擎的表会在Buffer Pool中缓存索引，长索引意味着缓存的数据行数会减少，导致更频繁的磁盘I/O操作，从而降低查询效率。 </font>
5. <font style="color:rgb(51, 51, 51);"> </font>**查询速度受影响**<font style="color:rgb(51, 51, 51);">：在使用长索引进行查找时，比对索引值需要消耗更多的CPU时间，特别是在做范围查询或者需要排序的查询中。 </font>
6. <font style="color:rgb(51, 51, 51);"> </font>**备份和恢复**<font style="color:rgb(51, 51, 51);">：备份和恢复数据库时，索引的大小也会影响到这些操作的速度。 </font>
7. <font style="color:rgb(51, 51, 51);"> </font>**增加锁竞争**<font style="color:rgb(51, 51, 51);">：对于InnoDB存储引擎，更长的索引可能意味着在高并发情况下更大的锁竞争。 </font>

### <font style="color:rgb(44, 62, 80);">什么时候需要 / 不需要创建索引？</font>
索引的优点就是可以提高查询效率，但是也有一些缺点，如创建和维护索引需要耗费时间，且存储索引要耗费空间，在B+树中进行增删改的时候需要动态维护，也会降低效率。

因此，我们可以在一些场景中使用索引，比如：

+ 可以为具有唯一性的字段创建索引
+ 经常在查询、排序中经常用到的字段可以创建索引，比如where，orderby， groupby

而在一些场景中不去使用索引，比如：

+ 需要经常增删改的字段，不要创建
+ 不怎么用到的字段
+ 包含大量重复数据的字段
+ 表数据太少，也不需要建立索引
+ 含null的字段

### 什么是覆盖索引，什么是索引下推？
覆盖索引指的是对要查询的字段建立联合索引，这样在查询的时候就能够避免回表操作来提升效率。

索引下推指的是对条件字段去建立联合索引，如果没有建立，那么在匹配完第一个条件后，需要先进行回表查询，在根据查询到的数据进行第二个条件的判断，建立联合索引后，第一个条件比较完，如果第二个条件也存在，则会直接进行比较，失败的话之间跳过，这样就能够减少回表操作的次数，提升效率。

### <font style="color:rgb(44, 62, 80);">有什么优化索引的方法？</font>
+ 主键索引最好是自增的，这样能够减少B+树动态维护的开销
+ 避免索引失效，像比如对索引列使用左、左右模糊查找、或者对它进行了计算等操作，会导致索引失效，还有比如在联合索引中不遵循最左匹配原则也会导致索引失效，还有在where中，如果or前面的条件是索引列而后面的不是，也会导致索引失效。
+ 前缀索引优化，就是对于像char、varchar、text等字符串，可以对他们建立前缀索引，来减小索引字段的长度
+ 覆盖索引优化，就是对于要查询的这些字段建立联合索引，来避免回表操作
+ 索引下推：就是在MySQL5.6之后，我们可以在非聚簇索引的时候先对索引中包含的字段进行判断和过滤，从而减少回表次数
+ 慎重考虑索引的创建
+ 限制每张表上的索引数量
+ 尽可能使用联合索引而不是单列索引
+ 删除长期未使用索引

### <font style="color:rgb(44, 62, 80);">常见扫描类型有哪些</font>
1. 全局扫描
2. 全索引扫描
3. 索引范围扫描
4. 非唯一索引扫描
5. 唯一索引扫描
6. 结果只有一条的主键或唯一索引扫描

### 左模糊匹配一定会导致索引失效吗？
不一定，当数据表中只有主键和二级索引时，会使用全二级索引扫描。

当满足覆盖索引的时候，就会使用全二级索引扫描，比全表扫描效率更高。

### 导致索引失效的情况？
1. 对索引进行了计算、函数、类型转换、隐式转换等操作
2. 最左、左右模糊匹配
3. or字段前后如果有一个不是索引，就会导致索引失效
4. 不满足最左匹配原则

### varchar a = 1 和 int a = '1'的索引失效情况
会发生隐式类型转换，会将varchar转为int型，对于第一种情况，会对a发生隐式类型转换，导致索引失效，对于第二种情况，只会将左边的'1'转换为int型，不会索引失效。

### EXPLAIN关键字有哪些字段？
possible_keys（条件字段中存在索引的字段列出来）、key、key_len、type

## 事务
### MySQL中四种隔离级别分别是怎么实现的？
+ 读未提交：直接执行操作就是读未提交
+ 读已提交和可重复读主要是基于read view来实现的，它们两者的区别主要在于read view的时机不同，对于读已提交来说，在语句执行前，会执行read view快照，而对可重复读来说，事务开启时就会创建read view快照， 并且在这期间都是使用这个快照。

### 有几种开启事务的方式？
1. start/begin transaction：这种方式不会立即开启事务，只有执行了增删改查操作的sql语句时，才会开启事务
2. start transaction with consistent snapshot：立即开启事务

### 什么是read view？如何工作的？
read view当中记录了几个东西：创建该read view的事务id、最小事务id、已开启但未提交的事务id列表、下一个事务id。对于当前事务来说，min_trx_id之前的数据是可见的。在每一行数据中，innodb会为他插入两个隐藏字段，一个是trx_id，一个是roll pointer，指向上一个旧版记录，可以根据这个链表查询所有旧版记录。

**可重复读：**对于可重复读来说，它是在事务启动的时候创建read view。当事务执行查询操作的时候，会判断当前行的trx_id是否在min id之前，如果在的话直接读取，如果在m_ids列表中，则会顺着undo log链表查找到第一个id小于min id 的数据进行读取。且可重复读是基于启动时的read view进行执行的，就算启动后m_ids中的事务提交了，其依然不会读取到这些事务提交的值

**读已提交：**对于读已提交来说，每次操作前创建read view，那么当 一个事务的修改未提交时，创建的read view中的m ids有这个事务，就不会读到，当事务提交后，再查询的时候就会读到修改的数据。

### InnoDB中解决幻读的方法
innodb中解决幻读主要有两种方法：mvcc 和 next-key lock

+ 针对快照读，即普通的select，我们可以使用mvcc很好的解决幻读。因为你在开启事务时创建read view，即使这中间有其他事物插入了数据，这条数据对你也是不可见的。
+ 针对当前读，即select...for update，我们可以使用next-key lock来解决。如果有其他事物在next-key lock范围内插入一条记录，则插入操作会被阻塞。

### 快照读和当前读的区别？
快照读就是普通的select，时使用MVCC来实现的，通过read view判断哪些事务是可见的。

当前读包括select...for update、insert、update、delete，是通过nk锁来实现的。

### 可重复读完全解决了幻读吗？
并没有完全解决，像比如当事务A开启，查询一条数据，为空，此时事务B插入了这条数据，A直接修改这条数据，然后再次查询的话就查得到了，产生了幻读

而对于当前读，如果事务开启的时候，先执行快照读，然后有其他事务插入数据后再执行当前读查询时，就会发生幻读。所以最好在事务开启后先执行当前读。

## 锁
### 全局锁有什么用?
全局锁主要用于全库逻辑备份。当使用全局锁时，数据库处于只读状态，这可能会影响业务。因此，像innodb引擎在备份数据库的时候，会先开启业务创建 read view，并且根据read view进行备份，此时，其他业务可以正常执行，也不会影响到数据库的备份。

### 表级锁有哪些?
表级锁包括表锁、元数据锁、意向锁、auto inc锁

+ 表锁：可以通过lock tables xxx read/write来为表添加共享读锁或独占写锁，它的缺点就是加锁期间会限制其他线程以及自己的操作，粒度较大，性能较低。
+ 元数据锁：元数据所MDL主要是用来保证表结构的正确修改。当我们执行CRUD操作的时候，需要加MDL读锁，当我们修改表结构的时候就需要加MDL写锁。MDL锁不需要显式调用，当事务提交后才会释放。如果遇到长事务占据MDL读锁，导致一个MDL写锁被阻塞的时候，其之后的所有读锁也会被阻塞，这是因为申请MDL锁的操作会形成一个队列，而写锁获取的优先级高于读锁。因此最好在修改表结构前先kill掉长事务。
+ 意向锁：意向锁的主要目的就是为了快速判断表中是否有记录被加锁。当我们要给一行记录加共享锁或独占锁时，会在表上加意向共享锁/意向独占锁，此时，如果有独占表锁想加，就会判断是否存在意向锁，有则失败，这就避免了独占表锁去表中一行行判断是否存在锁。
+ AUTO_INC 锁：这个锁主要就是用来实现主键自增的。当我们插入一个语句时，会申请auto inc锁，然后为主键字段赋值，当插入语句执行完成后释放该锁。但是当auto inc锁在对大量数据进行插入操作的时候，其他事务的插入操作会被阻塞，因此性能较低。后来innodb提供了一个更轻量级的mutex锁，来实现。这个锁就是在为主键赋值完之后就立即释放，不需要等到语句执行完。innodb也提供了一个系统变量innodb_atonic_lock_mode来控制选择auto inc锁还是mutex锁。他有三种模式:
    - innodb_atomic_lock_mode =  0：代表使用auto_inc锁
    - innodb_atomic_lock_mode = 1：代表普通insert语句采用mutex模式，而insert...select的批量插入还是采用auto_inc模式
    - innodb_atomic_lock_mode = 2：采用mutex模式

### 轻量级锁会有什么问题？
轻量级锁当和binlog的statement日志格式搭配的时候可能会出现主从不一致的问题。这是由于在并发情况下，如果一个线程对表执行一个插入语句，这个插入语句中会插入多行，此时，如果另一个线程也对这个表执行插入，那么由于交叉分配，另一个线程就会插入到中间来。而对于binlog而言，他记录的是执行的顺序，而且在从库复制的时候也是按顺序来执行，因此会等多个语句插入之后才会插入另一个线程的语句，就导致了主从不一致。

### 行级锁有哪些？
行级锁包括记录锁、间隙锁和next-key lock、插入意向锁

+ 记录锁：锁住一条记录，分为读锁和写锁
+ 间隙锁：锁住一个范围，不含记录。主要用来防止在范围内插入数据。
+ next-key lock：记录锁+间隙锁。主要用来解决幻读的情况，既能解决幻读，又能保护记录。在互斥情况下，不允许相同范围，但允许范围交叉。
+ 插入意向锁：当要插入的时候，会判断是否有间隙锁，如果有则会生成一个插入意向锁，并设置为等待状态，当间隙锁释放，开始执行插入。相当于一种特殊的间隙锁

### MySQL是如何加行级锁的？
1. 唯一索引等值查询：存在则退化为记录锁，不存在则退化为间隙锁（如果遍历到了最后一条记录，则还是nk锁）
2. 唯一索引范围查询：
    1. >、>=：
        1. >全是nk锁
        2. >=当值不存在时和>一样，值存在时，值的记录加上记录锁，后面都是next-key lock锁
    2. <、<=：
        1. 值不存在：边界是间隙锁，前边是next-lock锁
        2. 值存在：<=边界是next-lock锁，<和值不存在一样
3. 非唯一索引等值查询：
    1. 值不存在：添加间隙锁，两头是否能插入要根据主键判断，看插入位置的下一条记录是否持有间隙锁，有则无法插入
    2. 值存在：值左边添加next-key lock，（对应主键添加记录锁），右边添加间隙锁。此时无法插入该查询值的记录（被nk和gap覆盖了）
4. 非唯一索引范围查询：全都用nk锁，不会退化（对应主键添加记录锁）
5. 没加索引查询：相当于全表扫描，每一条记录都会加nk锁

### 删除操作会加什么锁？
在非唯一索引的情况下，删除一条存在的记录是有gap锁，锁住记录本身和记录之前的gap

在唯一索引和主键的情况下删除一条存在的记录，因为都是唯一值，进行删除的时候，是不会有gap存在

非唯一索引，唯一索引和主键在删除一条不存在的记录，均会在这个区间加gap锁

通过非唯一索引和唯一索引去删除一条标记为删除的记录的时候，都会请求该记录的行锁，同时锁住记录之前的gap

RC 情况下是没有gap锁的，除了遇到唯一键冲突的情况，如插入唯一键冲突。

### 插入时会加什么锁？
插入时会首先加入一个插入意向锁，如果存在间隙锁则阻塞等待，不存在则进行写入。写完之后，记录上会存在一个隐式锁。当其他线程来插入/读取时，会触发隐式锁转换为x型的记录锁，因此会导致主键冲突，也可以避免幻读。

### update没加索引会导致什么结果？
update没有加索引条件的话，会进行全表查询，默认会对每一条记录加nk锁，相当于就对表上锁了，这可能导致大量的事务阻塞，影响业务，甚至崩溃。正确的解决办法可以将sql_safe_updates的参数设为1，这样就代表在更新时必须在where种带上索引，或使用limit，或者wherelimit一起用。

### <font style="color:rgb(44, 62, 80);">MySQL 记录锁+间隙锁可以防止删除操作而导致的幻读吗？</font>
可以的。间隙锁可以防止插入导致的幻读，而记录锁的话就能够防止删除导致的幻读。在加锁过程当中会为每一个符合条件的记录加上记录锁，保证不被删除

### MySQL怎么会产生死锁？如何避免？
比如当事务A先加了一个间隙锁，然后事务B加了一个同样的间隙锁，接下来事务A想要在这中间插入，想添加插入意向锁，此时就会被阻塞，事务B也想插入的话，同样会被阻塞。

避免死锁:

1. 设置等待超时时间，当事务等待超时之后，就会发生回滚，从而使得其他事务能够继续执行
2. 开启主动死锁检测，将innodb_deadlock_detect设置为on，发生死锁时，就会让死锁链中的一个事务发生回滚，使得其他事务继续执行。

### MySQL中的乐观锁和悲观锁
乐观锁和悲观锁是一种锁的设计思想。

悲观锁是。。。在MySQL当中的表锁和行锁都是悲观锁的思想。

乐观锁是。。。在MySQL中的话主要通过程序来实现，比如添加版本字段或者时间戳，通过对比版本判断是否一致来判断记录是否被其他事务修改，如果被修改的话则回滚事务，并通过重试或者一些兜底措施进行处理。

## 日志
### MySQL中有哪几种日志？
+ undo log：主要用于事务回滚，保证事务的原子性，同时它也是实现MVCC的关键手段之一
+ redo log：用于数据库的故障恢复
+ binlog：用于数据库备份或主从复制

### undo页记录的是什么?
undo页主要就是记录undo log的信息，innodb更新数据前会生成undolog，并且写入undo页中

### 查询一条记录，就只需要缓冲一条记录吗？
不是的，查询一条记录innodb会将整个页写入到buffer pool当中，再到页当中进行查找。

### 为什么需要redo log
redo log主要就是用来进行数据库的恢复的。当我们更新一条记录的时候，redo log会记录下这个更新操作，如果在该记录被写到磁盘前发生故障，重启时我们就可以用redo log进行恢复。redo log保证了数据库的持久性。

### 修改undo页需要写入redo log吗？两者有啥区别？
需要的，在执行一条操作前，会先记录响应的undo log，写入undo页，如果undo页发生修改，也是要写到redo log中的。undo log主要用于事务的回滚，它记录的是事务提交前的数据，它可以保证原子性，而redolog主要用于故障恢复，记录的是事务提交后的数据，可以保证持久性。

### redo log 要写到磁盘，数据页也要写磁盘，为什么要多此一举？
1. 写入redo log的话只需要进行追加操作，写入磁盘是顺序写，而数据插入的话需要寻找到写入位置再插入，是随机写，因此redo log的写入性能要比数据写入高，它将写操作从随机写变为了顺序写，提升了写数据的性能。
2. redo log还可以用来做安全恢复

### 产生的 redo log 是直接写入磁盘的吗？
不是的，每当产生一条redo log，也会先记录到redo log buffer缓存当中，后续再写入磁盘。redo log buffer默认大小是16mb，增大其大小可以让大事务不用写入磁盘，提升性能。

### redo log什么时候刷盘？
1. 后台线程每隔1秒进行一次刷盘
2. MySQL正常关闭的时候
3. redo log buffer使用内存空间大于一半的时候会刷盘
4. 事务提交的时候会进行刷盘，这个可以由	innodb_flush_log_at_trx_commit参数控制

### innodb_flush_log_at_trx_commit 参数控制的是什么？
它主要由三种模式：

+ 0：代表每次事务提交都不redo log buffer刷盘，每隔一秒进行一次刷盘
+ 1：每次事务提交都进行redo log buffer刷盘
+ 2：每次事务提交，将redo log buffer写入到page 缓存当中，但还没有写入磁盘，调用fsync进行刷盘

当对于数据安全有较高要求的时候，可以使用模式1，当对于写入性能有较大要求的时候，可以使用模式2

### innodb_flush_log_at_trx_commit 为 0 和 2 的时候，什么时候才将 redo log 写入磁盘？
0的时候每隔一秒就进行刷盘，但是这可能会丢失上一秒的数据

2的时候会调用fsync方法将page cache写入到磁盘中，因此不会丢失数据，只可能由于系统崩溃、断电等因素出现问题。

### <font style="color:rgb(44, 62, 80);">redo log 文件写满了怎么办？</font>
redo log里边有一个redo log group，他里面含有两个日志文件，用一个循环写的方式来执行，当一个文件写满后，写另一个文件，另一个文件写满后，再写第一个文件。因为redo log记录了哪些脏页需要刷盘，当脏页刷盘了之后记录也就没用了，就可以覆盖。但是当脏页刷盘的速度跟不上redo log刷盘的速度的时候，日志文件会满，此时就会阻塞，然后执行脏页刷盘，再将日志文件中可以清除的数据清除，然后再恢复正常运行。

### binlog是什么？和redolog有什么区别？
binlog日志主要用于数据库备份和主从复制。它和redolog主要有几个区别：

1. 适用对象不同：binlog是server层实现的日志，任何引擎都能用，而redo log是innodb实现的日志
2. 文件格式不同：redo log记录的是对数据页的修改，而binlog有三种实现模式：
    1. statement：逻辑日志，记录的是每个更新操作的sql语句，在主从复制中，从端根据这些语句进行复制，缺点是容易和动态函数使用发生错误
    2. row：物理日志，记录的是每一行修改的结果，缺点就是日志文件太大
    3. mixed：自适应使用statement或row
3. 用途不同：binlog主要用于数据库备份或主从复制，而redo log主要用于数据库崩溃后的安全恢复。
4. 写入方式不同：binlog是顺序写，写满就新建一个文件，而redo log 是循环写，写满了会覆盖写

### 如果不小心整个数据库的数据被删除了，能使用 redo log 文件恢复数据吗？
不行的，因为redo log是循环写，之前的操作会被覆盖，因此只能用binlog进行恢复。

### binlog能用来实现故障恢复吗？为什么？
主要原因有两点:

1. binlog是逻辑日志，且有多种模式，它记录的是sql语句，而没有落实到具体的数据页，可能在重放的时候发生错误，而redo log是物理日志，它记录的是对数据页的修改，重放的时候能够保证正确。
2. redo log的两阶段提交：当执行完更新操作，更新到内存（buffer pool）之后，会生成redo log，并且写入redo log

### <font style="color:rgb(44, 62, 80);">主从复制是怎么实现？</font>
客户端提交一个事务的时候，主库会写入binlog，然后再提交事务，返回给客户端成功。而从库会专门创建一条IO线程，连接主库的log dump线程，获取binlog信息，并写入自己的relay log中继日志中，并返回给主库复制成功的响应。然后根据中继日志，创建一个线程进行回放，更新到数据库当中。

### 从库是不是越多越好？
不是的，从库越多代表连接的io通道越多，主库也要创建同样多的log dump线程，对资源消耗很高。

### MySQL 主从复制还有哪些模型？
主要有三种:

1. 同步：提交事务的线程需要等待从库复制成功的响应，缺点就是性能太差
2. 异步：提交的事务不需要从库复制成功的响应，就直接返回，缺点是主库宕机可能导致数据丢失
3. 半同步：提交的事务不需要所有从库的响应，只需要一部分即可，兼顾了同步和异步的优点，又不会导致数据丢失

### <font style="color:rgb(44, 62, 80);">binlog 什么时候刷盘？</font>
事务执行过程当中，server层会将日志写到每个线程自己的binlog cache当中，事务提交的时候再将binlog cache写到binlog日志文件中。

binlog cache的刷盘有三种模式，可以用sync_binlog进行控制：

1. 0：事务提交时执行write，将binlog cache写入系统的page cache，由系统决定什么时候执行fsync写入文件
2. 1：事务提交时执行write将binlog cache写入page cache，系统直接执行fsync（直接刷盘）
3. N：事务提交时write将binlog cache写入page cache，攒够n个再执行fsync

### 一条update语句的执行过程
经过连接、分析器、预处理器、优化器，来到执行器，执行器调用innodb接口，通过索引查找记录，如果记录存在于buffer pool当中， 直接返回，不存在则需要到磁盘中读取到buffer pool中。然后执行器判断是否需要更新，需要的话就将新值交给innodb，innodb就会开启一个事务，并记录undo log，写入buffer中，然后innodb更新数据，设置为脏页，并生成redo log，然后准备提交事务，redo log写入redo log buffer当中，并处于prepare状态，然后会生成binlog，写入binlog cache当中，最后将redo log修改为commit状态，提交事务。

### 为什么要两阶段提交？
主要就是为了保障数据库故障的安全回复，避免redo log和binlog写入出现半成功导致主从不一致（即只有一方写入）

第一个阶段，生成redo log并且进行持久化，此时redo log状态为prepare

第二个阶段，生成binlog并进行持久化，然后将redo log状态修改为commit

如果在第二个阶段前，发生故障，重启时会检查redo log中的事务ID在bnlog中是否存在，如果不存在则会根据undo log执行回滚操作，如果存在的话正常提交

如果在binlog持久化之后发生故障，重启时则正常提交。

### 处于 prepare 阶段的 redo log 加上完整 binlog，重启就提交事务，MySQL 为什么要这么设计?
因为写入binlog说明从数据库也能看到这个数据了，事务正常提交才能保证主从一致。

### <font style="color:rgb(44, 62, 80);">两阶段提交有什么问题？</font>
1. 磁盘IO次数多：两阶段提交中，redo log 和binlog分别会将自己写入对应的缓存中，而一般为了保证数据不丢失，会将这两个缓存的控制状态设为1，也就是redo log每次事务提交的时候都刷盘，binlog每当写入binlog cache的时候都刷盘，相当于一次事务提交需要两次刷盘操作，io次数自然就高了。
2. 锁竞争激烈：在MySQL的早期版本中，是使用锁来保证多线程事务提交的有序性，而随着并发量的提升，锁竞争激烈，导致性能下降。

### 什么是组提交，如何IO次数多的问题？
可以使用组提交来解决IO次数多的问题。组提交就是按照事务顺序，组成一个组，再将这个组一起提交。

在组提交的过程中，分为flush、sync、commit三个阶段

1. flush：在flush阶段会对一个事务组产生的redo log进行write+fsync，并且将相应的binlog写入page cahce
2. sync：sync阶段会等待一段时间，组合更多的binlog，然后对这些binlog进行刷盘
3. commit：调用引擎的提交事务接口，将redo log改为commit

此外，还可以通过设置binlog_group_sync_delay和binlog_group_commit_sync_no_delay_count来延迟binlog刷盘，进一步减小io次数。或者设置innodb_flush_log_at_trx_commit为2，延迟redo log刷盘时机。

|  | undo log | redo log | binlog |
| :---: | :---: | :---: | :---: |
| 主要作用 | 日志回滚 | 故障恢复 | 备份、主从复制 |
| 生成时机 | 更新之前生成，写入undo页 | 更新之后，记录页的变化 | redo log之后 |
| 刷盘时机 | 不刷盘 | innodb_flush_log_at_trx_commit<br/>0：事务提交，每隔一秒进行一次刷盘<br/>1：事务提交就刷盘<br/>2：事务提交，写入page cache，系统刷盘 | sync_binlog<br/>0：事务提交，写入page cache等系统刷盘<br/>1：事务提交直接刷盘<br/>N：事务提交，在page cache中攒N个再刷盘 |

## 内存
### 什么是Buffer Pool？有什么用
buffer pool是一个缓冲池，主要的作用就是来提升数据库的读写性能。当我们读取记录的时候，就可以先到buffer pool当中进行查找，如果存在直接读取，不存在再去磁盘中读取。写记录，一样，如果存在，则进行修改，并将该记录的数据页设置为脏页，后台线程会寻找合适的时机将脏页写入磁盘。

### Buffer Pool 缓存什么？
buffer pool是以页为单位进行缓存的，缓存的内容包括数据页、索引页、undo页、锁信息、插入缓存页、自适应哈希索引

### 介绍一下buffer pool
buffer pool是innodb设计的一个缓冲池，主要用来提升读写速度。在MySQL启动的时候，innodb会申请一块连续的内存区域作为buffer pool，并且将其划分为一个个的页，每个页大小为16kb。用来存放数据页、索引页、undo页等等......

为了避免每次需要读取数据的时候都要遍历内存，buffer pool为每个页设置了一个控制块，并且利用不同的链表来管理不同的页。

Free链表主要用来管理空闲页，Flush链表主要用来管理脏页，LRU链表主要用来管理普通页。这样就能够通过链表快速找出我们需要的页。

### 介绍一下LRU链表，有什么好处？
LRU链表主要用来管理存储数据的普通页，为了提高缓存命中率，我们希望越经常访问的数据在链表前端，而那些不经常访问的放在后面，并且当需要进行淘汰的时候也是淘汰后面的页，因此，LRU能够满足我们的需求。因此，当我们访问的页在buffer pool中，就把他移动到链表头部，不存在则读入缓存，再加入链表头部，可能还要淘汰尾部数据。

但是会有几个问题，预读失效和buffer pool污染

### 什么是预读失效？
innodb在读取数据页的时候，会将相邻的页也读取到buffer pool当中，然而这会导致一个问题，有可能这些预读的数据根本不会被访问，但是他却放在了链表的前面，甚至还需要淘汰掉后面的一些可能的热点数据。因此这就会产生一个预读失效的结果。解决预读失效的方法就是不要让读取的页一下子就放在头部，因此innodb分了young区和old区，读取数据的时候先放入old区的头部，当数据被访问的时候再添加到young区头部

### 什么是buffer pool污染？
虽然young区和old区解决了预读失效的问题，但是当我们进行大量的语句扫描或者全表扫面的时候，就会导致大量的数据页读到缓存当中，这会导致之前的热点数据被清除，但是许多我们读进来的页只会被使用一次，这就造成了污染，解决的方法就是提高进入young区的门槛。因此，一条数据要进入young区，需要满足两个条件：被访问+在old区存在一定时间以上。此外，innodb还规定，young区前四分之一的节点不会被移动到头部，后四分之三才会。

### <font style="color:rgb(44, 62, 80);">脏页什么时候会被刷入磁盘？</font>
1. MySQL正常关闭
2. MySQL空闲时
3. redo log日志满了
4. buffer pool满了

## 调优
### 慢查询怎么解决？
可以先开启慢查询日志，记录慢查询语句。

可能原因：索引失效、优化数据库结构（字段太多进行分解、联合查询可以建立中间表提高查询效率、添加冗余字段）、优化limit分页、分解关联查询

1. 优化索引：<font style="color:rgb(44, 62, 80);">最左前缀匹配原则、=和in可以乱序、索引列不能参与计算、尽量扩展索引，而不要新建索引</font>
2. <font style="color:rgb(44, 62, 80);">explain查看执行计划，分析结果，调整语句</font>

### limit调优？
limit在查询后面的数据的时候会出现性能不好的原因主要是limit 200000， 10 会先读索引，再读数据，并查询出200010条数据，再将前面的无用数据丢弃。

要优化limit，对于有序主键我们可以使用子查询，在子查询中先使用主键索引进行定位，然后让id>=子查询结果，这样我们只需要读取索引，速度更快。

对于无序主键则可以使用iner join进行优化。

### 如何分页分表？

# Redis
## 基础概念
### 介绍一下Redis
redis是一个基于内存的数据库，读写速度非常快，常用于缓存、消息队列、分布式锁等场景

同时它对数据类型的操作都是原子性的，执行指令由单线程执行，不存在并发竞争

它还支持事务、持久化、lua脚本、主从复制、哨兵、发布订阅、等等

### <font style="color:rgb(44, 62, 80);">Redis 为什么这么快？</font>
1. 首先redis是一个基于内存的数据库，因此它的读写操作非常快
2. 其次他基于reactor模式设计了一套事件处理模型，主要包括单线程事件循环和IO多路复用
3. //还有它内置了多种优化后的数据结构， 性能也更好

### <font style="color:rgb(44, 62, 80);">分布式缓存常见的技术选型方案有哪些？</font>
memcached、redis、腾讯开源的redis

### <font style="color:rgb(44, 62, 80);">Redis 和 Memcached 有什么区别？</font>
首先redis和memcached有一定的共同点：

1. 都是基于内存的模型，读写非常快，常用作缓存
2. 都支持过期策略
3. 性能都很高

不同之处在于：

1. redis支持比memcached更加丰富的数据结构，像string、hash、list、set、zset等等
2. redis支持数据的持久化，所以也可以灾难恢复
3. redis原生支持集群模式
4. redis支持发布订阅模型、lua脚本、事务等功能，这些都是memcached不具备的
5. memcached过期删除策略只用了惰性删除，而redis包括惰性删除和定期删除

### <font style="color:rgb(44, 62, 80);">为什么用 Redis 作为 MySQL 的缓存？</font>
主要是因为redis具有高性能和高并发两个特性。

高性能就是redis是基于内存的数据库，直接对内存进行读写，相比于mysql性能要高得多

高并发就是redis能够承受的并发访问量是远远大于MySQL的，所以可以吧一部分的数据存放到redis当中，来提升效率

### Redis支持事务吗？
redis支持事务，但是redis中的事务更像是一种多条语句打包执行的操作，他并没有像MySQL一样支持事务回滚，也就是说并不保证原子性。

## 数据结构
### <font style="color:rgb(44, 62, 80);">Redis 数据类型以及使用场景分别是什么？</font>
常见数据类型：string、hash、list、set、zset，后来添加的一些数据类型：bitmap、hypeloglog、GEO、stream

+ string：缓存对象、计数器、分布式锁、共享信息
+ hash：（键值对集合）缓存对象、购物车
+ list：消息队列
+ set：求并集、交集、差集的场景，如点赞、共同关注、抽奖等
+ zset：排序场景，如排行榜、电话和姓名排序
+ bitmap：二值状态统计，如签到、用户状态等
+ hyperloglog：海量数据计数统计场景
+ GEO：地理位置信息，如滴滴打车
+ stream：消息队列，相比于list，自动生成全局唯一id，支持以消费组形式消费数据

### String的内部实现？
string内部是由SDS，简单动态字符串实现的，它相比于基于C语言的这种字符串，有几点好处：

1. 它是以len来判断是否结束，而不是用空字符，因此它不仅可以存储文本，还可以存储二进制数据，也就是收它可以存图片、视频、音频等等数据
2. 它获得字符串长度是O(1)的复杂度，因为它会记录自身的长度
3. 它的拼接不会造成缓冲区的溢出，因为它拼接的时候会判断SDS空间是否足够，如果不够的话会进行扩容
+ <font style="color:rgb(44, 62, 80);">如果所需的 sds 长度</font>**<font style="color:rgb(48, 79, 254);">小于 1 MB</font>**<font style="color:rgb(44, 62, 80);">，那么最后的扩容是按照</font>**<font style="color:rgb(48, 79, 254);">翻倍扩容</font>**<font style="color:rgb(44, 62, 80);">来执行的，即 2 倍的newlen</font>
+ <font style="color:rgb(44, 62, 80);">如果所需的 sds 长度</font>**<font style="color:rgb(48, 79, 254);">超过 1 MB</font>**<font style="color:rgb(44, 62, 80);">，那么最后的扩容长度应该是 newlen </font>**<font style="color:rgb(48, 79, 254);">+ 1MB</font>**<font style="color:rgb(44, 62, 80);">。</font>

### String如何实现分布式锁？
主要依赖于SETNX语句，并且设置过期时间来防止客户端异常导致一直不释放锁。<lock_key - 客户端ID>

解锁时则需要借助lua脚本来保证原子性。

### List如何实现消息队列？
要实现一个消息队列，就是生产者消费者模型，需要满足三个条件：

1. 消息的有序性：根据先进先出原则，利用LPUSH+RPOP实现，BRPOP实现阻塞式读取
2. 不重复性：生产者生成全局唯一ID
3. 安全可靠：BRPOPLPUSH实现备份

### Hash如何实现购物车？
由于hash存储的是一个键值对集合，因此我们可以在一条记录里面存储用户id、商品id、商品数量等等信息，然后可以根据用户id来获取购物车。 cart::userid : { <skuId, cartItemJSON>, <skuId, cartItemJSON>, ... }

### <font style="color:rgb(44, 62, 80);">String 还是 Hash 存储对象数据更好呢？</font>
string存储的时序列化后的对象数据，存放的是整个对象，而hash按照字段单独存储，因此当我们需要对一个对象的部分字段进行读取的时候可以使用hash，但string相对更加节省内存，一般情况下还是用string

### Set如何实现抽奖？
如果允许重复中奖，可以使用SRANDMEMBER来进行获取，如果不允许的话可以使用SPOP

### ZSet如何实现排行榜？
将所有的文章和它的权重值记录到ZSet当中，ZSet会根据 score进行排序，我们可以使用ZREVRANGE start stop WITHSCORE命令来获取前N个记录（正序ZRANGE）

### 如何实现签到统计？
可以使用bitmap实现签到统计，为每个用户设置一个bitmap，使用setbit offset 1，命令代表其第offset天签到了，可以用bitcount来统计签到天数，bitpos key 1来获得首次签到日期

### 如何实现连续7天签到用户统计？
我们可以将日期作为key，用户id作为offset设置一个bitmap，用户在这一天打卡就把他对应的位置置为1，设置7个这样的bitmap，进行与运算，结果为1的用户就是连续打卡了7天

### Stream实现的消息队列和List的有什么区别？
stream实现的消息队列，对于list主要有几个升级：能够自动生成全局唯一ID，支持消费组

1. 消息保序：XADD, XREAD
2. 阻塞式读取：XREAD Block
3. 不可重复读：使用XADD时自动生成全局唯一ID
4. 安全性：内部使用PENDING LIST来存储被消费者读取的信息，当消费者XACK返回确认信息后，就会删除，如果没有收到信息就会保留，消费者重启之后可以使用XPENDING命令查看已读取但未处理的消息
5. 支持消费组：XGROUP

### Redis 基于 Stream 消息队列与专业的消息队列有哪些差距？
差距主要体现在两个方面：数据丢失和数据堆积

1. 数据丢失：一个消息队列的数据丢失可能发生在三个地方：生产者、消息中间件、消费组，对于redis而言，生产者在写入消息中间件的时候，只要处理好返回值、异常和失败重发的操作，就不会发生数据丢失。对于消费者而言，redis利用内部队列来保证了消费者数据不会丢失，而对于redis的消息中间件而言，宕机、主从切换都有可能导致数据丢失，因此专业的消息队列，他们会对消息中间件进行集群部署，有多个副本，来解决数据丢失问题。
2. 对于数据堆积，为了防止OOM，redis实现的消息队列会设置最大长度，当长度满的时候，旧消息会被删除。因此面对消息挤压，内存资源会紧张，而专业的消息队列，他们直接对数据进行持久化，不用担心数据堆积问题。

### SDS
SDS用来表示字符串。他相比于C语言中的字符串有以下优势：

1. 记录字符串长度len，获取长度的时间复杂度为O(1)
2. 用len判断字符串结束，而不是空字符，因此可以存储各种格式的数据
3. 不会发生缓冲区溢出，可以根据alloc和len判断剩余空间，如果不足可以进行扩容
4. 灵活的类型分配，根据长度的大小，分配不同的类型，比如int32、int16等，减小结构体的大小
5. 取消结构体的字节对齐，不会按照最大的类型长度去分配空间

### 链表
优势如下：

1. 双向链表，能快速获取前驱和后继
2. 有head和tail，获取头尾节点的时间复杂度为O(1)
3. 保存len，获取长度时间复杂度为O(1)
4. 可以保存不同类型的值

缺陷：

1. 内存不连续，无法很好的利用CPU缓存（连续内存可以通过预读提升效率）
2. 每个链表节点都需要一个链表节点结构头的分配，内存开销更大

### 压缩列表
优势：适用于保存节点数量不多的场景

1. 占用连续内存空间，可以充分利用CPU缓存
2. 针对不同长度的数据，进行相应的编码，节省内存开销
3. 获取头尾元素的时间复杂度为O(1)

劣势：

1. 元素过多时查询效率低
2. 连锁更新问题

连锁更新问题：

每个列表节点记录了三个值：前驱节点长度、自身值类型和长度、具体值

当插入元素或修改元素的值过大时，超出后续节点记录的前驱节点长度，可能导致后续每个节点的prevlen都需要更新，引起连锁更新问题，导致每个节点都要重新分配（为了能从后向前遍历）

<!-- 这是一张图片，ocr 内容为： -->
![](https://cdn.nlark.com/yuque/0/2023/png/34998771/1693541622755-9a2e016e-4c3b-497d-888a-e1354ccb0e8b.png)

### 哈希表
优势：

1. 以O(1)复杂度查询

哈希冲突解决：链式哈希

**rehash：**

redis采用了两张哈希表，在哈希表1上写入，当触发rehash时，哈希表2会分配空间，一般是2倍扩容，然后把哈希表1的元素迁移到2中，再将哈希表1释放。但如果「哈希表 1 」的数据量非常大，那么在迁移至「哈希表 2 」的时候，因为会涉及大量的数据拷贝，此时可能会对 Redis 造成阻塞，无法服务其他请求。

**渐进式rehash：**

给哈希表2分配空间，同时每次增删改查操作的时候，会顺序的将「哈希表 1 」中索引位置上的所有 key-value 迁移到「哈希表 2」 上；随着处理客户端发起的哈希表操作请求数量越多，最终在某个时间点会把「哈希表 1 」的所有 key-value 迁移到「哈希表 2」，从而完成 rehash 操作。（迁移，不是复制）

这样做把哈希表的迁移操作分摊到多次操作上，避免阻塞。

ps：渐进式rehash中，增删改查操作会在两个表上进行。（查的时候先查1，再查2，插的 时候直接插2）

**rehash触发条件 ：**

+ 当负载因子大于等于 1 ，并且 Redis 没有在执行 bgsave 命令或者 bgrewiteaof 命令，也就是没有执行 RDB 快照或没有进行 AOF 重写的时候，就会进行 rehash 操作。
+ 当负载因子大于等于 5 时，此时说明哈希冲突非常严重了，不管有没有有在执行 RDB 快照或 AOF 重写，都会强制进行 rehash 操作。

### 整数集合
Set的底层实现之一，同样根据不同的数据长度，开辟不同长度的数组，同时有一个升级操作：

当插入的数据大于当前数组类型长度时，触发升级，将数组升级为更大的类型，并更新长度。（每一格都更新为欣的数据类型）

### 跳表
跳表实现了一个多级链表，是zset的底层数据结构。zset 结构体里有两个数据结构：一个是跳表，一个是哈希表。这样的好处是既能进行高效的范围查询，也能进行高效单点查询。跳表通过构建多层级链表，每层跨度不同，提升查询效率，达到O(logn)。

**跳表查询：**从最顶层开始，值大于当前值则在该层向后查询，如果后续为null，则向下一层查询。如果小于，则向前查找。

**跳表新建节点：**找到位置，插入

**如何确定层数：**跳表的相邻两层的节点数量最理想的比例是 2:1，查找复杂度可以降低到 O(logN)。在redis中，跳表在创建节点时候，会生成范围为[0-1]的一个随机数，如果这个随机数小于 0.25（相当于概率 25%），那么层数就增加 1 层，然后继续生成下一个随机数，直到随机数的结果大于 0.25 结束，最终确定该节点的层数。层高最大限制为64。

**为什么用跳表不用平衡树？**

+ <font style="color:#DF2A3F;">从内存占用上来比较，跳表比平衡树更灵活一些。</font>平衡树每个节点包含 2 个指针，而跳表每个节点包含的指针数目平均为 1/(1-p)，具体取决于参数 p 的大小。如果像 Redis里的实现一样，取 p=1/4，那么平均每个节点包含 1.33 个指针，比平衡树更有优势。
+ <font style="color:#DF2A3F;">在做范围查找的时候，跳表比平衡树操作要简单。</font>在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。如果不对平衡树进行一定的改造，这里的中序遍历并不容易实现。而在跳表上进行范围查找就非常简单，只需要在找到小值之后，对第 1 层链表进行若干步的遍历就可以实现。
+ <font style="color:#DF2A3F;">从算法实现难度上来比较，跳表比平衡树要简单得多。</font>平衡树的插入和删除操作可能引发子树的调整，逻辑复杂，而跳表的插入和删除只需要修改相邻节点的指针，操作简单又快速。

### quicklist
redis3.0之前，list底层使用压缩列表或双向链表，而3.2提出了quicklist。quicklist其实就是压缩列表+双向链表，它是一个双向链表，每个节点内包含一个压缩列表。它的思想就是通过控制压缩列表的个数，来减少连锁更新带来的影响。

在向 quicklist 添加一个元素的时候，不会像普通的链表那样，直接新建一个链表节点。而是会检查插入位置的压缩列表是否能容纳该元素，如果能容纳就直接保存到 quicklistNode 结构里的压缩列表，如果不能容纳，才会新建一个新的 quicklistNode 结构。

quicklist 会控制 quicklistNode 结构里的压缩列表的大小或者元素个数，来规避潜在的连锁更新的风险，但是这<font style="color:#DF2A3F;">并没有完全解决连锁更新的问题</font>。

### listpack
由于quicklist仍然使用压缩列表，仍然具有连锁更新的风险（本质是每个节点记录了前驱的长度）。因此，redis5.0设计了listpack，目的是代替压缩列表。其最大特点就是不在记录前驱节点的长度

## 线程模型
### <font style="color:rgb(44, 62, 80);">Redis 是单线程吗？</font>
redis的单线程是指它接收客户端请求，解析请求，处理数据，并返回给客户端，这一系列操作是由一条主线程完成的，但其实他也有其他的后台线程来处理其他任务。比如关闭文件、AOF刷盘、释放内存，这些操作都有对应的任务队列和线程来进行操作。

### redis为什么要用单线程/为什么不用多线程？
1. 编程简单、易于维护
2. redis的性能瓶颈不在于CPU，也就是单线程和多线程性能差距不会太大，性能瓶颈在于内存和网络
3. 不会出现死锁、线程上下文切换等并发问题，甚至影响性能

### <font style="color:rgb(44, 62, 80);">Redis 单线程模式是怎样的？</font>
redis6.0之前的单线程模式，主要采用IO多路复用，包括连接事件、读事件、写事件

+ 连接事件用来接收连接请求，向epoll添加socket，注册读事件处理函数
+ 读事件包括调用read接收数据，然后解析执行命令，并且把数据添加到发送队列
+ 写事件则主要负责调用write函数将未发送的数据发送出去

还有一个发送函数，用来处理发送队列，当队列有任务的时候，就会调用write函数发送数据，如果没有发送完则会注册写事件。整个过程是一个循环执行的过程。

### <font style="color:rgb(44, 62, 80);">Redis 6.0 之后为什么引入了多线程？</font>
redis 6.0之后引入的多线程主要是针对于网络IO进行改进，主要的处理仍然是单线程的。它是添加了多个IO线程来处理发送请求的，只针对发送响应数据，不会以多线程的方式处理读请求

## 持久化
### <font style="color:rgb(44, 62, 80);">Redis 如何实现数据不丢失？</font>
redis有三种持久化方案：

1. RDB快照，将某一时刻的内存数据，写入日志当中
2. AOF，每执行一条操作命令，就以追加的方式添加到日志文件中
3. 混合模式

### <font style="color:rgb(44, 62, 80);">AOF 日志是如何实现的？</font>
当redis执行一条操作命令的时候，会先执行语句，写入内存，然后执行AOF操作，将命令持久化。然后当redis重启的时候，就可以根据aof日志文件记录的命令进行恢复。

redis采用先写后持久化的方式，主要有两个优势：

1. 不会阻塞主线程
2. 避免重复的检查开销，就可以不用在AOF的时候去检查语句的正确性

但是也会带来一定的缺陷：

1. 会阻塞其他线程
2. 会导致数据丢失，可能还没来得及执行AOF的时候，发生宕机，就会导致数据丢失

### AOF 写回策略有几种？
AOF一共有三种：

ALWAYS：每次执行玩操作，将AOF写入page cache，并直接持久化到磁盘

EVERYSEC：执行完操作，写入page cache，每隔一秒执行刷盘

NONE：写入page cache 由操作系统来决定什么时候刷盘

### AOF 日志过大，会触发什么机制？介绍一下
AOF日志文件过大会触发重写机制。重写机制就是，当文件过大的时候，主进程会创建一个bgrewriteaof子进程来执行重写操作，子进程会对日志文件进行压缩，具体而言，就是获得主进程的数据副本，并为每条记录生成一句语句，记录到日志文件中。从而实现压缩的效果。在这个过程当中，如果主进程进行数据修改的话，就会触发写时复制，从而保证数据安全。此外，为了避免主进程修改数据，而AOF日志中没有相应的修改，主进程会在每次执行命令的时候，分别写入aof重写缓冲区，aof缓冲区，以及内存数据，当aof子进程执行完毕之后，会给主进程发一个信号，主进程收到信号后，就会将aof重写缓冲区的内容追加到aof文件中，并且对现有文件进行覆盖，从而保证了数据的正确性

### 重写时，主进程为什么又要写到aof缓冲区，又要写到aof重写缓冲区
首先，所有的修改命令，都会被写入到aof缓冲区当中，在写到aof文件。而aof重写缓冲区存储的的是重写发生之后，新进来的修改命令。

写到重写缓冲区是为了保证重写后的文件含有重写过程中发生的修改。而写到aof缓冲区主要是为了保证原有的aof日志文件仍然在更新。假如说aof重写失败了，那么原有的aof日志文件仍然可用。

[https://redisbook.readthedocs.io/en/latest/internal/aof.html](https://redisbook.readthedocs.io/en/latest/internal/aof.html)

### 为什么要用子进程，不用子线程？
1. <font style="color:rgb(44, 62, 80);">子进程进行 AOF 重写期间，主进程可以继续处理命令请求，从而避免阻塞主进程；</font>
2. <font style="color:rgb(44, 62, 80);">子进程带有主进程的数据副本，这里使用子进程而不是线程，因为如果是使用线程，多线程之间会共享内存，那么在修改共享内存数据的时候，需要通过加锁来保证数据的安全，而这样就会降低性能。而使用子进程，创建子进程时，父子进程是共享内存数据的，不过这个共享的内存只能以只读的方式，而当父子进程任意一方修改了该共享内存，就会发生「写时复制」，于是父子进程就有了独立的数据副本，就不用加锁来保证数据安全。</font>

### 介绍一下RDB快照
RDB快照是redis的一种持久化方式，他主要采用快照的形式，就是记录当前的所有数据，写入日志文件。它主要有两种形式：save和bgsave

save命令执行rdb快照，是使用主线程来进行执行，可能会导致主线程阻塞

而bgsave命令是创建一个子进程来执行，因此不会造成主线程阻塞。此外，类似于AOF，bgsave也有写时复制，不过它的写时复制只保证了主进程能写，子进程记录的内容仍然是写之前的数据。并不会将新的修改进行记录，有可能会造成数据丢失。

### 介绍一下混合持久化方式
首先对于AOF而言，其优点就是丢失数据少，RDB的优点是恢复速度快，而混合持久化就是希望能够整合两者的优点。对于混合持久化方式来说，fork出的重写子进程会以RDB快照的形式，写入AOF文件，而主线程再执行更新操作的时候，会写入重写缓冲区，RDB写入之后，会将重写缓冲区的内容以AOF的形式写入AOF文件，然后再通知主线程将AOF文件替换旧的文件。因此，新AOF文件的前半部分是RDB全量数据，后半部分是追加的AOF增量数据。

这样做的好处就是重启恢复的时候，前半部分是RDB快照，恢复的很快，后面才会用AOF的方式进行增量数据的恢复。同时AOF增量方式也保证了数据不会丢失。

### 大key对持久化有什么影响？
大key可能再一些复制、写入操作上会比较耗时，导致线程的阻塞。

例如我们使用Always的写回策略，每次都会调用fsync进行写回，如果key很大的话耗时久，就会导致主线程阻塞。

或者当fork一个子进程，需要拷贝父进程的页表，此时如果key大的话也会耗时，导致阻塞。

或者创建完子进程后，如果发生写时复制，那么复制物理内存，也会导致阻塞。

## 集群
### 介绍一下Redis集群方式？
主从复制、哨兵模式、切片集群

### 介绍一下主从复制
主从复制是一种redis 的集群化部署模式，它包括一台主服务器和多台从服务器。主服务器主要用来执行读写操作，而从服务器主要用来执行读操作。当客户端对主服务器执行写操作的时候，主服务器会调用异步方法，将数据同步到从服务器当中，来实现主从一致。但由于是异步方法，所以可能造成数据的不一致。

### 讲一下主从复制的具体过程
首先从服务器执行replicaof命令，然后向主服务器发送一个psync请求，代表想要进行数据同步。

主服务器收到后，会返回一个fullsync响应，并且带上主服务器的runid，还有复制进度。

从服务器收到之后就会记录这些信息。

然后主服务器会用bgsave命令，来生成RDB文件，并发送给从服务器，从服务器收到后会先清空当前数据，然后载入RDB文件。

载入完成后，发送一个消息给主服务器，主服务器就会将此时记录再replication buffer里的增量记录发送给从服务器，从服务器执行这些命令，完成第一次复制。

在这之后，主从服务器之间会维护一个TCP连接，主服务器会将写操作通过该连接发送给从服务器来执行。

<!-- 这是一张图片，ocr 内容为： -->
![](https://cdn.nlark.com/yuque/0/2023/png/34998771/1690027336134-cb4e6255-d8c6-4e85-913a-097d80509bcf.png)

### 如何能够分摊主服务器的压力？
我们可以设置一些从服务器，让他们底下再接上一些从服务器，这样的话，就可以用这些从服务器来替主服务器执行bgsave、发送rdb文件这些操作，主服务器只需要第一次连上这些从服务器之后，每次传输操作命令给他们就可以。减轻了主服务器的压力

### 介绍一下增量复制？如果主从的TCP连接断开了会怎么样？
假如主从之间的TCP连接断开了，

当连接恢复时 ，从服务器会发送一个psync请求给主服务器，带上offset，主

服务器再断开连接之后，会将写操作记录在一个环形缓冲区当中，然后根据从服务器发过来的offset，判断从服务器要读取的数据是否还在缓冲区当中，

如果在的话，就会采用增量同步的方式，将repl backlog buffer里面的操作写到replication buffer中，发送给从服务器来执行。

如果不在的话，就会执行全量复制的方式，让从服务器再复制一次。

<!-- 这是一张图片，ocr 内容为： -->
![](https://cdn.nlark.com/yuque/0/2023/png/34998771/1690027362368-a505f749-ade1-432b-8d92-9012b95348da.png)

### <font style="color:rgb(44, 62, 80);">怎么判断 Redis 某个节点是否正常工作？</font>
心跳检测机制，主服务器每隔十秒向从服务器发送心跳包，判断节点的活性和连接情况，从节点每个一秒向服务器发送心跳包，上报自己的复制偏移量，检测网络状态，也判断自己是否有数据丢失。

### <font style="color:rgb(44, 62, 80);">主从复制架构中，过期key如何处理</font>
如果key过期了，主服务器会模拟一个del语句，发送给从服务器执行。

### <font style="color:rgb(44, 62, 80);">主从复制中两个 Buffer(replication buffer 、repl backlog buffer)有什么区别？</font>
repl backlog buffer主要是用于增量阶段，主服务器只会有一个这个buffer，而replication buffer存在于增量复制和全量复制阶段，主服务器会为每个新连接的从服务器分配一个replication buffer。

当repl backlog buffer满了之后，由于它是环形缓冲区，就会重头开始写

而当replication buffer 满了之后，会断开连接，清除缓存，让从服务器重新连接，重新进行全量复制

### <font style="color:rgb(44, 62, 80);">如何应对主从数据不一致？</font>
主从不一致主要是网络原因，因此我们可以尽量让主服务器和从服务器在一个机房

此外，我们可以开发一个外部程序，来监听主服务器的接收写命令的进度和从服务器复制写命令的进度，然后如果主服务器的进度大于从服务器的进度，大于一定阈值的话，我们可以让客户端暂时不再使用当前从服务器。避免读出不一致的数据。

### <font style="color:rgb(44, 62, 80);">主从切换如何减少数据丢失？</font>
主从切换主要有两种情况会造成数据丢失：

1. 异步复制同步丢失：由于主->从是异步复制，如果主服务器写入后，还没发给从服务器就宕机，或者网络发生故障，就会导致数据丢失，针对这种情况，可以设置最大延迟，如果从节点数据复制和同步的延迟都超过了这个最大值，主服务器就会拒收写请求，客户端可以采用降级措施，先将请求进行缓存，等主节点恢复正常了再执行。
2. 集群产生脑裂丢失：当发生某些故障，导致主服务器无法向从服务器发送信息，但客户端仍可以写入主节点，此时，哨兵节点也发现主节点丢失，那么他就会重新选举一个主节点，当旧主节点恢复正常后，他会降级为从节点，向新主节点建立连接，并且申请同步数据，清除自己的数据，但是这个时候，就会清除客户端向他写入的数据，导致数据丢失。解决方法就是，可以设置当主节点发现从节点下线太多，或者网络延迟太大，就拒收客户端请求，直到恢复正常，或者重新选举主节点，这样客户端的数据就只会写入新主节点，不会导致丢失。

### <font style="color:rgb(44, 62, 80);">主从如何做到故障自动切换？</font>
哨兵模式

### 什么是哨兵机制？
哨兵模式主要的作用就是进行主从节点故障转移，当我们的主节点挂掉之后，客户端无法进行写操作，此时就需要有一种机制来为我们选出一个新的主节点，这就是哨兵机制干的事。哨兵机制主要做三件事：监控、选主、通知。

### 如何判断一个主节点已经下线？
在redis中，通常由哨兵集群来判断一个节点是否下线。哨兵节点会向各个节点发送心跳包，如果在规定时间内没有收到响应，则会判断该节点主观下线。随后，该哨兵会向其他哨兵发起命令，一起判断这个节点是否下线，来避免误判。收到命令的哨兵节点会根据自己和主节点的网络状况判断，投出赞成票，如果赞成票达到一定阈值（quorum），则判断该主节点客观下线，就可以执行选主操作。

### <font style="color:rgb(44, 62, 80);">由哪个哨兵进行主从故障转移？</font>
首先，哪个哨兵节点判断主节点为主观下线，那么它就成为候选者。候选者会向其他哨兵节点发送请求，表明自己想成为leader，每个节点有一次投票机会，当候选者的同意票超过一半且大于等于设置好的阈值之后，就可以成为leader来执行主从切换。

quorum建议取值：哨兵二分之一+1

### 那如何进行故障转移呢？
在确定完执行故障转移的哨兵节点后，该节点首先在从节点中挑选出新主节点，主要从三个维度：优先级、复制进度、ID号。三个维度依次递进。

根据挑选出来的节点，leader节点会向他发送消息，告诉他升级为主节点，当它升级成功后，leader就会向旧主节点下的所有从节点发送slaveof命令，让他们称为新主节点的从节点。

完成了主从切换之后，哨兵节点会利用发布订阅机制，向客户端发送新主节点的ip和端口号，客户端就可以切换和新主节点进行通信。

最后，哨兵节点会继续监视旧主节点，当他重新上线后，给他发送slaveof命令，成为新主节点的从节点。

### <font style="color:rgb(44, 62, 80);">哨兵集群是如何组成的？</font>
哨兵节点是通过发布订阅机制来互相感知的，在主节点上有一个sentinel_:hello频道，哨兵会订阅这个频道，并且向他推送自己的ip和端口，其他节点收到推送，就可以和这个哨兵建立连接。

### 哨兵集群如何知道「从节点」的信息？
哨兵节点会以十秒一次的频率向主节点发送info，主节点收到后会将从节点列表返回给哨兵，哨兵就可以和各个从节点建立连接，并实施监控。

## 缓存
### <font style="color:rgb(44, 62, 80);">什么是缓存雪崩，怎么解决？</font>
缓存雪崩就是当一个时刻有大量的key同时过期，此时就可能导致大量的访问直接跳过redis访问到数据库，导致数据库的压力骤增，甚至宕机，进而可能导致整个系统的崩溃。导致缓存雪崩主要有两个原因：大量key同时过期或者redis宕机。

针对大量key过期，我们可以有几种解决方法：

1. 对每个key设置随机过期时间，让他们不会在同一时刻集体过期
2. 设置双key，当主key过期后，还有备用key可以访问
3. 设置互斥锁，当key过期时，在访问数据库，构建缓存操作上加锁，保证同一时间只有一个请求来构建缓存
4. 后台线程更新缓存，可以设置key永不过期，将更新缓存的操作交由后台执行。如果key由于内存紧张被淘汰了，那么可以在业务访问的时候通过消息队列通知后台线程更新缓存。

针对redis宕机，可以这样解决：

1. 集群部署
2. 服务熔断或限流，当redis宕机后，可以执行服务熔断，暂停客户端对redis的访问，直接向客户端返回错误，从而降低数据库压力。或者通过限流，只允许少部分请求访问数据库，避免数据库宕机。

### <font style="color:rgb(44, 62, 80);">什么是缓存击穿，怎么解决？</font>
缓存击穿就是针对于redis中的热点数据，如果热点数据过期了，可能在这一时刻会有大量的访问，打到数据库上面，这就可能导致数据库宕机。主要有两种解决方案：

1. 加互斥锁，保证每次只有一个请求能更新缓存，未获取锁的请求需要等锁释放后才能访问缓存或者返回空值
2. 不给热点数据设置过期时间，有后台线程更新缓存，或者在热点数据即将过期的时候，通知后台线程更新缓存

### 热点key问题如何解决？
热点key产生的问题：

+ 请求过多，缓存分片服务被打垮
+ 集群架构下，产生访问倾斜
+ DB 击穿，引起业务雪崩

解决：

1. **<font style="color:rgb(77, 77, 77);">使用二级缓存</font>**

使用本地缓存，如利用ehcache、GuavaCache等，甚至是一个HashMap都可以；在发现热key以后，把热key加载到系统的JVM中，针对这种热key请求，会直接从本地缓存中取，而不会直接请求redis；

本地缓存天然的将同一个key的大量请求，根据网络层的负载均衡，均匀分散到了不同的机器节点上，避免了对于固定key全部打到单个redis节点的情况，并且减少了1次网络交互；

2. **<font style="color:rgb(77, 77, 77);">将热key分散到不同的服务器中</font>**

<font style="color:rgb(77, 77, 77);">不要让固定key老是走到同一台redis节点上；我们把这个key，在多个redis节点上都备份一份即可，在有热key请求进来的时候，我们就在有备份的redis上随机选取一台，进行访问取值，返回数据，就能缓解redis单点热key的查询压力；</font>

3. **<font style="color:rgb(77, 77, 77);">热key拆分</font>**

热key问题的关键之一就是请求太多了，多的原因是热key存放的热点信息，对于每个用户请求过来时都需要查询，如零点秒杀活动信息，而单位时间的用户请求量是巨大的，从而对热key的查询请求量是巨大的；——因此解决热key的思路之一就是能否想办法把这个key给细化拆分，让不同用户请求的key是不一样的；

4. **<font style="color:rgb(77, 77, 77);">将核心/非核心业务做Redis的隔离</font>**

Redis单点查询性能有限，当热点key的查询超过Redis节点的性能阈值时，会导致缓存分片服务被打垮现象的产生，此时当前节点上的所有业务的redis的读写都是不可用的；为了防止热点key引发问题时，核心业务不受影响，应当提前做好核心/非核心业务的Redis的隔离，至少热点key存在的redis集群应当与核心业务隔离开来；

### 使用二级缓存怎么保证数据一致性？
<font style="color:rgb(85, 86, 102);">方案一：</font>

<font style="color:rgb(85, 86, 102);">获取缓存的节点从Redis中获取缓存数据和剩余过期时间，然后往本地cache中添加数据，并设置本地cache的过期时间=redis中缓存的剩余过期时间。</font>

<font style="color:rgb(85, 86, 102);">方案二：</font>

<font style="color:rgb(85, 86, 102);">通过消息队列（kafka/rocketmq）通知其他节点更新缓存。</font>

<font style="color:rgb(85, 86, 102);">方案三：</font>

<font style="color:rgb(85, 86, 102);">先更新数据库，再删redis，再删本地缓存</font>

### <font style="color:rgb(44, 62, 80);">什么是缓存穿透，怎么解决？</font>
缓存穿透就是，当一个请求查询的数据reids中不存在，数据库中不存在时，也就无法构建缓存，如果有大量这样的请求，就会导致数据库压力骤增。解决缓存穿透有几个方法：

1. 非法请求限制，我们可以在api入口处判断访问的参数是否合理，防止恶意请求造成缓存穿透
2. 设置空值或默认值，当一个请求查询数据库，没有找到时，我们可以给这个数据设置一个空值缓存，来服务后面的请求
3. 使用布隆过滤器，在写入数据库的时候，用布隆过滤器做个标记，这样请求来的时候就可以先用布隆过滤器判断数据是否存在，如果不存在，就不用访问数据库。

### 知道布隆过滤器怎么工作的吗？
布隆过滤器由初始值为0的位图数组和N个哈希函数组成，当我们在数据库写入数据的时候，可以用布隆过滤器对这个数据进行标记，首先对这个数据进行N个哈希计算，然后把每次结果对位图数组的长度取模，得到一个下标，将该位置的值置为1。然后当访问数据的时候，就可以判断该数据的N个哈希对应位置是否全为1，全为1则存在，否则不存在。但是由于哈希冲突的存在，布隆过滤器判断存在的数据，不一定真实存在。但是如果查询不到，那就是一定不存在。

### 布隆过滤器的优缺点
<!-- 这是一张图片，ocr 内容为： -->
![](https://cdn.nlark.com/yuque/0/2023/png/34998771/1695397312472-344e3f18-0bbf-48c7-9455-992e2571a858.png)

相比于缓存空值方法，主要有以下几个优点：

1. 占用小，如果空值过多的情况下布隆过滤去具有很大的空间优势
2. 运算快，开销小

缺点：

1. <font style="color:rgb(18, 18, 18);">存在误判的情况。</font>
2. <font style="color:rgb(18, 18, 18);">存在数据更新问题。增加复杂性，如果更新失败可能导致数据不一致</font>

### redis常见缓存更新策略？
redis常见的缓存更新策略包括：

1. 旁路缓存策略：应用程序负责和数据库、缓存交互，并且负责缓存的维护。读的时候如果缓存命中直接返回，如果没命中则去数据库中读，并写回缓存。写的时候则先更新数据库，再删除缓存。（若先删缓存有可能导致缓存数据不一致，即先删，读来了未命中，读取数据并写回缓存，而第一个改再改数据库，造成不一致）。适合读多写少的场景，因为对于写多的场景，缓存频繁的被删除，会影响缓存命中率。
2. 读穿/写穿策略：应用程序只负责和缓存交互，由缓存去和数据库交互。读的流程和旁路类似，写的时候先写缓存，再写数据库。但它要求缓存需要具备和数据库交互的能力，在开发当中常用的redis、memcached都不具备。

<!-- 这是一张图片，ocr 内容为：请求 读请求 写请求 请求类型? 缓存是否 缓存是否 命中? 命中? 是 读缓存 写缓存 是 数据库加载 数据到缓存 写数据库 返回数据 结束 -->
![](https://cdn.nlark.com/yuque/0/2023/png/34998771/1680530999702-83d7b189-53ea-4988-bce5-0f6656c33539.png)

3. 写回策略：更新数据时，只更新缓存，并且将其设置为脏数据，并立即返回，而不会更新数据库，通过批量异步的方式对数据库进行更新。适合写多的场景，但是不能保证数据强一致性，且有数据丢失的风险。

### 数据库和缓存如何保证一致性？
不论是先更新数据库还是先更新缓存，都有可能导致数据不一致问题，因此可以采取删除缓存的策略。对于缓存来说，如果先删除缓存，再更新数据库，仍然可能导致数据不一致，因此，使用先更新数据库，再删除缓存的方式能较好的解决这个问题。同时，我们可以加入重试机制保证缓存删除成功，将操作加入消息队列，如果删除失败，可以从消息队列中获取数据，再次删除，删除成功则将该消息删除。或者使用canal订阅mysql的binlog再操作缓存。

## 过期策略
### <font style="color:rgb(44, 62, 80);">如何判定 key 已过期了？</font>
当我们对一个key设置了过期时间，redis会将该key和时间缓存在一个过期字典中，当再次访问该key的时候，就  会查询字典中是否存在，不存在则正常读取，存在则比较其过期时间，看是否过期。

### <font style="color:rgb(44, 62, 80);">过期删除策略有哪些？</font>
定时删除、惰性删除、定期删除

+ 定时删除：在设置key的过期时间时，同时设置一个定时时间，当时间到达时，有事件处理器执行删除操作。其优点就是能够保证过期key尽快的被删除，缺点就是当key较多时，会占用CPU，对CPU不友好
+ 惰性删除：就是在你访问key，检查key是否失效的时候，失效再执行删除策略，优点就是对CPU较友好，缺点是会导致一部分过期key占用内存
+ 定期删除：redis每隔一段时间，随机选择一些key，并对他们进行过期删除。其优点就是能够控制过期删除的时长和频率，一定程度上减小CPU占用和内存占用，而缺点就是它是一个比较中庸的解决方案，且时长和频率不好设置，如果频率过高，就和定时删除一样，会占用CPU，而如果执行的少，又和惰性删除一样。

而redis采用的是惰性删除+定期删除的模式。

### 介绍一下redis的过期删除策略
redis采用的是惰性删除+定期删除的模式。对于定期删除，redis每隔十秒从数据库中抽出20个key，进行过期删除，如果过期key超过四分之一，则继续执行定期删除。

### 什么是内存淘汰？有哪些内存淘汰策略？
内存淘汰就是当redis的使用内存超过了最大内存时，就需要执行内存淘汰策略来淘汰一些符合条件的key。

redis当中的内存淘汰策略，你可以针对设置了过期时间的key范围，或者全部范围

例如，使用LRU算法，淘汰设置了过期时间的key中最久未使用的，或者用LFU算法淘汰最少使用次数的，或者淘汰更早过期的key

### Redis如何实现LRU算法？
传统的LRU算法采用链表结构，将使用的元素移动到表头，保证表尾是最久未使用元素。而这样做的缺点就是：

1. 使用链表结构，需要额外的存储空间
2. 每次都要移动元素，如果大量访问，会很耗费时间

因此，redis采用在数据中额外添加一个最后访问时间的字段，然后采取随机采用的方式，随机抽取一些值，加淘汰里面最久未访问的元素。LRU的问题：缓存污染

### Redis如何实现LFU算法？
redis同样在数据中添加了一个字段，该字段高16位记录访问时间，低8位存储logc。当对象被访问时，会先根据此次访问和上次访问的时间差，对logc进行衰减，然后再按一定概率增加logc，这样做其实是基于访问频率来进行淘汰的。

## 实战
### <font style="color:rgb(44, 62, 80);">Redis 如何实现延迟队列？</font>
zset

### Redis的大key如何删除？
1. 分批次删除，使用相应命令扫描大key，在使用命令分批次删除
2. 异步删除：使用unlink命令，这个命令会将key 放入一个子线程当中执行删除，不会阻塞当前线程

### Redis如何实现分布式锁？
redis作为缓存，是面向多个客户端的，可以被多个客户端访问，相当于是一个共享资源，因此很适合用来保存分布式锁。redis实现分布式锁有两个关键步骤：加锁和解锁。基本的逻辑是在redis中保存一个数据，比如string类型的数据，作为锁，形如<lock, id>。抢锁时，使用setnx命令设置该数据，如果设置成功，说明抢锁成功，设置失败说明抢锁失败。

1. 加锁阶段

在加锁阶段，主要要做几件事：读取变量，检查变量值，修改变量值。为了避免并发问题，显然这几件事情都需要保证原子性。而SETNX命令就可以很好的解决这个问题，一条命令做完了这三件事。

然后更进一步的考虑，如果抢到锁的客户端宕机了，那么锁就无法释放，导致阻塞。所以，最好再加上一个过期时间来避免这个问题。此外，我们在释放锁时，必须保证释放的是自己加的锁，而不是别人加的锁，因此需要设置每个客户端对应的唯一id。（例如，当A抢到锁，运行很久，锁过期了，B抢到锁，还在运行，此时A跑完，过来把B的锁释放了，显然是有问题的）

```java
SET lock_key unique_value NX PX 10000
```

2. 解锁阶段

对于解锁阶段，主要做两件事：判断当前锁是否是自己占有的、如果是则删除锁。第一件事，通过加锁阶段设置唯一id已经得到保证，因此可以正确完成逻辑。现在的问题是，解锁阶段分为两个操作，具有并发问题。因此，我们可以通过lua脚本解决。

基于redis实现的优点：

性能高效、实现方便

缺点：

过期时间不好确定（可以用watchdog续约，<font style="color:rgb(44, 62, 80);">先给锁设置一个超时时间，然后启动一个守护线程，让守护线程在一段时间后，重新设置这个锁的超时时间。实现方式就是：写一个守护线程，然后去判断锁的情况，当锁快失效的时候，再次进行续约加锁，当主线程执行完成后，销毁续约锁即可，不过这种方式实现起来相对复杂</font>）、主从异步复制导致分布式锁不可靠（redlock）

### watch dog机制
由于锁的过期时间不好确定，所以可以使用看门狗机制来进行自动续约。看门狗机制会默认设置一个锁的过期时间为30s，然后每隔10s去检查一下客户端是否还拥有锁，如果拥有锁，那么就自动续期。这样就能够保证即使服务阻塞，也不会导致锁过期，使得另一个线程获得锁。

而看门狗作为运行在服务器上的一个后台定时任务线程，加入服务器宕机了，它自然也就死了，就不会进行续期，锁在经过30s后过期，保证其他线程正常访问。

# ES
### 基本概念
集群：即ES集群，有多个ES机器组成

节点：即一台ES机器

索引：对应MySQL中的数据库，是一个数据集合

文档：对应MySQL中的一行，不同的是索引中的每个document可以有不同的结构

分片：类似于分库

数据类型：String（text、keyword），数字类型，boolean，date，binary，range，nested...

### text和keyword的区别是什么？

候选题（152）

候选 1新建

MySQL基础架构有哪些组件？

置信度 0.97

题目答案

分类标签

处理方式目标题目 ID

填写已有 canonical 题目 ID。当前正式题库 ID 也使用 q_ 前缀，不是临时占位。

候选 2新建

MySQL支持哪些存储引擎？默认使用哪个？

置信度 0.98

分类: 数据库标签: 1

候选 3新建

MySQL存储引擎架构了解吗？

置信度 0.96

分类: 数据库标签: 2

候选 4新建

MyISAM和InnoDB有什么区别？

置信度 0.98

分类: 数据库标签: 1

候选 5新建

MyISAM和InnoDB的索引有什么区别？

置信度 0.95

分类: 数据库标签: 0

候选 6新建

事务的四大特性是什么？

置信度 0.98

分类: 分布式系统标签: 1

候选 7新建

并发事务会带来哪些问题？

置信度 0.98

分类: 数据库标签: 1

候选 8新建

不可重复读和幻读有什么区别？

置信度 0.92

分类: 未设置标签: 0

候选 9新建

SQL标准定义了哪些事务隔离级别？

置信度 0.98

分类: 数据库标签: 1

候选 10新建

MySQL的隔离级别是基于锁实现的吗？

置信度 0.96

分类: 数据库标签: 1

候选 11新建

并发事务的控制方式有哪些？

置信度 0.97

分类: 分布式系统标签: 1

候选 12新建

什么是查询缓存？

置信度 0.93

分类: 分布式系统标签: 1

候选 13新建

执行一条select语句期间发生了什么？

置信度 0.96

分类: 分布式系统标签: 2

候选 14新建

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

置信度 0.95

分类: 数据库标签: 1

候选 15新建

InnoDB的行格式有哪些？

置信度 0.94

分类: 未设置标签: 0

候选 16新建

COMPACT行格式长什么样？

置信度 0.93

分类: 未设置标签: 0

候选 17新建

为什么变长字段长度列表要逆序存放？

置信度 0.88

分类: 未设置标签: 0

候选 18新建

记录头信息有哪些内容？

置信度 0.93

分类: 未设置标签: 0

候选 19新建

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

置信度 0.84

分类: 数据库标签: 1

候选 20新建

行溢出后MySQL怎么处理？

置信度 0.94

分类: 数据库标签: 1

候选 21新建

MySQL的NULL值是怎么存放的？

置信度 0.92

分类: 数据库标签: 1

候选 22新建

数据页包含哪些部分？

置信度 0.94

分类: 未设置标签: 0

候选 23新建

什么是索引？有什么优缺点？

置信度 0.96

分类: 数据库标签: 0

候选 24新建

索引的分类有哪些？

置信度 0.96

分类: 数据库标签: 0

候选 25新建

Hash索引和B+树索引有什么区别？

置信度 0.95

分类: 数据库标签: 1

候选 26新建

什么是聚簇索引和非聚簇索引？

置信度 0.95

分类: 数据库标签: 0

候选 27新建

B树和B+树有什么区别？为什么选择B+树？

置信度 0.97

分类: 数据库标签: 1

候选 28新建

为什么不使用红黑树？为什么不使用跳表？

置信度 0.94

分类: 数据库标签: 1

候选 29新建

最左前缀匹配原则介绍一下

置信度 0.92

分类: 数据库标签: 0

候选 30新建

联合索引有长度限制吗？过长会有什么影响？

置信度 0.80

分类: 分布式系统标签: 1

候选 31新建

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

置信度 0.95

分类: 数据库标签: 0

候选 32新建

什么是覆盖索引？什么是索引下推？

置信度 0.95

分类: 数据库标签: 0

候选 33新建

有什么优化索引的方法？

置信度 0.96

分类: 数据库标签: 1

候选 34新建

常见扫描类型有哪些？

置信度 0.81

分类: 数据库标签: 0

候选 35新建

左模糊匹配一定会导致索引失效吗？

置信度 0.89

分类: 数据库标签: 1

候选 36新建

导致索引失效的情况有哪些？

置信度 0.97

分类: 数据库标签: 0

候选 37新建

varchar a = 1 和 int a = '1'的索引失效情况？

置信度 0.91

分类: 数据库标签: 0

候选 38新建

EXPLAIN关键字有哪些字段？

置信度 0.90

分类: 数据库标签: 0

候选 39新建

MySQL中四种隔离级别分别是怎么实现的？

置信度 0.95

分类: 数据库标签: 1

候选 40新建

有几种开启事务的方式？

置信度 0.93

分类: 数据库标签: 1

候选 41新建

什么是read view？如何工作的？

置信度 0.93

分类: 分布式系统标签: 0

候选 42新建

InnoDB中如何解决幻读？

置信度 0.96

分类: 数据库标签: 0

候选 43新建

快照读和当前读的区别？

置信度 0.93

分类: 数据库标签: 0

候选 44新建

可重复读完全解决了幻读吗？

置信度 0.84

分类: 数据库标签: 0

候选 45新建

全局锁有什么用？

置信度 0.91

分类: 分布式系统标签: 1

候选 46新建

表级锁有哪些？

置信度 0.96

分类: Java 并发标签: 0

候选 47新建

轻量级锁会有什么问题？

置信度 0.85

分类: 数据库标签: 1

候选 48新建

行级锁有哪些？

置信度 0.97

分类: Java 并发标签: 0

候选 49新建

MySQL是如何加行级锁的？

置信度 0.90

分类: 数据库标签: 1

候选 50新建

删除操作会加什么锁？

置信度 0.86

分类: 数据库标签: 0

候选 51新建

插入时会加什么锁？

置信度 0.90

分类: Java 并发标签: 1

候选 52新建

update没加索引会导致什么结果？

置信度 0.93

分类: 数据库标签: 1

候选 53新建

MySQL记录锁+间隙锁可以防止删除操作导致的幻读吗？

置信度 0.92

分类: 数据库标签: 1

候选 54新建

MySQL怎么会产生死锁？如何避免？

置信度 0.95

分类: 数据库标签: 1

候选 55新建

MySQL中的乐观锁和悲观锁是什么？

置信度 0.78

分类: 数据库标签: 1

候选 56新建

MySQL中有哪几种日志？

置信度 0.98

分类: 数据库标签: 1

候选 57新建

为什么需要redo log？

置信度 0.96

分类: 数据库标签: 1

候选 58新建

修改undo页需要写入redo log吗？两者有什么区别？

置信度 0.93

分类: 数据库标签: 0

候选 59新建

redo log要写磁盘，数据页也要写磁盘，为什么还需要redo log？

置信度 0.96

分类: 未设置标签: 0

候选 60新建

产生的redo log是直接写入磁盘的吗？

置信度 0.95

分类: 分布式系统标签: 0

候选 61新建

redo log什么时候刷盘？

置信度 0.95

分类: 数据库标签: 1

候选 62新建

innodb_flush_log_at_trx_commit参数控制的是什么？

置信度 0.93

分类: 分布式系统标签: 0

候选 63新建

redo log文件写满了怎么办？

置信度 0.93

分类: 未设置标签: 0

候选 64新建

binlog是什么？和redo log有什么区别？

置信度 0.97

分类: 数据库标签: 1

候选 65新建

如果误删整个数据库，能用redo log恢复吗？

置信度 0.95

分类: 数据库标签: 1

候选 66新建

主从复制是怎么实现的？

置信度 0.95

分类: 数据库标签: 1

候选 67新建

从库是不是越多越好？

置信度 0.94

分类: 未设置标签: 1

候选 68新建

MySQL主从复制还有哪些模型？

置信度 0.95

分类: 分布式系统标签: 1

候选 69新建

binlog什么时候刷盘？

置信度 0.95

分类: 数据库标签: 1

候选 70新建

一条update语句的执行过程是什么？

置信度 0.96

分类: 数据库标签: 0

候选 71新建

为什么要两阶段提交？

置信度 0.95

分类: 分布式系统标签: 1

候选 72新建

MySQL 两阶段提交为什么要设计成 prepare 阶段的 redo log 加完整 binlog，重启后提交事务？

置信度 0.94

分类: 分布式系统标签: 2

候选 73新建

MySQL 两阶段提交有什么问题？

置信度 0.97

分类: 分布式系统标签: 1

候选 74新建

什么是组提交，如何解决 IO 次数多的问题？

置信度 0.95

分类: 数据库标签: 0

候选 75新建

什么是 Buffer Pool？有什么用？

置信度 0.96

分类: 分布式系统标签: 1

候选 76新建

Buffer Pool 缓存什么？

置信度 0.94

分类: 分布式系统标签: 0

候选 77新建

介绍一下 Buffer Pool

置信度 0.96

分类: 分布式系统标签: 2

候选 78新建

介绍一下 LRU 链表，有什么好处？

置信度 0.93

分类: 分布式系统标签: 0

候选 79新建

什么是预读失效？

置信度 0.95

分类: 未设置标签: 0

候选 80新建

什么是 Buffer Pool 污染？

置信度 0.95

分类: 分布式系统标签: 0

候选 81新建

脏页什么时候会被刷入磁盘？

置信度 0.94

分类: 数据库标签: 1

候选 82新建

慢查询怎么解决？

置信度 0.95

分类: 数据库标签: 1

候选 83新建

limit 调优怎么做？

置信度 0.93

分类: 数据库标签: 0

候选 84新建

介绍一下 Redis

置信度 0.96

分类: 分布式系统标签: 3

候选 85新建

Redis 为什么这么快？

置信度 0.95

分类: 分布式系统标签: 2

候选 86新建

分布式缓存常见的技术选型方案有哪些？

置信度 0.68

分类: 分布式系统标签: 1

候选 87新建

Redis 和 Memcached 有什么区别？

置信度 0.95

分类: 分布式系统标签: 1

候选 88新建

为什么用 Redis 作为 MySQL 的缓存？

置信度 0.95

分类: 分布式系统标签: 2

候选 89新建

Redis 支持事务吗？

置信度 0.93

分类: 分布式系统标签: 1

候选 90新建

Redis 数据类型以及使用场景分别是什么？

置信度 0.97

分类: 分布式系统标签: 2

候选 91新建

String 的内部实现？

置信度 0.96

分类: 分布式系统标签: 1

候选 92新建

String 如何实现分布式锁？

置信度 0.94

分类: 分布式系统标签: 2

候选 93新建

List 如何实现消息队列？

置信度 0.94

分类: 未设置标签: 2

候选 94新建

Hash 如何实现购物车？

置信度 0.91

分类: 未设置标签: 1

候选 95新建

String 还是 Hash 存储对象数据更好？

置信度 0.93

分类: 未设置标签: 1

候选 96新建

Set 如何实现抽奖？

置信度 0.92

分类: 未设置标签: 1

候选 97新建

ZSet 如何实现排行榜？

置信度 0.93

分类: 未设置标签: 1

候选 98新建

如何实现签到统计？

置信度 0.93

分类: 未设置标签: 1

候选 99新建

如何实现连续 7 天签到用户统计？

置信度 0.92

分类: 未设置标签: 1

候选 100新建

Stream 实现的消息队列和 List 有什么区别？

置信度 0.95

分类: 未设置标签: 2

候选 101新建

Redis 基于 Stream 的消息队列与专业消息队列有哪些差距？

置信度 0.95

分类: 分布式系统标签: 2

候选 102新建

Redis 是单线程吗？

置信度 0.95

分类: 分布式系统标签: 2

候选 103新建

Redis 为什么要用单线程/为什么不用多线程？

置信度 0.94

分类: 分布式系统标签: 2

候选 104新建

Redis 单线程模式是怎样的？

置信度 0.95

分类: 分布式系统标签: 2

候选 105新建

Redis 6.0 之后为什么引入了多线程？

置信度 0.94

分类: 分布式系统标签: 2

候选 106新建

Redis 如何实现数据不丢失？

置信度 0.93

分类: 分布式系统标签: 1

候选 107新建

AOF 日志是如何实现的？

置信度 0.94

分类: 分布式系统标签: 2

候选 108新建

AOF 写回策略有几种？

置信度 0.94

分类: 未设置标签: 1

候选 109新建

AOF 日志过大，会触发什么机制？介绍一下

置信度 0.95

分类: 分布式系统标签: 1

候选 110新建

重写时，主进程为什么又要写到 AOF 缓冲区，又要写到 AOF 重写缓冲区？

置信度 0.95

分类: 未设置标签: 1

候选 111新建

为什么要用子进程，不用子线程？

置信度 0.95

分类: Java 并发标签: 2

候选 112新建

介绍一下 RDB 快照

置信度 0.94

分类: 分布式系统标签: 2

候选 113新建

介绍一下混合持久化方式

置信度 0.95

分类: 未设置标签: 2

候选 114新建

大 key 对持久化有什么影响？

置信度 0.93

分类: 未设置标签: 2

候选 115新建

介绍一下 Redis 集群方式

置信度 0.90

分类: 分布式系统标签: 1

候选 116新建

介绍一下主从复制

置信度 0.95

分类: 分布式系统标签: 1

候选 117新建

讲一下主从复制的具体过程

置信度 0.95

分类: Java 并发标签: 2

候选 118新建

如何能够分摊主服务器的压力？

置信度 0.90

分类: 未设置标签: 1

候选 119新建

介绍一下增量复制？如果主从的 TCP 连接断开了会怎么样？

置信度 0.95

分类: 网络协议标签: 1

候选 120新建

怎么判断 Redis 某个节点是否正常工作？

置信度 0.91

分类: 分布式系统标签: 1

候选 121新建

主从复制架构中，过期 key 如何处理？

置信度 0.93

分类: 系统设计标签: 1

候选 122新建

主从复制中 replication buffer 和 repl backlog buffer 有什么区别？

置信度 0.96

分类: 分布式系统标签: 1

候选 123新建

如何应对主从数据不一致？

置信度 0.92

分类: 网络协议标签: 1

候选 124新建

主从切换如何减少数据丢失？

置信度 0.95

分类: 分布式系统标签: 1

候选 125新建

主从如何做到故障自动切换？

置信度 0.92

分类: 未设置标签: 1

候选 126新建

什么是哨兵机制？

置信度 0.95

分类: 未设置标签: 1

候选 127新建

如何判断一个主节点已经下线？

置信度 0.95

分类: 分布式系统标签: 1

候选 128新建

由哪个哨兵进行主从故障转移？

置信度 0.95

分类: 未设置标签: 1

候选 129新建

那如何进行故障转移呢？

置信度 0.95

分类: 未设置标签: 1

候选 130新建

哨兵集群是如何组成的？

置信度 0.93

分类: Java 并发标签: 2

候选 131新建

哨兵集群如何知道从节点的信息？

置信度 0.92

分类: 未设置标签: 1

候选 132新建

什么是缓存雪崩，怎么解决？

置信度 0.96

分类: 分布式系统标签: 3

候选 133新建

什么是缓存击穿，怎么解决？

置信度 0.95

分类: 分布式系统标签: 3

候选 134新建

热点 key 问题如何解决？

置信度 0.92

分类: 分布式系统标签: 1

候选 135新建

使用二级缓存怎么保证数据一致性？

置信度 0.95

分类: 分布式系统标签: 3

候选 136新建

什么是缓存穿透，怎么解决？

置信度 0.98

分类: 分布式系统标签: 1

候选 137新建

知道布隆过滤器怎么工作的吗？

置信度 0.97

分类: 未设置标签: 0

候选 138新建

布隆过滤器的优缺点？

置信度 0.95

分类: 未设置标签: 0

候选 139新建

Redis 常见缓存更新策略有哪些？

置信度 0.97

分类: 分布式系统标签: 1

候选 140新建

数据库和缓存如何保证一致性？

置信度 0.97

分类: 分布式系统标签: 3

候选 141新建

如何判定 key 已过期了？

置信度 0.93

分类: 分布式系统标签: 1

候选 142新建

过期删除策略有哪些？

置信度 0.98

分类: 分布式系统标签: 1

候选 143新建

介绍一下 Redis 的过期删除策略

置信度 0.90

分类: 分布式系统标签: 1

候选 144新建

什么是内存淘汰？有哪些内存淘汰策略？

置信度 0.90

分类: 分布式系统标签: 1

候选 145新建

Redis 如何实现 LRU 算法？

置信度 0.94

分类: 分布式系统标签: 1

候选 146新建

Redis 如何实现 LFU 算法？

置信度 0.92

分类: 分布式系统标签: 1

候选 147新建

Redis 如何实现延迟队列？

置信度 0.96

分类: 分布式系统标签: 1

候选 148新建

Redis 的大 key 如何删除？

置信度 0.95

分类: 分布式系统标签: 2

候选 149新建

Redis 如何实现分布式锁？

置信度 0.98

分类: 分布式系统标签: 2

候选 150新建

watch dog 机制是什么？

置信度 0.96

分类: 分布式系统标签: 3

候选 151新建

什么是热点 key，如何处理？

置信度 0.88

分类: 分布式系统标签: 1

候选 152新建

text 和 keyword 的区别是什么？

置信度 0.35

分类: 未设置标签: 0

导入预览

新建预览

MySQL基础架构有哪些组件？

分类: 分布式系统

标签: MySQL, 系统设计

答案预览

mysql主要包括连接器、查询缓存、分析器、优化器、执行器和插件式存储引擎

批量摘要

新建

152

合并

跳过

解析提示

Long source was parsed in 3 chunks because raw_text exceeded 24000 characters.
Chunk 1/3: 该来源是知识笔记而非真实面经，缺少公司、岗位、轮次等面试元数据。
Chunk 1/3: 这是长文档的第1段，仅能提取当前片段明确支持的内容。
Chunk 1/3: 部分答案包含口语化、可能随版本变化或表述不够严谨的内容，如查询缓存、索引长度限制、可重复读是否完全解决幻读等，已按原文保守提取。
Chunk 2/3: 来源为长文档分片第 2 段，仅提取本段可直接支持的题目与答案。
Chunk 2/3: 部分内容为知识点罗列或标题式笔记，问题表述做了轻度规范化。
Chunk 2/3: 个别表述可能存在原文笔误或不严谨之处，例如 bnlog/bnlog、page cahce、iner join、对 Redis 6.0 多线程读写范围的描述等，已尽量按原文保留，不额外扩展纠正。
Chunk 3/3: 该分块是长文末尾片段，只能提取当前分块明确支持的内容。
Chunk 3/3: 末尾出现“text和keyword的区别是什么？”标题，但当前分块未包含答案，无法归纳标准答案。
Chunk 3/3: 部分 Redis 细节表述可能来自个人笔记，未给出严格版本边界，例如定期删除的具体抽样参数。

这个任务已经确认过了，不会再次写入 canonical。

返回队列

创建时间: 2026/03/29 00:41

开始时间: 2026/03/29 00:41

完成时间: 2026/03/29 00:57