interview1-DB篇

需要项目经验可自行上Gitee寻找项目资源

 一、Redis篇

 

 1、缓存

缓存的要点可分为穿透、击穿、雪崩，双写一致、持久化，数据过期、淘汰策略。

（1）穿透、击穿、雪崩

1.缓存穿透

查询一个不存在的数据，mysql查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库。

• 解决方法一：缓存空数据，查询返回的数据为空，仍把这个空结果进行缓存。

优点：简单。 缺点：消耗内存，可能会发生不一致的问题

• 解决方案二：布隆过滤器。

布隆过滤器主要是用于检索一个元素是否在一个集合中。我们当时使用的是redisson实现的布隆过滤器。它的底层主要是先去初始化一个比较大数组，里面存放的二进制0或1。在一开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据的下标然后把数组中原来的0改为1，这样的话，三个数组的位置就能标明一个key的存在。查找的过程也是一样的。当然是有缺点的，布隆过滤器有可能会产生一定的误判，我们一般可以设置这个误判率，大概不会超过5%，其实这个误判是必然存在的，要不就得增加数组的长度，其实已经算是很划分了，5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库。

数组越小误判率就越大，数组越大误判率就越小，但是同时带来了更多的内存消耗。

2.缓存击穿

给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮

• 解决方法一：互斥锁

当缓存失效时，不立即去load db，先使用如 Redis 的setnx 去设置一个互斥锁，当操作成功返回时再进行 load db的操作并回设缓存，否则重试get缓存的方法

• 解决方法二：逻辑过期

①：在设置key的时候，设置一个过期时间字段一块存入缓存中，不给当前key设置过期时间

②：当查询的时候，从redis取出数据后判断时间是否过期

③：如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据不是最新

如果选择数据的强一致性，建议使用分布式锁的方案，性能上可能没那么高，锁需要等，也有可能产生死锁的问题

如果选择key的逻辑删除，则优先考虑的高可用性，性能比较高，但是数据同步这块做不到强一致。

3.雪崩问题

指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方案一般主要是可以将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

（2）双写一致、持久化

1.双写一致

记得要先介绍业务场景，数据是一致性要求高，还是允许延迟。  

也就是redis缓存和db写入数据同步的问题，当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致。

• 解决方法一：读写锁。

采用的是redisson实现的读写锁，在读的时候添加共享锁，可以保证读读不互斥，读写互斥。当我们更新数据的时候，添加排他锁，它是读写，读读都互斥，这样就能保证在写数据的同时是不会让其他线程读数据的，避免了脏数据。这里面需要注意的是读方法和写方法上需要使用同一把锁才行。

• 解决方法二：延迟双删。

如果是写操作，我们先把缓存中的数据删除，然后更新数据库，最后再延时删除缓存中的数据，其中这个延时多久不太好确定，在延时的过程中可能会出现脏数据，并不能保证强一致性，所以没有采用它。

• 解决方法三：使用canal。

2.持久化

在Redis中提供了两种数据持久化的方式：1、RDB 2、AOF

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

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。当redis实例宕机恢复数据的时候，会从这个文件中再次执行一遍命令来恢复数据。

   这两种方式，哪种恢复的比较快呢？

RDB因为是二进制文件，在保存的时候体积也是比较小的，它恢复的比较快，但是它有可能会丢数据，我们通常在项目中也会使用AOF来恢复数据，虽然AOF恢复的速度慢一些，但是它丢数据的风险要小很多，在AOF文件中可以设置刷盘策略，我们当时设置的就是每秒批量写入一次命令。

（3）数据过期、淘汰策略

1.数据过期

Redis对数据设置数据的有效时间，数据过期以后，就需要将数据从内存中删除掉。可以按照不同的规则进行删除，这种删除规则就被称之为数据的删除策略（数据过期策略）。

• 惰性删除：设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key

• 定期删除：每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的过期key)。

SLOW模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf 的 hz 选项来调整这个次数

FAST模式执行频率不固定，每次事件循环会尝试执行，但两次间隔不低于2ms，每次耗时不超过1ms

 Redis的过期删除策略：惰性删除 + 定期删除两种策略进行配合使用。

2.淘汰策略

当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。

• LRU的意思就是最少最近使用，用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。

• LFU的意思是最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。

1. 优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分，建议使用。

2. 如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用 allkeys-random，随机选择淘汰。

3. 如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。

4. 如果业务中有短时高频访问的数据，可以使用 allkeys-lfu 或 volatile-lfu 策略。

2、分布式锁

• Redis分布式锁如何实现？

在redis中提供了一个命令setnx(SET if not exists) 由于redis的单线程的，用了命令之后，只能有一个客户端对某一个key设置值，在没有过期或删除key的时候是其他客户端是不能设置这个key的。

• 那你如何控制Redis实现分布式锁有效时长呢？

redis的setnx指令不好控制这个问题，我们当时采用的redis的一个框架redisson实现的。在redisson中需要手动加锁，并且可以控制锁的失效时间和等待时间，当锁住的一个业务还没有执行完成的时候，在redisson中引入了一个看门狗机制，就是说每隔一段时间就检查当前业务是否还持有锁，如果持有就增加加锁的持有时间，当业务执行完成之后需要使用释放锁就可以了。

• redisson实现的分布式锁是可重入的吗？

嗯，是可以重入的。这样做是为了避免死锁的产生。这个重入其实在内部就是判断是否是当前线程持有的锁，如果是当前线程持有的锁就会计数，如果释放锁就会在计算上减一。在存储数据的时候采用的hash结构，大key可以按照自己的业务进行定制，其中小key是当前线程的唯一标识，value是当前线程重入的次数。

3、集群

（1）主从复制

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

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid。

offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

主从同步数据的流程：

全量同步是指从节点第一次与主节点建立连接的时候使用全量同步，流程是这样的：

1. 从节点请求主节点同步数据（replication id、 offset ）

2. 主节点判断是否是第一次请求，是第一次就与从节点同步版本信息（replication id和offset）

3. 主节点执行bgsave，生成rdb文件后，发送给从节点去执行

4. 在rdb生成执行期间，主节点会以命令的方式记录到缓冲区（一个日志文件）

5. 把生成之后的命令日志文件发送给从节点进行同步

增量同步指的是，当从节点服务重启之后，数据就不一致了，所以这个时候，从节点会请求主节点同步数据:

1. 从节点请求主节点同步数据，主节点判断不是第一次请求，不是第一次就获取从节点的offset值

2. 主节点从命令日志中获取offset值之后的数据，发送给从节点进行数据同步

（2）哨兵模式

哨兵（Sentinel）机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下：

• 监控：Sentinel 会不断检查您的master和slave是否按预期工作。

• 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主。

• 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端。

redis集群脑裂，该怎么解决呢？

集群脑裂是由于主节点和从节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到主节点，所以通过选举的方式提升了一个从节点为主，这样就存在了两个master，就像大脑分裂了一样，这样会导致客户端还在老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将老的主节点降为从节点，这时再从新master同步数据，就会导致数据丢失。

解决：我们可以修改redis的配置，可以设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的数据丢失。

（3）分片集群

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：海量数据存储问题、高并发写的问题。

使用分片集群可以解决上述问题，分片集群特征：

• 集群中有多个master，每个master保存不同数据

• 每个master都可以有多个slave节点

• master之间通过ping监测彼此健康状态

• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

Redis 分片集群引入了哈希槽的概念，Redis 集群有 16384 个哈希槽，每个 key通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash 槽。

4、Redis为什么这么快

1. 完全基于内存的，C语言编写

2. 采用单线程，避免不必要的上下文切换可竞争条件

3. 使用多路I/O复用模型，非阻塞IO

例如：bgsave 和 bgrewriteaof 都是在后台执行操作，不影响主线程的正常使用，不会产生阻塞

能解释一下I/O多路复用模型？

Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度， I/O多路复用模型主要就是实现了高效的网络请求。

I/O多路复用模型是指利用单个线程来同时监听多个Socket ，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。目前的I/O多路复用都是采用的epoll模式实现，它会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间，不需要挨个遍历Socket来判断是否就绪，提升了性能。

Redis网络模型:

二、MySQL篇 

1、定位慢查询

表象：页面加载过慢、接口压测响应时间过长（超过1s）

1. 方案一：开源工具

• 调试工具：Arthas

• 运维工具：Prometheus 、Skywalking

1. 方案二：MySQL自带慢日志

   慢查询日志记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认10秒）的所有SQL语句的日志如果要开启慢查询日志，需要在MySQL的配置文件（/etc/my.cnf）中配置如下信息：

 配置完毕之后，通过以下指令重新启动MySQL服务器进行测试，查看慢日志文件中记录的信息 /var/lib/mysql/localhost-slow.log。

2、SQL执行计划

那这个SQL语句执行很慢, 如何分析呢？

可以采用EXPLAIN 或者 DESC命令获取 MySQL 如何执行 SELECT 语句的信息。

可以采用MySQL自带的分析工具 EXPLAIN

1. 通过key和key_len检查是否命中了索引（索引本身存在是否有失效的情况）

2. 通过type字段查看sql是否有进一步的优化空间，是否存在全索引扫描或全盘扫描

3. 通过extra建议判断，是否出现了回表的情况，如果出现了，可以尝试添加索引或修改返回字段来修复

如果一条sql执行很慢的话，我们通常会使用mysql自动的执行计划explain来去查看这条sql的执行情况，比如在这里面可以通过key和key_len检查是否命中了索引，如果本身已经添加了索引，也可以判断索引是否有失效的情况，第二个，可以通过type字段查看sql是否有进一步的优化空间，是否存在全索引扫描或全盘扫描，第三个可以通过extra建议来判断，是否出现了回表的情况，如果出现了，可以尝试添加索引或修改返回字段来修复。

3、索引

索引（index）是帮助MySQL高效获取数据的数据结构(有序)。在数据之外，数据库系统还维护着满足特定查找算法的数据结构（B+树），这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

• 索引（index）是帮助MySQL高效获取数据的数据结构(有序)

• 提高数据检索的效率，降低数据库的IO成本（不需要全表扫描）

• 通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗

（1）存储引擎

存储引擎是存储数据、建立索引、更新/查询数据等技术的实现方式 。存储引擎是基于表的，而不是基于库的，所以存储引擎也可被称为表类型。

在mysql中提供了很多的存储引擎，比较常见有InnoDB、MyISAM、Memory

• InnoDB存储引擎是mysql5.5之后是默认的引擎，它支持事务、外键、表级锁和行级锁

• MyISAM是早期的引擎，它不支持事务、只有表级锁、也没有外键，用的不多

• Memory主要把数据存储在内存，支持表级锁，没有外键和事务，用的也不多

（2）索引底层数据结构

MySQL的InnoDB引擎采用的B+树的数据结构来存储索引

• 阶数更多，路径更短

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

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

  

（3）聚簇和非聚簇索引

• 如果存在主键，主键索引就是聚集索引。

• 如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引。

• 如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引。

聚簇索引主要是指数据与索引放到一块，B+树的叶子节点保存了整行数据，有且只有一个，一般情况下主键在作为聚簇索引的。

非聚簇索引值的是数据与索引分开存储，B+树的叶子节点保存对应的主键，可以有多个，一般我们自己定义的索引都是非聚簇索引。

回表查询是通过二级索引找到对应的主键值，到聚集索引中查找整行数据，这个过程就是回表。

覆盖索引是指查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到 。

覆盖索引是指select查询语句使用了索引，在返回的列，必须在索引中全部能够找到，如果我们使用id查询，它会直接走聚集索引查询，一次索引扫描，直接返回数据，性能高。如果按照二级索引查询数据的时候，返回的列中没有创建索引，有可能会触发回表查询，尽量避免使用select *，尽量在返回的列中都包含添加索引的字段。

mysql超大分页处理方法：超大分页一般都是在数据量比较大时，我们使用了limit分页查询，并且需要对数据进行排序，这个时候效率就很低，我们可以采用覆盖索引 和 子查询来解决先分页查询数据的id字段，确定了id之后，再用子查询来过滤，只查询这个id列表中的数据就可以了因为查询id的时候，走的覆盖索引，所以效率可以提升很多。

（4）索引创建原则

一般有以下原则：主键索引、唯一索引、根据业务创建的索引(复合索引)

1. 数据量较大，且查询比较频繁的表（一般超过10万）

2. 常作为查询条件、排序、分组的字段

3. 字段内容区分度高

4. 内容较长，使用前缀索引

5. 尽量联合索引

6. 要控制索引的数量

7. 如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它

（5）索引失效场景

• 违反最左前缀法则

• 范围查询右边的列，不能使用索引

• 不要在索引列上进行运算操作， 索引将失效

• 字符串不加单引号，造成索引失效。(类型转换)

• 以%开头的Like模糊查询，索引失效

4、SQL优化经验

（1）表的设计优化

• 比如设置合适的数值（tinyint int bigint），要根据实际情况选择。

• 比如设置合适的字符串类型（char和varchar）char定长效率高，varchar可变长度，效率稍低。

（2）SQL语句优化

• SQL语句优化SELECT语句务必指明字段名称（避免直接使用select * ）

• SQL语句要避免造成索引失效的写法

• 尽量用union all代替union union会多一次过滤，效率低

• 避免在where子句中对字段进行表达式操作

• Join优化 能用innerjoin 就不用left join right join，如必须使用 一定要以小表为驱动，内连接会对两个表进行优化，优先把小表放到外边，把大表放到里边。left join 或 right join，不会重新调整顺序

（3）主从复制、读写分离

主从复制、读写分离如果数据库的使用场景读的操作比较多的时候，为了避免写的操作所造成的性能影响 可以采用读写分离的架构。读写分离解决的是，数据库的写入，影响了查询的效率。

（4）分库分表

分库分表的时机：

1. 前提，项目业务数据逐渐增多，或业务发展比较迅速 （单表数据达到1000W或20G）

2. 优化已解决不了性能问题（主从读写分离、查询索引…）

3. IO瓶颈（磁盘IO、网络IO）、CPU瓶颈（聚合查询、连接数太多）

拆分策略：

 具体拆分策略

1. 水平分库，将一个库的数据拆分到多个库中，解决海量数据存储和高并发的问题

2. 水平分表，解决单表存储和性能的问题

3. 垂直分库，根据业务进行拆分，高并发下提高磁盘IO和网络连接数（微服务常用）

4. 垂直分表，冷热数据分离，多表互不影响

水平拆分时一般使用mycat中间件进行分库分表：

 mycat中间件可以解决分库分表时遇到的问题，比如：

• 分布式事务一致性问题

• 跨节点关联查询

• 跨节点分页、排序函数

• 主键重复

5、事务

（1）事务特征

事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。

事务的ACID特性：

• 原子性（Atomicity）：事务是不可分割的最小操作单元，要么全部成功，要么全部失败。

• 一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态。

• 隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。

• 持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。

redo log: 记录的是数据页的物理变化，服务宕机可用来同步数据

undo log ：记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据

redo log保证了事务的持久性，undo log保证了事务的原子性和一致性

（2）隔离级别

并发事务问题: 脏读、不可重复读、幻读

解决方案：对事务进行隔离

隔离级别：读未提交、读已提交、可重复读、串行化

 注意：事务隔离级别越高，数据越安全，但是性能越低。

 事务的隔离性是靠什么保证的？

• 锁：排他锁（如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁）

• mvcc : 多版本并发控制

（3）MVCC

全称 Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突MVCC的具体实现，主要依赖于数据库记录中的隐式字段、undo log日志、readView。

• 隐藏字段：

1. trx_id(事务id)，记录每一次操作的事务id，是自增的

2. roll_pointer(回滚指针)，指向上一个版本的事务版本记录地址

• undo log：

1. 回滚日志，存储老版本数据

2. 版本链：多个事务并行操作某一行记录，记录不同事务修改数据的版本，通过roll_pointer指针形成一个链表

• readView解决的是一个事务查询选择版本的问题

1. 根据readView的匹配规则和当前的一些事务id判断该访问那个版本的数据

2. 不同的隔离级别快照读是不一样的，最终的访问的结果不一样

RC ：每一次执行快照读时生成ReadView

RR：仅在事务中第一次执行快照读时生成ReadView，后续复用

6、主从同步原理

 MySQL主从复制的核心就是二进制日志。

二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。

复制分成三步：

1. Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。

2. 从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。

3. slave重做中继日志中的事件，将改变反映它自己的数据。