缓存穿透、击穿、雪崩

《缓存三兄弟》

穿透无中生有key，布隆过滤null隔离
缓存击穿过期key，锁与非期解难题
雪崩大量过期key，过期时间要随机
面试必考三 兄 弟，可用限流来保底

什么是缓存穿透

指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这导致不存在的数据每次请求都要到DB去查询，可能导致DB挂掉。这种情况大概率是遭到了攻击。

解决方案（布隆过滤器）
缓存穿透解决方案：布隆过滤器。

布隆过滤器：用于检索一个元素是否在一个集合中，使用redisson实现。底层主要是先去初始化一个比较大数组，里面存放二进制0或1。在一开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据的下标然后把数组中原来的0改为1。这样的话，三个数组的位置就能标明一个key的存在。查找过程也是一样的。
优点：内存占用较少、保密性强、时间复杂度低（On）
缺点：可能产生一定的误判，一般可以设置误判率，大概不会超过5%，其实误判是必然存在的，要不就得增加数组的长度，5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库；无法获取元素本身；很难删除元素

什么是缓存击穿

对于设置了过期时间的key，缓存在某个时间点过期的时候，恰好这时间点对这个key有大量的并发请求，于是会请求DB加载数据回设到缓存，这个时候大并发请求会瞬间压垮DB。

解决方案

1、使用互斥锁:强一致、性能差
当缓存失效时，不去立刻load db，先使用redis的setnx去设置一个互斥锁，当操作成功返回在进行load db的操作并回设缓存，否则重试get缓存的方法。
2、设置当前key逻辑过期：高可用、性能优、不能保证数据绝对一致
①在设置key的时候，设置一个过期时间字段一块存入缓存，不给当前key设置过期时间
②当查询的时候，从redis取出数据后判断时间是否过期
③如果过期则开通另一个线程进行数据同步，当前线程正常返回数据（不是最新的）
利弊：如果选择数据强一致性，建议使用分布式锁的方案，性能上可能没那么高，锁需要等，也有可能产生死锁问题；如果选择key逻辑过期删除，高可用、性能比较高，但是数据同步这块做不到强一致。

什么是缓存雪崩

设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，瞬间压力过重雪崩。与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。

解决方案
主要是将缓存失效时间分散开，比如可以在原有失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存过期时间重复率就会降低，就很难引发集体失效的事件。
利用redis集群提高服务的可用性
给缓存业务添加降级限流策略（保底策略）
给业务添加多级缓存

双写一致性

mysql数据如何与redis进行同步？（双写一致性）

1、当时项目有公共查询组织机构的功能，需要让数据库与redis高度保持一致，但是要求时效性比较高，我们当时采用的读写锁保证强一致性。
采用的是redisson实现的读写锁，在读的时候添加共享锁，保证读读不互斥，读写互斥。当我们更新数据的时候，添加排他锁，它是读写，读读都互斥，这样能保证在写数据的同时是不会让其他线程读数据，避免脏数据。需要注意的是读方法和写方法上需要使用同一把锁才行。
排他锁如何保证读写、读读互斥？
排他锁底层使用也是setnx，保证了同时只能有一个线程操作锁住的方法。
延时双删用过吗？
延时双删：如果是写操作，先把缓存中的数据删除，然后更新数据库，最后再演示删除缓存中的数据，其中延时多久不太好确定，在延时过程中可能会出现脏数据，并不能保证强一致性，所以没有采用。
2、采用阿里的canal组件实现数据同步，不需要更改业务代码，部署一个canal服务，canal服务把自己伪装成mysql的一个从节点，当mysql数据更新以后，canal会读取binlog数据，然后在通过canal客户端获取数据，更新缓存即可。（或者mq，更新数据之后，通知缓存删除）

数据持久化

redis提供两种持久化的方式：RDB、AOF
区别：

RDB是一个快照文件，它是把redis内存存储的数据写到磁盘上，当redis实例宕机恢复数据的时候，方便从RDB的快照文件中恢复数据。
AOP的含义是追加文件，当redis操作写命令的时候，都会存储到这个文件中，当redis实例宕机恢复数据的时候，就会从这个文件再执行一遍命令来恢复数据。

	RDB	AOP
持久化方式	定对整个内存做快照	记录每一次执行命令
数据完整性	不完整，两次备份之间会丢失	取决于刷盘策略
文件大小	会有压缩，很小	记录命令，相对很大
宕机恢复速度	很快	慢
数据恢复优先级	低，数据完整性不如AOF	高
系统资源占用	高，大量cpu和内存消耗	低，主要是磁盘io。重写会占用大量cpu和内存资源。
使用场景	容忍数分钟的数据丢失	对数据安全性要求较高

两种方式，哪儿种恢复快？

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

过期策略

redis的key过期之后，回立即删除吗？

惰性删除：访问key的时候，才会过期检查。
定期删除：定期检查一定量的key是否过期
①slow模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件的hz选项来调整
②fast模式执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms
优点：可以通过限制删除操作执行的时长和频率来减少删除操作对CPU的影响。另外定期删除，也能有效释放过期键占用的内存。
缺点：难以确定删除操作执行的时长和频率。
redis的过期删除策略：惰性删除+定期删除配合使用

数据淘汰策略

redis淘汰策略是什么
redis内存不够时，再向redis中添加新的key，redis就会按照某一种规则将内存中的数据删除掉。

1.noeviction(默认策略)：对于写请求不再提供服务，直接返回错误
2.volatile-ttl：对设置了TTL的key，淘汰过期时间剩余最短的
3.allkeys-random：对全体key，随机数据
4.volatile-random：对设置了TTL的key，随机淘汰
LRU：最近最少使用，当前时间-最后一次访问时间，越大则淘汰优先级越高
LFU：最少频率使用，统计每个key的访问频率，值越小淘汰优先级越高
5.allkeys-lru：全体key，基于LRU算法进行淘汰
6.volatile-lru：对设置了TTL的key，基于LRU算法进行淘汰
7.allkeys-lfu：全体key，基于LFU算法进行淘汰
8.volatile-lfu：对设置了TTL的key，基于LFU算法进行淘汰

答：在redis中提供了八种，默认是noeviction，不删除任何数据，内存不足直接报错。可以在redis配置文件中设置，里面有两个非常重要的概念，一个是LRU，另外一个是LFU。LRU是最少最近使用，用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。LFU的意思是最少频率使用，会统计每个key访问频率，值越小淘汰优先级越高。我们在项目中设置的是allkeys-lru，挑选最近最少使用的数据淘汰，把一些经常访问的key留在redis中。

数据库有1000万数据，redis只能存储20w数据，任何保证redis中的数据都是热点数据？

使用allkeys-lru（最近最少使用）淘汰策略，留下来的都是经常访问的热点数据。

redis内存用完了会发生什么？

主要看淘汰策略是什么？如果是默认的，会直接报错

分布式锁

redis分布式锁，如何实现？

当时有一个培训模版，根据组织机构和人员id进行累加学时。需要加锁，防止脏数据。我们当时使用的redisson实现的分布式锁，底层是setnx和lua脚本（保证原子性）

如何合理控制锁的有效时长
redisson的分布式锁中，提供了一个WatchDog（看门狗），一个线程获取锁成功以后，WatchDog会给持有锁的线程续期（默认是每隔10秒续期一次）

答：redis的setnx指令不好控制锁的有效时长，我们采用redis的一个框架redisson实现的。redisson中需要手动加锁，并且可以控制锁的失效时间和等待时间，当锁住的一个业务还没有执行完成的时候，在redisson中引入一个看门狗机制，就是说每隔一段时间就检查当前业务是否还持有锁，如果持有就增加锁的持有时间，当业务执行完成需要释放锁。
还有一个好处就是，在高并发下，一个业务有可能会执行很快，客户1持有锁的时候，客户2来了以后不会马上拒绝，它会选择不断的尝试获取锁，如果客户1释放之后，客户2可以马上持有锁，性能也得到提升。

redisson分布式锁，可重入吗？

可以重入，多个锁重入需要判断是否是当前线程，在redis中进行存储的时候使用的hash结构，来存储线程信息和重入的次数。

redisson锁能解决主从数据一致的问题吗？

不能解决，但是可以使用redisson的红锁来解决，但是这样的话，性能太低了，如果业务中非要保持数据的强一致性，建议采用zookeeper实现的分布式锁。

redis集群

redis集群有哪些方案

redis提供的集群方案总共有三种，主从复制、哨兵模式、分片集群
主从和哨兵可以解决高可用、高并发读的问题，分片集群可以解决海量数据存储、高并发写问题

介绍一下redis主从同步

单节点redis的并发能力是有上限的，要进一步提高redis的并发能力，可以搭建主从集群，实现读写分离，一般都是一主多从，主节点负责写数据，从节点负责读数据，主节点写入数据之后，需要把数据同步到从节点中。

主从同步数据的流程

主从同步分为两个阶段，一个是全量同步，一个是增量同步。

全量同步：从节点第一次与主节点建立连接的时候使用全量同步。

①从节点请求主节点同步数据，从节点携带自己的replication id和offset偏移量。
②主节点判断是否是第一次请求。主要判断的依据就是，主节点与从节点是否是同一个replication id，如果不是，说明是第一次同步，主节点就会把自己的replication id和offset发送给从节点，让从节点与主节点的版本信息保持一致。
③同时主节点会执行bgsave，生成一个rdb文件，发送给从节点去执行，从节点先把自己的数据清空，然后执行主节点发送过来的rdb文件。
④如果在rdb生成执行期间，有请求走到了主节点，主节点会以命令的方式记录到缓冲区，缓冲区是一个日志文件，最后把这个日志文件发送给从节点，这样就能保证主节点与从节点完全一致。

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

①主节点判断不是第一次请求，获取从节点的offset值
②然后主节点从命令日志中获取offset值之后的数据，发送给从节点进行数据同步

怎么保证redis的高并发可用
哨兵模式：实现主从集群的自动故障恢复（监控，自动故障恢复，通知）

答：首先可以搭建主从集群，再加上redis的哨兵模式，哨兵模式可以实现主从集群的自动故障恢复，其中包含了对主从服务的监控、自动故障恢复、通知；如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主；同时sentinel也充当redis客户端的服务发现来源，放集群发生故障转移时，会将最新信息推送给redis客户端，所以一般项目会采用哨兵模式来保证redis的高并发高可用

使用redis是单点还是集群，哪儿种集群

主从（1主1从）+哨兵。单节点不超过10G内存，如果redis内存不足则可以给不同的服务分配独立的redis主从节点。尽量不做分片集群，因为集群维护起来比较麻烦，并且集群之间的心跳检测和数据通信会消耗大量的网络带宽，也没有办法使用lua脚本和事务

什么是redis集群脑裂

脑裂:这个在项目中很少见，脑裂问题是这样的，我们现在用的redis的哨兵模式集群，有的时候由于网络等原因可能会出现脑裂情况，就是说，由于redis master节点和redis salve节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到master，所以通过选举方式提升了一个salve为master，这样就存在了两个master，这样会导致客户端还在old master那里写入数据，新节点无法同步数据，当网络恢复以后，sentinel会将old master降为salve，这时候再从new master 同步数据，会导致old master中的大量数据丢失。

怎么解决redis集群脑裂：

我记得redis的配置中可以设置，第一可以设置最少得salve节点个数，比如设置至少要有一个从节点才能同步数据，第二个可以设置主从数据复制和同步的延迟时间，达不到要求就拒绝请求，可以避免大量的数据丢失。

分片集群有什么用

分片集群主要解决的是，海量数据存储问题，集群中有多个master，每个master保存不同数据，并且还可以给每个master设置多个salve节点，就可以继续增大集群的高并发能力，同时每个master之间通过ping监测彼此健康状态，就类似于哨兵模式了。当客户端请求可以访问集群任意节点，最终都会被转发到正确节点。

redis分片集群数据是怎么存储和读取的？

redis集群引入了哈希槽的概念，有2~14（16384）个哈希槽，集群中每个主节点绑定了一定范围的哈希槽范围，通过key的有效部分（如果key前面有大括号，大括号的内容就是有效部分，如果没有，则以key本身做为有效部分）计算哈希值，对16384取余，余数为插槽，找到对应的节点进行存储。

redis事务

MULTI： 开启事务
EXEC： 执行事务，按执行命令顺序返回结果。
DISCARD： 终止事务，清空命令队列并终止事务。
WATCH： 监听 key，被监听的 key 如果在事务之外被修改，则事务不会执行（EXEC 时结果返回 nil）。
UNWATCH： 取消监听 key。

具有隔离性、不具有持久性、不支持事务回滚，不满足原子性

I/O多路复用模型

redis是单线程的，但是为什么还那么快？

①完全基于内存的，c语言编写
②采用单线程，避免不必要的上下文切换可竞争条件
③使用I/O多路复用模型，非阻塞IO
例如：bgsave和bgrewriteaof都是在后台执行操作，不影响主线程的正常使用，不会产生阻塞

解释一下I/O多路复用模型？
redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，I/O多路复用模型主要是实现了高效的网络请求。
select和poll只会通知用户进程有Socket就绪，但是不确定具体是哪儿个Socket，需要用户进程逐个遍历Socket来确认
epoll则会通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间。

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

redis网络模型
使用I/O多路复用结合事件的处理器来应对多个Socket请求

连接应答处理器
命令回复处理器，在redis6.0之后，使用多线程来处理回复事件
命令请求处理器，在redis6.0之后，将命令的转换使用了多线程，增加命令转换速度，在执行命令的时候，依旧是单线程

答：其中redis的网络模型就是使用I/O多路复用结合事件的处理器来应对多个Socket请求，比如，提供了连接应答处理器、命令回复处理器、命令请求处理器；在redis6.0之后，为了提升更好的性能，在命令回复处理器使用了多线程来处理回复事件，在命令请求处理器中，将命令的转换使用了多线程，增加命令的转换速度，在执行命令的时候，依旧是单线程。