Redis面试常见问题——使用场景问题-EW帮帮网

布隆过滤器主要是用于检索一个元素是否在一个集合中。我们当时使用的是Redisson实现的布隆过滤器。它的底层原理是，先初始化一个比较大的数组，里面存放的是二进制0或1。一开始都是0，当一个key来了之后，经过3次hash计算，模数组长度找到数据的下标，然后把数组中原来的0改为1。这样，三个数组的位置就能标明一个key的存在。查找的过程也是一样的。

布隆过滤器有可能会产生一定的误判，我们一般可以设置这个误判率，大概不会超过5%。其实这个误判是必然存在的，要不就得增加数组的长度。5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库。

缓存击穿

缓存击穿的意思是:redis某个热点key过期或者刚开始，但是此时有大量的用户访问该过期key（或者大并发场景下刚开始这个数据只在数据库里不在缓存里），这个时候大并发的请求可能会瞬间把 DB 压垮。

解决方案有两种方式：

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

第二种方案是设置当前key逻辑过期，大概思路如下：

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

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

3) 如果过期，则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据可能不是最新的。

总结，两种方案各有利弊：如果选择数据的强一致性，建议使用分布式锁的方案，但性能上可能没那么高，且有可能产生死锁的问题。如果选择key的逻辑删除，则优先考虑高可用性，性能比较高，但数据同步这块做不到强一致。

缓存雪崩

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

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

双写一致性（redis做为缓存，mysql的数据如何与redis进行同步呢？）

不同的业务场景有不同的策略，面试时一定要根据业务实际情况回答。

双写一致性：当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致

1.若一致性要求高：强一致方案（分布式锁）

采用redisson实现的读写锁。

在读的时候添加共享锁，可以保证读读不互斥，读写互斥(其他线程可以一起读，但是不能写)。当我们更新数据的时候，添加排他锁，它是读写，读读都互斥（其他线程不能读也不能写），这样就能保证在写数据的同时是不会让其他线程读数据的，避免了脏数据。排他锁底层使用也是setnx，保证了同时只能有一个线程操作锁住的方法。

共享锁：读锁readLock，加锁之后，其他线程可以共享读操作。

排他锁：独占锁writeLock也叫，加锁之后，阻塞其他线程读写操作。

2.延时双删

策略原理：延时双删策略的核心是在写库操作的前后分别进行删除缓存操作，并设定合理的超时时间来确保读请求结束，写请求可以删除可能产生的缓存脏数据。
具体步骤：先删除缓存，再写数据库，然后线程休眠一段时间（比如500毫秒），最后再次删除缓存。休眠时间的确定需要评估项目读数据业务逻辑的耗时，并考虑Redis和数据库主从同步的耗时。
优缺点：这种策略能在一定程度上解决数据不一致的问题，但增加了写请求的耗时，并且在最差的超时时间内，数据仍可能存在不一致性。

延时删除的具体方案，异步通知保证数据的最终一致性

基于Canal的异步通知：

总结：

允许延时一致的业务，采用异步通知使用MQ中间中间件，更新数据之后，通知缓存删除利用canal中间件，不需要修改业务代码，伪装为mysql的一个从节点，canal通过读取binlog数据更新缓存。强一致性的，采用Redisson提供的读写锁 共享锁：读锁readLock，加锁之后，其他线程可以共享读操作 排他锁：独占锁writeLock也叫，加锁之后，阻塞其他线程读写操作

数据的持久化

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

Redis持久化

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

RDB的执行原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。 fork采用的是copy-on-write技术：当主进程执行读操作时，访问共享内存；当主进程执行写操作时，则会拷贝一份数据，执行写操作。

AOF执行原理

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置。

RDB与AOF对比

Redis的数据过期策略有哪些

Redis数据删除策略-惰性删除

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

优点：对CPU友好，只会在使用该key时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查。

缺点：对内存不友好，如果一个key已经过期，但是一直没有使用，那么该key就会一直存在内存中，内存永远不会释放。

Redis数据删除策略-定期删除

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

定期清理有两种模式：

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

优点：可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。缺点：难以确定删除操作执行的时长和频率。

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

Redis的数据淘汰策略有哪些

数据淘汰策略

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

Redis支持8种不同策略来选择要删除的key：

noeviction：不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略。
volatile-ttl：对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰
allkeys-random：对全体key ，随机进行淘汰。
volatile-random：对设置了TTL的key ，随机进行淘汰。
allkeys-lru：对全体key，基于LRU算法进行淘汰
volatile-lru：对设置了TTL的key，基于LRU算法进行淘汰
allkeys-lfu：对全体key，基于LFU算法进行淘汰
volatile-lfu：对设置了TTL的key，基于LFU算法进行淘汰

LRU（Least Recently Used）最近最少使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。 LFU（Least Frequently Used）最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。

数据淘汰策略-使用建议

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

选用Redis八股：Docs

Redis面试常见问题——使用场景问题