面试宝典(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集群)