面试宝典（2）——缓存篇（Redis）

面试宝典（2）——缓存篇（Redis）

1.Redis的主要用途有哪些？

• 缓存
• 分布式锁：setnx，redisson
• 消息队列，延迟队列

2.什么是缓存穿透？

查询一个不存在的数据，数据库查询不到，同时也不会写入缓存，这就会导致每次查询都会去请求数据库。

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

优点：简单

缺点：消耗内存，可能会发生数据不一致问题。

解决方案二：布隆过滤器

布隆过滤器可以用于检索一个元素是否在集合中。

优点：内存占用少，没有多余的key

缺点：实现复杂，存在误判

3.什么是缓存击穿？

概念：当某一个热点Key设置了过期时间，当Key过期时，恰好这个时间点过来大量请求，将数据库压倒。

缓存击穿通常发生在缓存中设置了过期时间，而在该数据过期后，大量请求同时访问该数据的情况下。

解决方案一：互斥锁，互斥锁可是实现强一致性，性能略差。

解决方案二：设置逻辑过期。对于缓存数据，不设置过期时间，但是在缓存数据中设置逻辑过期。这种方案属于高可用，性能较优，但是逻辑过期实现的是最终一致。当业务允许短暂的不一致时，可以使用逻辑过期。

4.什么是缓存雪崩？

缓存雪崩是指在同一时段内大量缓存的key同时失效，或者Redis服务宕机，导致大量的请求同时到达数据库，从而导致数据库承受大量压力。

解决方案：

• 给不同的key设置不一样的TTL时间，或者设置指定范围内的随机值
• 利用Redis集群提高服务的可用性，比如哨兵模式，集群模式
• 给业务添加降级限流策略，比如nginx，Spring cloud gateway
• 给业务添加多级缓存，比如Guava或者Caffeine

5.Redis缓存的双写一致性

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

1.采用延时双删的策略进行同步

删除缓存——>修改数据库——>延时删除缓存

延时双删依然存在脏数据的分险，做不到绝对的强一致。

2.采用互斥锁，可以实现强一致

共享锁：读锁readLock,加锁之后，其他数据可以共享读操作，写操作则互斥。共享锁可以实现最终一致性。

排它锁：独占锁writeLock,加锁之后，阻塞其他线程读写操作，即读写均互斥，排它锁可以保证强一致性。

Redisson提供了读写锁的功能：

RLock lock = (RLock) redissonClient.getReadWriteLock("LOCK_NAME");
boolean update = lock.tryLock();

3.异步通知，保证数据的最终一致性，例如MQ等

6.Redis持久化

Redis提供了两种持久化方式，分别是RDB和AOF

1.RDB

RDB是Redis的数据备份文件，也叫Redis快照文件。它把内存中的所有数据都记录在磁盘中，当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

可以通过以下命令手动执行

# 由Redis主进程来执行RDB，会阻塞所有命令
save
# 开启子进程执行RDB，不会阻塞主进程，避免主进程受到影响
bgsave

也可以通过redis的配置文件redis.conf中去配置它的执行状况，可以根据自己的需要自行配置

# 900秒内如果至少有1个key被修改，则执行bgsave,以下同理
save 900 1
save 300 10
save 60 10000

执行原理：bgsave开始执行时会fork主进程得到子进程，子进程共享主进程中的数据。完成后fork后读取内存数据并写入RDB文件中。

fork时采用的是一种 copy-on-write 技术，主进程执行读操作时，访问共享内存。主进程 执行写操作时，则会拷贝一份数据，执行写操作。

2.AOF

AOF为（Append Of File）追加文件。Redis的每一个命令都会被记录在AOF文件中，可以看做命令日志文件。

AOF功能默认是关闭的，需要修改redis.conf文件来开启。

# 是否开启AOF功能
appendonly no
# AOF文件名称
appendfilename "appendonly.aof"
# AOF记录频率，也叫刷盘策略，共有三种策略
appendfsync everysec

• always：同步刷盘，可靠性高，但是对性能的影响大
• everysec：每秒刷盘，性能适中，最多只丢失1秒的数据
• no：操作系统控制，性能最好，但是可靠性较差，可能会丢失大量数据

因为是记录命令，AOF文件会比RDB文件大得多。而且AOF会记录对一个key的多次写操作，但只有最后一次操作才有意义。

通过bgrewriteaof命令,可以让AOF文件执行重写功能，用最少的命令达到相同的效果。

# AOF文件比上次大小增长超过100%时，触发重写(配置文件大小增长的百分比)
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才出发重写（配置文件增长的大小）
auto-aof-rewrite-min-size 64mb

7.Redis数据过期策略

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

Redis中提供了两种过期策略，分别为惰性策略和定期删除。

• 惰性删除：key过期后不会自己删除，等以后再次使用该key时会检查它是否过期。如果过期则删除，反之则返回。
• 定期删除：每隔一段时间会对一部分key进行检查，如果过期则进行删除。定时清理分为SLOW模式和FAST模式，SLOW模式是定时任务执行频率可以通过配置来自己调节；FAST模式执行频率不固定

# 通过redis.conf文件中的hz来调节定期删除的频率
hz 10

8.Redis数据淘汰策略

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

Redis默认支持8种淘汰策略。

• No Eviction（不淘汰）
• Allkeys-lru（最近最少使用）
• Volatile-lru（基于LRU的过期键淘汰）
• Allkeys-random（随机淘汰）
• Volatile-random（基于随机的过期键淘汰）
• Volatile-ttl（基于TTL的过期键淘汰）
• Volatile-lfu（基于LFU的过期键淘汰）
• Allkeys-lfu（基于LFU的淘汰）

# 配置数据淘汰策略，默认为 noeviction
maxmemory-policy noeviction

扩展：LRU表示最近最少使用；LFU表示最少评率使用。

9.Redis分布式锁的使用场景

一般常见的业务有抢券，秒杀等高并发场景。

单体项目并且只有一台服务器时，使用synchronized加锁即可。

集群状态下，则synchronized不再适用，需要使用分布式锁来实现。

synchronized是属于本地锁，即JVM的锁。集群状态下，每个jvm都有各自的锁，所以synchronized将不再适用。

Redis分布式锁主要利用Redis的setnx命令实现。如果加锁成功，则返回该锁的值，否则返回0

# 添加一个锁，NX表示互斥，EX用来设置锁的过期时间(获取锁)
set key value nx ex 10
# 直接使用setnx命令设置锁，不设置过期时间
setnx key value
# 删除锁（释放锁）
del key

注意：如果不设置过期时间，有可能导致死锁的问题。

在设置锁的过期时间时，可以根据业务的执行时间来进行预估。也可以续期锁。

续期锁时可以使用Redisson来实现，它的内部已经利用Watch Dog（看门狗）机制实现了续期的功能。

Redisson实现分布式锁的原理是setnx和lua脚本,lua脚本保证了redis命令的原子性。

RLock lock = (RLock) redissonClient.getLock(LOCK + 12);
boolean lock = lock.tryLock();
if(lock){
    try {
       // code
    } finally {
        log.info("释放锁......");
        lock.unlock();
    }
}

注意：分布式锁可以重入

如果要保证强一致性，应该在多个实例上创建锁（n/2+1）。

10.Redis中常用的集群方案

1.主从复制

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

2.哨兵模式

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。

哨兵机制的作用如下：

• 监控：Sentinel会定期检查mater和slave是否按照预期工作。
• 自动故障恢复：如果master故障，setinel会按照指定规则将一个slave提升为master。当故障实例回复后将以slave身份运行；如果节点故障，则会自动去除。
• 通知：Sentinel充当redis客户端的服务发现来源，当集群发生故障转移时，会将最新的消息推送给Redis客户端。
  

Sentinel基于心跳机制检查服务状态，每隔一秒向集群的每个实例发送ping命令。

• 主观下线：如果某Sentinel节点发现某实例围在规定时间内响应，则认为该实例时主观下线。
• 客观下线：如果超过指定数量（quorum）的Sentinel都认为该实例主观下线，则该实例客观下线。quorum的值最好超过Sentinel实例的一般。

11.Redis集群的脑裂问题

Redis集群脑裂问题是指在Redis集群中出现网络分区的情况，导致集群中的不同部分无法相互通信，从而导致数据不一致或数据丢失的问题。脑裂问题通常发生在网络分区或节点故障的情况下，如果集群无法及时检测并处理这种情况，就会出现脑裂问题。

脑裂问题的解决办法：通过配置Redis的两个关键参数控制

min-replicas-to-write 1 : 表示主节点最少要有一个从节点

min-replicas-max-lag 5 : 表示数据复制和同步的延迟不能超过5秒

12.Redis分片集群

Redis分片集群引入了哈希槽的概念，集群的每一个节点负责一部分哈希槽，也就说，每个节点只存储一部分数据。

13.Redis是单线程的，但是为什么还那么快？

1.Redis是基于内存的，执行速度非常快

2.采用单线程，避免了不必要的可竞争条件，且不需要考虑线程切换带来的安全问题。

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

关于Redis集群，哨兵，和分片集群的搭建：SpringCloud（13）— 分布式缓存(Redis集群)