mysql篇

MySQL中的执行引擎

MySQL中的执行引擎

常用的存储引擎有以下：

Innodb引擎：Innodb引擎提供了对数据库ACID事务的支持。并且还提供了行级锁和外键的约束。它的设计的目标就是处理大数据容量的数据库系统。

MyIASM引擎(原本Mysql的默认引擎)：不提供事务的支持，也不支持行级锁和外键。

MEMORY引擎：所有的数据都在内存中，数据的处理速度快，但是安全性不高。

MyISAM与InnoDB区别

大多数时候我们使用的都是 InnoDB 存储引擎，在某些读密集的情况下，使用 MyISAM 也是合适的。不过，前提是你的项目不介意 MyISAM 不支持事务、崩溃恢复等缺点。

MyISAM：以读写插入为主的应用程序，比如博客系统、新闻门户网站。

Innodb：更新（删除）操作频率也高，或者要保证数据的完整性；并发量高，支持事务和外键。比如OA自动化办公系统。

MySQL中字段类型CHAR 和 VARCHAR 的区别？

数据库三大范式

• 第一范式： 属性不可再分

• 第二范式： 在一范式的基础上，消除了部份依赖，属性完全依赖于主键

• 第三范式： 在二范式的基础上，消除了传递依赖，属性不依赖于其它非主属性 属性直接依赖于主键
  

数据库中的事务是什么?事务的特性？

事务（ transaction） 是一组有序的数据库操作。如果组中的所有操作都成功， 则认为事务成功，提交事务。 如果一个操作失败， 则事务将回滚， 该事务所有操作的影响都将取消。（事务是逻辑上的一组操作，要么都执行，要么都不执行）

事务的特性：ACID

原子性（Atomicity） ： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；

一致性（Consistency）： 执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的；

隔离性（Isolation）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；

持久性（Durability）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

ACID靠什么来保证？

原子性：MySQL InnoDB 引擎使用 undo log(回滚日志) 来保证事务的原子性，记录了需要回滚的日志信息，事务回滚时撤销已经执行成功的sql

一致性：保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。

隔离性：MySQL InnoDB 引擎通过锁机制、MVCC 等手段来保证事务的隔离性（ 默认支持的隔离级别是 REPEATABLE-READ ）。

持久性：使用 redo log(重做日志) 保证事务的持久性，mysql修改数据的同时在内存和redo log记录这次操作，宕机的时候可以redo log恢复。redo log的刷盘会在系统空闲时进行。

mysql主从同步原理

MySQL的主从复制中主要有三个线程： master (binlog dump thread)，slave( I/O thread、SQL thread)， Master-条线程和Save中的两条线程。

主节点binlog：主从复制的基础是主库记录数据库的所有变更记录到binlog。 binlog是数据库服务器启动的那一刻起，保存所有修改数据库结构或内容的一个文件。

主节点 log dump线程，当 binlog有变动时， log dump线程读取其内容并发送给从节点。

从节点I/O线程接收 binlog内容，并将其写入到 relay log文件中。

从节点的SQL线程读取 relay log文件内容对数据更新进行重放，最终保证主从数据库的一致性

由于mysql默认的复制方式是异步的，主库把日志发送给从库后不关心从库是否已经处理，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念：

全同步复制：主库写入 binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响

半同步复制：和全同步不同的是，半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成

并发事务带来哪些问题?

脏读（Dirty read）：某个事务对数据进行修改时，另外一个事务读取了这个数据。因为这个数据是还没有提交的数据（可能会发生回滚），那么另外一个事务读到的这个数据是“脏数据”。

不可重复读（Unrepeatable read）：某个事务内多次读同一数据，数据不一致。可能在该事务多次读取数据期间，某一个事务修改了数据。（修改操作）

幻读（Phantom read）： 某个事务内多次读同一种数据，数据行数不一致。可能在该事务多次读取数据期间，某一个事务插入了数据，导致出现了本不该出现的数据。（插入删除操作）

丢失修改（Lost to modify）: 某个事务读取一个数据，并对数据进行修改，期间另外一个事务也访问了该数据，并对数据进行修改。导致第一个事务进行修改的的操作没有成功，因此称为丢失修改。 例如：事务 1 读取某表中的数据 A=20，事务 2 也读取 A=20，事务 1 修改 A=A-1，事务 2 也修改 A=A-1，最终结果 A=19，事务 1 的修改被丢失。

四种事务隔离级别

READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。

READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。

REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。

SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）。我们可以通过SELECT @@transaction_isolation;查看

什么是索引？索引的基本原理

索引是一种用于快速查询和检索数据的数据结构。常见的索引结构有: B 树， B+树和 Hash。

索引的作用就相当于目录的作用。其本身是一种特殊的文件，它们包含着对数据表里所有记录的引用指针。会占据一定的物理空间。

索引的优缺点：

• 优点 ：使用索引可以大大加快数据的检索速度（大大减少检索的数据量）

• 缺点 ：创建索引和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态的修改，会降低 SQL 执行效率。另外，索引需要使用物理文件存储，也会耗费一定空间。

索引的原理：把无序的数据变成有序的查询

• 把创建了索引的列的内容进行排序

• 对排序结果生成倒排表

• 在倒排表内容上拼上数据地址链

• 在查询的时候，先拿到倒排表的内容，再取出数据地址链，从而拿到具体数据

使用索引一定能提高查询性能吗?
大多数情况下，索引查询都是比全表扫描要快的。但是如果数据库的数据量不大，那么使用索引也不一定能够带来很大提升。

索引类型

• 普通索引(Index) ：用来快速查询数据，一张表允许创建多个普通索引，并允许数据重复和 NULL。

• 唯一索引(Unique Key) ：可以保证数据记录的唯一性，允许数据为 NULL，一张表允许创建多个唯一索引。 建立唯一索引的目的大部分时候都是为了该属性列的数据的唯一性，而不是为了查询效率。

• 主键索引(Primary Key)：数据表的主键列使用的就是主键索引。是一种特殊的唯一索引，一张数据表有只能有一个主键，并且主键不能为 null，不能重复。

• 前缀索引(Prefix) ：前缀索引只适用于字符串类型的数据。前缀索引是对文本的前几个字符创建索引，相比普通索引建立的数据更小， 因为只取前几个字符。（前缀的标识度高。比如密码就适合建立前缀索引，因为密码几乎各不相同）

• 全文索引(Full Text) ：全文索引主要是为了检索大文本数据中的关键字的信息，通过建立倒排索引，可以极大提升索引效率，解决判断字段是否包含问题，是目前搜索引擎使用的关键技术。

MySQL 如何为表字段添加索引？

添加 PRIMARY KEY（主键索引）
ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )

添加 UNIQUE(唯一索引)
ALTER TABLE `table_name` ADD UNIQUE ( `column` )

添加 INDEX(普通索引)
ALTER TABLE `table_name` ADD INDEX index_name ( `column` )

添加 FULLTEXT(全文索引)
ALTER TABLE `table_name` ADD FULLTEXT ( `column`)

添加多列索引
ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

select count(*)/count(distinct left(password,prefixLen));
通过从调整prefixLen的值（从1自增）查看不同前缀长度的一个平均匹配度，接近1时就可以了（表示一个密码的前prefixLen个字符几乎能确定唯一一条记录）

在 MySQL 的 InnoDB 的表中，当没有显示的指定表的主键时，InnoDB 会自动先检查表中是否有唯一索引的字段，如果有，则选择该字段为默认的主键，否则 InnoDB 将会自动创建一个 6Byte 的自增主键。

二级索引(辅助索引)：
二级索引又称为辅助索引，是因为二级索引的叶子节点存储的数据是主键。也就是说，通过二级索引，可以定位主键的位置。唯一索引，普通索引，前缀索引等索引属于二级索引。

二级索引属于非聚簇索引

聚集索引与非聚集索引

两者都是B+树的数据结构，依赖于有序的数据。

聚集索引：聚集索引即索引结构和数据一起存放，并按一定的顺序进行排序的索引，找到了索引进找到了数据。

主键索引属于聚集索引。

优点：

聚集索引的范围查询速度非常的快，因为整个 B+树本身就是一颗多叉平衡树，叶子节点也都是有序的，定位到索引的节点，就相当于定位到了数据。

缺点：

依赖于有序的数据 ：因为 B+树是多路平衡树，如果索引的数据不是有序的，那么就需要在插入时排序，如果数据是整型还好，否则类似于字符串或 UUID 这种又长又难比较的数据，插入或查找的速度肯定比较慢。

更新代价大 ： 如果对索引列的数据被修改时，那么对应的索引也将会被修改， 而且况聚集索引的叶子节点还存放着数据，修改代价肯定是较大的， 所以对于主键索引来说，主键一般都是不可被修改的。

非聚集索引：非聚集索引即索引结构和数据分开存放的索引。非聚集索引的叶子节点并不存放数据，存储的数据行地址，根据数据行地址再回表查数据。

优点：

更新代价比聚集索引要小 。非聚集索引的更新代价就没有聚集索引那么大了，非聚集索引的叶子节点是不存放数据的

缺点：

跟聚集索引一样，非聚集索引也依赖于有序的数据

可能会二次查询(回表) ：这应该是非聚集索引最大的缺点了。 当查到索引对应的指针或主键后，可能还需要根据指针或主键再到数据文件或表中查询。

MyISAM：采用非聚集索引， 索引文件的数据域存储指向数据文件的指针。辅索引与主索引基本一致， 但是辅索引不用保证唯一性。

InnoDB：主键索引采用聚集索引（ 索引的数据域存储数据文件本身）， 辅助索引的数据域存储主键的值； 因此从辅助索引查找数据， 需要先通过辅助索引找到主键值， 再访问辅助索引； 最好使用自增主键， 防止插入数据时， 为维持 B+树结构， 文件的大调整。

创建索引的一些原则

适合索引：频繁查询、范围查询、排序、连接的字段
不适合索引：基数较小、频繁更新、重复值多的、字段为NULL的字段

选择合适的字段创建索引：

被频繁查询的字段 ：我们创建索引的字段应该是查询操作非常频繁的字段。

被作为条件查询的字段 ：被作为 WHERE 条件查询的字段，应该被考虑建立索引。(避免在查询条件中对字段施加函数，这会造成无法命中索引)

频繁需要排序的字段 ：索引已经排序，这样查询可以利用索引的排序，加快排序查询时间。

被经常频繁用于连接的字段 ：经常用于连接的字段可能是一些外键列，对于外键列并不一定要建立外键，只是说该列涉及到表与表的关系。对于频繁被连接查询的字段，可以考虑建立索引，提高多表连接查询的效率。

一些建议：

对于中到大型表索引都是非常有效的，但是特大型表的话维护开销会很大，不适合建索引。

在使用 InnoDB 时使用与业务无关的自增主键作为主键，即使用逻辑主键，而不要使用业务主键。

删除长期未使用的索引，不用的索引的存在会造成不必要的性能损耗

在使用 limit offset 查询缓慢时，可以借助索引来提高性能

索引失效的原因可能是什么？

索引失效这个问题的前提应该是建立了索引，却没有使用到，或者没有完全使用到，下面列举了一些常见原因，面试中可能也会闻到。

原因一：复合索引没有遵守最左前缀原则，复合索引必须遵守最左前缀，也就是按照复合索引创建的顺序，左边的列必须按顺序出现。

原因二：在索引列上做了任何操作（计算、函数、类型转换）

原因三：出现范围条件，往后全部失效

原因四：没有充分利用覆盖索引

原因五：使用了不等于（!= 或者 <>） 作为条件

MySQL的最左前缀原则

最左前缀原则就是最左优先，在创建多列索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。 mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。

=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式。

前缀索引

因为可能我们索引的字段非常长，这既占内存空间，也不利于维护。所以我们就想，如果只把很长字段的前面的公共部分作为一个索引，就会产生超级加倍的效果。但是，我们需要注意，order by不支持前缀索引 。

流程是：

先计算完整列的选择性 :select count(distinct col_1)/count(1) from table_1

再计算不同前缀长度的选择性 :select count(distinct left(col_1,4))/count(1) from table_1

找到最优长度之后，创建前缀索引 :create index idx_front on table_1 (col_1(4))

MySQL锁的类型

按照锁的粒度把数据库锁分为行级锁、表级锁和页级锁

• 行级锁：行级锁是MySQL中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁和排他锁。
  特点：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

• 表级锁：表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。

  特点：开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。

• 页级锁：页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。
  特点：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

基于锁状态分类：共享锁、排它锁

• 共享锁( Share Lock) 又称读锁，简称S锁；当一个事务为数据加上读锁之后，其他事务只能对该数据加读锁，而不能对数据加写锁。直到所有的读锁释放之后其他事务才能对其进行加持写锁，共享锁的特性主要是为了支持并发的读取数据，读取数据的时候不支持修改，避免出现重复读的问题

• 排他锁( exclusive Lock) 又称写锁，简称X锁；当一个事务为数据加上写锁时，其他请求将不能再为数据加任何锁，直到该锁释放之后， 其他事务才能对数据进行加锁，排他锁的目的是在数据修改时候，不允许其他人同时修改，也不允许其他人读取，避免了出现脏数据和脏读的问题

锁的优化策略：
读写分离、分段加锁、减少锁持有的时间

Redis篇

redis为什么这么快

内存：redis的所有数据都在内存中，因此不需要访问磁盘，极大的降低了访问延迟；内存操作（读写）性能高，支持每秒百万级操作。

单线程：redis以单线程模式运行，避免了多线程上下文切换的开销问题和多线程竞争问题，提高了CPU利用效率。

高效的数据结构：redis利用了几个高效的底层数据结构来提高数据操作效率。

非阻塞I/O多路复用机制：Redis使用非阻塞I/O，这种机制使得redis可以处理多个连接而不阻塞其他操作，从而能快速处理请求，实现高并发和高吞吐量。

Redis优缺点

优点：高性能、高并发

1.高性能：redis将数据存储在内存中，因此读写速度非常快。

2.高并发：redis基于Reactor 模式开发的网络事件处理器（文件事件处理器）是单线程模式运行的，所有操作都是原子性的，天然就支持高并发。

3.数据结构丰富：redis支持各种抽象数据结构，如字符串，列表，映射，集合，排序集合，HyperLogLogs，位图，流和空间索引。

4.支持持久化：redis支持将数据持久化到磁盘，提供可靠的数据保证。

5.分布式支持：redis支持主从复制和哨兵机制，可以实现数据备份、读写分离和自动故障转移，提高系统的可用性和可靠性。

缺点（内存消耗、数据一致性问题、阻塞）：

1.内存消耗较大：由于redis将数据存储在内存中，因此对于大规模数据的存储需求，需要考虑服务器的内存容量和成本。

2.CPU操作瓶颈：单线程模型可以避免上下文切换，但是也无法利用现代多核处理器的性能，对于CPU密集型的操作或服务器存在CPU密集型服务时可能存在性能瓶颈（一般很少见，redis的瓶颈主要在内存和网络），这种情况下就不适合处理大量并发请求。

3.线程阻塞：当单线程执行的命令阻塞时（慢查询、大key操作、网络问题等），将严重影响redis的性能。

4.数据一致性：当redis作为缓存使用时，就一定存在缓存和数据库数据不一致的问题。此外redis的主从复制存在一定的延迟。

5.无法处理复杂查询：redis不支持复杂查询操作，对于需要进行复杂数据分析和统计的场景不太适用。

6.数据容量受限：由于redis将数据存储在内存中，所以数据的容量受到内存大小的限制，无法存储超过内存容量的数据。

redis如何实现持久化

为什么要持久化？redis是内存数据库，它的数据都存储在内存中，如果不把数据保存到磁盘里，那么服务器进程一旦退出，服务器的数据就丢失了。

通过两种方式：
1.RDB（Persistence DB）：RDB类似快照，它只能持久化某一时刻的服务器数据。RDB持久化后，文件将被保存至同文件夹下的dump.rdb文件中，且以压缩的二进制文件表示，服务器重启都会加载该文件以加载数据。

2.AOF（Append Only File）：AOF可以支持实时的数据持久化。AOF持久化功能通过保存redis服务器所执行的写命令来记录数据库状态，默认存储在appendonly.aof中，AOF文件中存储的都是redis相关命令。

RDB和AOF有什么区别？分别在什么场景下使用RDB和AOF？

RDB持久化与AOF持久化的区别：

1.实现原理：RDB是保存所有的键值对数据，而AOF则是保存服务器执行的写命令；

2.实现方式：RDB、AOF都可以实现手动和自动执行；

3.服务器执行：如果AOF功能处于打开状态，那么服务器总是会读取AOF的文件来恢复数据库状态，只有当AOF关闭时，才会读取RDB文件。

4.读取性能：AOF文件保存的是服务器写命令，容易形成很多不必要的冗余数据，读取文件时，服务器需要重写执行这些命令，速度较慢；RDB文件仅仅保存了数据库需要的所有状态，恢复较快；

5.写入性能：都是自动保存时，RDB需要额外的定时线程维护，且需要判断自动保存的条件，性能一般；而AOF支持服务器每次执行写命令都可以将缓存区的数据保存至AOF文件中，单次性能快。

6.安全性：AOF的更新频率更快，安全性更高，但是总体写入性能较差。

根据上述的区别，选择哪种方式主要取决于业务需求和数据安全性要求。

RDB持久化适用于以下场景：

• 数据备份：由于RDB文件是紧凑的二进制文件，适合数据备份。

• 主从复制：在Redis的主从复制场景中，主节点通常会将RDB文件发送给从节点，以便从节点能够快速加载数据并保持与主节点的同步。

• 对数据一致性要求不高：如果能接受在Redis崩溃时丢失最近一段时间的数据，那么RDB是一个不错的选择。因为RDB持久化只保证某个时间点的数据一致性，而无法保证数据的实时性。

AOF持久化适用于以下场景：

• 对数据实时性要求高 + 对数据安全性要求高：AOF持久化通过记录所有对数据库的写操作来保证数据的实时性。即使Redis崩溃，也可以通过执行AOF文件中的写操作来恢复大部分数据（取决于你的AOF文件写入配置）。

RDB，AOF都开启时，服务器是如何加载数据的，数据以谁为准？

由于AOF文件的更新频率更高更准确，如果RDB和AOF持久化同时处于打开状态，那么服务器将优先使用AOF文件来还原数据库状态，只有AOF关闭，才会通过RDB方式恢复服务器。

Redis什么情况下会出现阻塞，怎么解决?

1.慢查询：

由于redis是单线程的，大量的慢查询可能会阻塞服务器。当慢查询发生时，其他命令可能会因为命令执行排队机制而导致级联阻塞。

通过查询redis的慢查询日志slowlog get命令逐一进行监控和优化，确保系统的稳定性和性能。

slowlog-log-slower-than time：记录大于 time 的慢日志记录

slowlog-max-len：最大记录条数（先进先出的队列）

2.阻塞命令：

使用KEYS命令（大key问题）遍历大量键可能导致Redis阻塞。使用SCAN命令来遍历键；

手动执行RDB持久化命令：save，阻塞redis服务器进程，直到RDB文件创建完毕，在此期间，服务器不能处理任何命令。使用bgsave代替，bgsave将派生出子进程，由该进程创建RDB文件，服务器则不受其影响。

3.内存交换：
当内存空间不足时，操作系统可能会使用内存交换（swap）来释放内存，这会导致Redis性能下降甚至阻塞。为了避免这种情况，应该确保Redis服务器有足够的内存，并监控内存使用情况。

4.持久化阻塞：

当AOF持久化功能处于打开且AOF配置文件写入为appendfsync always时，Redis每次执行写命令都将缓冲区的内容写入AOF文件，此时主线程可能会因为持久化操作而阻塞（将数据写到磁盘的IO操作）。

解决这个问题的方法是控制Redis最大内存，使用高效支持fork操作的虚拟机，或者优化持久化策略。

5.网络问题：

网络闪断、Redis连接拒绝或连接溢出等网络问题也可能导致Redis阻塞。

解决方案是检查网络连接稳定性，调整Redis连接配置，以及优化网络带宽和延迟。

6.高并发写入：

在高并发写入的情况下，多个客户端同时请求写入操作可能导致阻塞。可以使用Redis的事务功能将多个写入操作打包成一个原子性的操作序列，以减少阻塞的可能性。

如何处理redis过期键？你知道哪些删除策略？

Redis服务器实际使用的是：惰性删除和定期删除两种策略来处理redis过期键。

1. 定时删除：在设置键的过期时间时，创建一个定时器timer，定时器时间到了就删除过期键。

优缺点：

• 对内存友好，一旦有过期键便会很快删除

• 对CPU压力最大，过期键过多时（或同一时刻大面积的键失效），会占用很大一部分的CPU时间在删除键上，致使服务器的响应时间增加、吞吐量下降。

2. 惰性删除：程序在取出键时，才对键进行过期检测，并选择是否删除。

优缺点：

• 对CPU压力最小，这种策略不会操作不访问的无关过期键

• 对内存压力大，当大量键过期时，如果不对键进行访问，那么所有过期键都不会被删除，造成内存垃圾堆积。

3. 定期删除：每隔一段时间执行一次删除过期键的操作，并通过限制删除操作执行的时长和频率来减小对CPU的影响。

优缺点：

• 有效减少了过期键带来的内存浪费

• 有效减少了删除操作对CPU时间的影响

• 但是很难控制和确定定期删除的执行时长和频率。执行时长过长或频率频繁就容易形成定时删除的弊端，反之则会形成惰性删除的弊端。

说说内存淘汰机制？有哪些策略？

当redis内存超过maxmemory的限制时，就会根据maxmemory-policy选择的内存淘汰机制（eviction policy）尝试删除键。

maxmemory-policy默认值为noeviction。策略内容如下：

noeviction：在达到内存限制并且客户端尝试执行可能导致使用更多内存的命令时返回错误（一般出现在写入命令时，但删除和一些其他操作时也有可能引发异常）。

allkeys-lru：尝试在键空间中先删除最近最少使用的（LRU）键

volatile-lru：在设置了过期时间的键空间中，尝试在键空间中删除最近最少使用（LRU）的键

allkeys-random：随机删除键

volatile-random：在设置了过期时间的键空间中随机删除键

volatile-ttl：在设置了过期时间的键空间中，尝试首先逐出具有较短生存时间（TTL）的密钥（即更早过期的键）

当redis中没有设置任何过期键或删除过期键仍没有多余内存时，volatile-lru、volatile-random以及volatile-ttl的行为跟noeviction相似。

遇到过redis缓存穿透问题吗？什么场景下产生的？如何解决的？

大规模key失效，导致大量请求打到数据库，使得数据库瞬间承受了远超常规水平的并发请求量，进而可能导致数据库响应变慢、服务不可用，最终对整个系统造成严重的性能瓶颈甚至崩溃。

可能产生的场景：

• 大量缓存同时过期：例如，若系统中的多个关键热数据的缓存设置了相同或相近的过期时间，一旦这些缓存同时过期，会导致大量请求直接打到数据库。

• 缓存实例故障：Redis服务器本身发生故障，如宕机或网络断开，导致整个缓存集群失去作用，所有请求无法命中缓存而转向数据库。

• 批量操作失误：由于运维或者其他原因，执行了错误的大规模删除缓存操作，使大量缓存数据瞬间失效。

解决方案：

• 分散过期时间：对不同缓存数据设置随机的过期时间，避免同一时间点大量缓存同时失效。

• 二级缓存策略：采用主从、分层或多级缓存架构，即使一级缓存失效，还有其他层次的缓存可以抵挡一部分冲击。

• 熔断机制：引入类似Hystrix这样的熔断器组件，当请求量超过数据库能承受的阈值时，立即停止服务调用，避免压垮数据库。

• 限流/降级：使用令牌桶或漏桶算法等实现流量控制，当请求过多时进行限流，优先确保核心服务的稳定。

• 后台更新缓存：在缓存失效时，不是立即从数据库加载数据并返回给客户端，而是异步地去更新缓存，减少数据库压力。

• 冗余设计：提升缓存集群的可用性和容错能力，即便部分节点失效，也能通过其他节点继续提供服务。

遇到过击穿问题吗？什么场景下产生的？如何解决的？

某个热点key失效，大并发集中对其进行请求，就会造成大量请求读缓存没读到数据，从而导致高并发访问数据库，引起数据库压力剧增，甚至可能导致数据库崩溃的情况。

可能产生的场景：

• 缓存过期：假设某个热点Key设置了固定的过期时间，当过期时间到达时，这个Key的缓存失效，而在接下来的一段时间内，有大量的并发请求恰好都访问到了这个失效的Key，所有的请求都会绕过缓存直接查询数据库。

• 缓存被大量并发删除或更新：如果因为某种原因（如误操作、代码bug等），导致大量并发请求删除或更新了同一个热点Key的缓存，也会造成短时间内数据库压力激增。

解决方案：

• 缓存续期（缓存永不过期）：对于热点Key，可以采取主动续期的方式，即在每次访问热点Key时都刷新其过期时间，使其始终保持有效状态，避免因过期导致的击穿问题。

• 互斥锁（Mutex Lock）：在访问热点Key时，先尝试加分布式锁，成功加锁后才去查询数据库并更新缓存，其他请求则等待解锁后再进行。这样可以确保同一时刻只有一个请求穿透到数据库。

• Cache Aside Pattern：采用缓存旁路模式，当缓存失效时，只让一个线程重建缓存，其他线程等待重建完成之后再从缓存中获取数据，避免所有线程都去查询数据库。

• 延时双删策略：在删除缓存的同时，设置一个短暂的延迟时间，在延迟期间再次删除缓存。这样可以尽量覆盖到缓存真正失效和新缓存重建完成之间的空窗期，减少数据库压力。