需要项目经验可自行上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的访问频率，值越小淘汰优先级越高。

优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分，建议使用。
如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用 allkeys-random，随机选择淘汰。
如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。
如果业务中有短时高频访问的数据，可以使用 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，需要更新。

主从同步数据的流程：

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

从节点请求主节点同步数据（replication id、 offset ）
主节点判断是否是第一次请求，是第一次就与从节点同步版本信息（replication id和offset）
主节点执行bgsave，生成rdb文件后，发送给从节点去执行
在rdb生成执行期间，主节点会以命令的方式记录到缓冲区（一个日志文件）
把生成之后的命令日志文件发送给从节点进行同步

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

从节点请求主节点同步数据，主节点判断不是第一次请求，不是第一次就获取从节点的offset值
主节点从命令日志中获取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为什么这么快

完全基于内存的，C语言编写
采用单线程，避免不必要的上下文切换可竞争条件
使用多路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）

方案一：开源工具

调试工具：Arthas
运维工具：Prometheus 、Skywalking

方案二：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

通过key和key_len检查是否命中了索引（索引本身存在是否有失效的情况）
通过type字段查看sql是否有进一步的优化空间，是否存在全索引扫描或全盘扫描
通过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）索引创建原则

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

数据量较大，且查询比较频繁的表（一般超过10万）
常作为查询条件、排序、分组的字段
字段内容区分度高
内容较长，使用前缀索引
尽量联合索引
要控制索引的数量
如果索引列不能存储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，不会重新调整顺序