Redis常用场景、数据结构、读写一致、缓存穿透、缓存雪崩等

末蓝、 2022-05-14 01:36 87阅读 0赞

## 一、分布式系统为什么要用Redis ##

### 1、性能 ###

> 我们在碰到需要执行耗时特别久，且结果不频繁变动的 SQL，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，使得请求能够迅速响应。

### 2、并发 ###

> 在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用 Redis 做一个缓冲操作，让请求先访问到 Redis，而不是直接访问数据库。

## 二、应用场景 ##

### 1、缓存 ###

缓存现在几乎是所有中大型网站都在用的必杀技，合理的利用缓存不仅能够提升网站访问速度，还能大大降低数据库的压力。Redis提供了键过期功能，也提供了灵活的键淘汰策略，所以，现在Redis用在缓存的场合非常多。

### 2、排行榜 ###

很多网站都有排行榜应用的，如京东的月度销量榜单、商品按时间的上新排行榜等。Redis提供的有序集合数据类构能实现各种复杂的排行榜应用。

### 3、计数器 ###

什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景。

### 4、分布式会话 ###

集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。

### 5、分布式锁 ###

在很多互联网公司中都使用了分布式技术，分布式技术带来的技术挑战是对同一个资源的并发访问，如全局ID、减库存、秒杀等场景，并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现，但在并发量高的场合中，利用数据库锁来控制资源的并发访问是不太理想的，大大影响了数据库的性能。可以利用Redis的setnx功能来编写分布式的锁，如果设置返回1说明获取锁成功，否则获取锁失败，实际应用中要考虑的细节要更多。

### 6、社交网络 ###

点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据，Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。

### 7、最新列表 ###

Redis列表结构，LPUSH可以在列表头部插入一个内容ID作为关键字，LTRIM可用来限制列表的数量，这样列表永远为N个ID，无需查询最新的列表，直接根据ID去到对应的内容页即可。

### 8、消息系统 ###

消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

## 三、Redis为什么这么快 ##

*主要是以下三点：*

*  纯内存操作
 *  单线程工作模型，避免了频繁的上下文切换
 *  采用了非阻塞 I/O 多路复用机制

## 四、Redis数据类型 ##

### 1、String ###

这个没啥好说的，最常规的 set/get 操作，Value 可以是 String 也可以是数字。一般做一些复杂的计数功能的缓存。

### 2、Hash ###

这里 Value 存放的是结构化的对象，比较方便的就是操作其中的某个字段。  
做单点登录的时候，可以用这种数据结构存储用户信息，以 CookieId 作为 Key，设置 30 分钟为缓存过期时间，能很好的模拟出类似 Session 的效果。

### 3、List ###

使用 List 的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用 lrange 命令，做基于 Redis 的分页功能，性能极佳，用户体验好。

### 4、Set ###

因为 Set 堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用 JVM 自带的 Set 进行去重？因为我们的系统一般都是集群部署，使用 JVM 自带的 Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。  
另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

### 5、Sorted Set ###

Sorted Set多了一个权重参数 Score，集合中的元素能够按 Score 进行排列。可以做排行榜应用，取 TOP N 操作。Sorted Set 可以用来做延时任务。最后一个应用就是可以做范围查找。点击这里查看Redis面试题汇总。

## 五、Redis 的过期策略以及内存淘汰机制 ##

> 比如你 Redis 只能存 5G 数据，可是你写了 10G，那会删 5G 的数据。怎么删的，这个问题思考过么？
> 
> 还有，你的数据已经设置了过期时间，但是时间到了，内存占用率还是比较高，有思考过原因么?

**回答：Redis 采用的是定期删除+惰性删除策略。**

### 1、定期删除+惰性删除是如何工作 ###

定期删除，Redis 默认每过 **100ms** 检查，是否有过期的 Key，有过期 Key 则删除。  
需要说明的是，Redis 不是每个 100ms 将所有的 Key 检查一次，而是**随机抽取进行检查**(如果每隔 100ms，全部 Key 进行检查，Redis 岂不是卡死)。

因此，如果只采用定期删除策略，会导致很多 Key 到时间没有删除。于是，**惰性删除**派上用场。

也就是说在你获取某个 Key 的时候，Redis 会检查一下，这个 Key 如果设置了过期时间，那么是否过期了？如果过期了此时就会删除。

### 2、采用定期删除+惰性删除就没其他问题了么? ###

不是的，如果定期删除没删除 Key。然后你也没即时去请求 Key，也就是说惰性删除也没生效。这样，Redis的内存会越来越高。那么就应该采用内存淘汰机制。

### 3、内存淘汰机制 ###

**在 redis.conf 中有一行配置：**

# maxmemory-policy volatile-lru

该配置就是配内存淘汰策略的：

*  `noeviction`：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。
 *  `allkeys-lru`：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 Key。推荐使用，目前项目在用这种。
 *  `allkeys-random`：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 Key。不推荐。
 *  `volatile-lru`：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 Key。这种情况一般是把 Redis 既当缓存，又做持久化存储的时候才用。不推荐。
 *  `volatile-random`：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 Key。依然不推荐。
 *  `volatile-ttl`：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。不推荐。

> 如果没有设置 expire 的 Key，那么 volatile-lru，volatile-random 和 volatile-ttl 策略的行为，和 noeviction(不删除) 基本上一致。

## 六、Redis常见问题 ##

### 1、Redis 和 DB 一致性 ###

**查询：**

> 先查Redis，没命中再查DB，然后写Redis

**更新：**

> 先删Redis，再更新DB，然后写Redis

### 2、缓存穿透 ###

**概念：**

> 一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就去DB查找。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对DB造成很大的压力。这就叫做缓存穿透。

**解决方案：**

*  对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存；
 *  对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的set中，查询时通过该set过滤(用的较少)；

### 3、缓存雪崩 ###

**含义：**  
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给DB带来很大压力。

**解决方案**

*  在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待;
 *  不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀;
 *  做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期;

### 4、并发竞争Key ###

> 这个问题大致就是，同时有多个子系统去 Set 一个 Key。这个时候大家思考过要注意什么呢？

**如果对这个 Key 操作，不要求顺序:**

这种情况下，准备一个**分布式锁**，大家去抢锁，抢到锁就做 set 操作即可，比较简单。

**如果对这个 Key 操作，要求顺序:**

> 假设有一个 key1，系统 A 需要将 key1 设置为 valueA，系统 B 需要将 key1 设置为 valueB，系统 C 需要将 key1 设置为 valueC。

期望按照 key1 的 value 值按照 `valueA > valueB > valueC` 的顺序变化。这种时候我们在数据写入数据库的时候，需要保存一个时间戳。

*假设时间戳如下：*

系统A key 1 {valueA  3:00}
        系统B key 1 {valueB  3:05}
        系统C key 1 {valueC  3:10}

那么，假设这会系统 B 先抢到锁，将 key1 设置为`{valueB 3:05}`。接下来系统 A 抢到锁，发现自己的 valueA 的时间戳早于缓存中的时间戳，那就不做 set 操作了，以此类推。

其他方法，比如利用**队列**，将 set 方法变成**串行访问**也可以。总之，灵活变通。