常见场景

缓存：穿透、击穿、雪崩、双写一致、持久化、数据淘汰、淘汰策略；
分布式锁：setnx、redisson；
计数器、保存token、消息队列、延迟队列：数据类型；

---

常见问题

• 什么是缓存穿透，怎么解决？
• 什么是布隆过滤器？
• 什么是缓存击穿，怎么解决？
• 什么是缓存雪崩，怎么解决？
• Redis双写问题?
• Redis作为缓存如何实现持久化？
• Redis的数据过期策略有哪些?
• Redis的数据淘汰策略有哪些?
• Redis分布式锁如何实现?
• Redis实现分布式锁如何合理的控制锁的有效时长?
• 什么是 Redis 主从同步?
• Redis集群有哪些方案?
• 使用的Redis是单点还是集群?哪种集群？
• Redis集群脑裂？
• Redis分片集群中数据是怎么存储和读取的？
• 怎么保证Redis的高并发高可用？
• Redis是单线程的，但是为什么还那么快?
• 用过Redis的事务吗?事务的命令有哪些？
• …

---

问题1、2

缓存穿透、布隆过滤器

示例场景

缓存穿透

查询一个不存在的数据，mysql查不到，因此不会直接写入，导致频繁查询数据库；

解决方案一

缓存空数据,即使查询返回数据为空，也仍把空结果缓存；
优点：简单；
缺点：内存消耗，可能导致不一致问题；

解决方案二

布隆过滤器：

作用：检索一个元素是否在集合中；

优点：内存占用少，没有多余key；
缺点：实现相对复杂，存在误判；

---

问题3

缓存击穿

示例场景

缓存击穿

给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮；

解决方案

互斥锁
优点：强一致；
缺点：性能差；
逻辑过期
优点：高可用，性能优；
缺点：不能保证数据绝对一致；

---

问题4

缓存雪崩

示例场景

缓存雪崩

指在同一时间段大量的缓存key同时失效或者Redis宕机，导致大量请求到达数据库，带来巨大的查询压力；

解决方案

• 给不同的key的TTL添加随机值；
• 利用Redis集群提高服务可用性：哨兵模式、集群模式；
• 给缓存业务添加降级限流策略：ngxin或spring cloud gateway
• 给业务添加多级缓存:Guava或者Caffeine

---

问题5

示例场景

双写一致性

双写一致性

当修改了数据库的数据，也要同时更新缓存的数据，缓存数据于数据库数据要保持一致；

强一致方案

Redisson提供的读写锁
共享锁：读锁readLock，加锁后，其他线程可以共享读操作；
排它锁：独占锁writeLock，加锁后，阻塞其他线程读写操作；

允许延时一致方案

MQ中间件:更新数据后，通知缓存删除；

canal中间件:监听binlog数据更新缓存，不需要修改业务代码；

---

问题6

Redis持久化

RDB方式

bgsave开始时会fork主进程得到子进程，子进程 （不是子线程） 会共享主进程的内存数据，完成fork后读取内存数据并写入RDB文件；
fork采用的是copy-on-write技术

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作；
  

AOF方式

AOF全称为Append Only File(追加文件)，Redis处理的每一个读写命令都会记录在AOF文件中，可以看作是命令日志文件；

需要注意的是，AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

AOF命令的记录频率也可以通过redis.conf文件来配置：


因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果；

Redis也会在触发阈值时自动去重写AOF文件，阈值也可以在redis.conf中进行配置：

两种方式对比

RDB和AOF各有优缺点，如果对数据安全性要求较高，在实际开发中往往结合两者来使用；

---

问题7

Redis数据过期策略

数据过期策略

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

惰性删除

设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key；
优点:对CPU友好，只会在使用该key时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查；
缺点:对内存不友好，如果一个key已经过期，但是一直没有使用，那么该key就会一直存在内存中，内存永远不会释放；

定期删除

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

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

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

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

---

问题8

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 策略；

问题9、10、11

示例场景

/**
*抢购优惠券
@throws InterruptedException
*/
public void rushToPurchase() throws InterruptedException {
//获取优惠券数量
Integer num = (Integer) redisTemplate.opsForValue().get("num");
//判断是否抢完
if (null == num | num <= 0){throw new RuntimeException(“优惠券已抢完");
//优惠券数量减一，说明抢到了优惠券
num = num-1;
//重新设置优惠券的数量
redisTemplate.opsForValue().set("num", num);

代码在高并发场景下存在问题，通过对线程加锁，可以解决，但在集群部署情况下，对线程加锁无法影响集群中其他服务线程对该资源的访问；

实现原理

setnx命令

Redis实现分布式锁主要利用setnx命令，setnx是SET if not exists的简写。

• 获取锁：SET lock value NX EX 10 # NX是互斥，EX是设置超时时间
• 释放锁：DEL key
  

Redisson

• 控制锁的有效时长
  
• 可重入
  示例场景：

public void add1(){RLock lock= redissonClient.getLock("heimalock");boolean isLock = lock.tryLock();//执行业务add2();//释放锁lock.unlock();
}
public void add2(){RLock lock = redissonClient.getLock("heimalock");boolean isLock = lock.tryLock();//执行业务//释放锁lock.unlock();
}

利用hash结构记录线程id与重入次数：

• 主从一致性
  存在隐患：
  
  
  RedLock(红锁)：在多个redis实例上创建锁（n/2+1），避免在一个redis实例上加锁；
  
  红锁缺点：实现复杂、性能差、运维繁琐；实际业务中一般不建议使用；
  如果业务中一定要保证数据的强一致性，建议使用zookeeper实现的分布式锁；

---

问题12、13、14

Redis集群方案

集群方案

Redis中提供的集群方案总共有3种：主从复制、哨兵模式、分片集群；

主从复制

单节点Redis的并发能力是有上限的，要进一步提高Redis并发能力，就需要搭建主从集群，实现读写分离；数据同步的方式有全量同步、增量同步；

• 全量同步：
  Replication ld:简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid；
  offset:偏移量，随着记录在repl_bakloq中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset;如果slave的offset小于master的offset，说明slave数据落后于master，需要更新;
  
• 增量同步
  

哨兵模式

哨兵（Sentinel）机制主要实现主从集群的自动故障恢复，哨兵的结构和作用如下：

• 监控:Sentinel会不断检查您的master和slave是否按预期工作；
• 自动故障恢复:如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主；
• 通知:Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端；
  

服务状态监控

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令:

• 主观下线:如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线；
• 客观下线:若超过指定数量(quorum)的sentinel都认为该实例主观下线，则该实例客观下线；quorum值最好超过Sentinel实例数量的一半；
  

哨兵选主规则

• 首先判断主与从节点断开时间长短，如超过指定值就排该从节点；
• 然后判断从节点的slave-priority值，越小优先级越高；
• 如果slave-prority一样，则判断slave节点的offset值，越大优先级越高；
• 最后是判断slave节点的运行id大小，越小优先级越高。

哨兵脑裂

集群脑裂：是由于主节点和从节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到主节点，所以通过选举的方式提升了一个从节点为主，这样就存在了两个master，就像大脑分裂了一样，这样会导致客户端还在老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将老的主节点降为从节点，这时再从新master同步数据，就会导致数据丢失；
解决:我们可以修改redis的配置，可以设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求就可以避免大量的数据丢失；
min-replicas-to-write 1：表示最少的salve节点为1个；
min-replicas-max-lag 5 :表示数据复制和同步的延迟不能超过5秒；

---

问题15、16

分片集群、高并发

分片集群

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：海量数据存储、高并发写；
使用分片集群可以解决上述问题；
分片集群特征:

• 集群中有多个master，每个master保存不同数据，每个master都可以有多个slave节点；
• master之间通过ping监测彼此健康状态；
• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点；
  

数据读写

Redis 分片集群引入了哈希槽的概念，Redis 集群有 16384 个哈希槽，每个 key通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash 槽；

---