Redis详细学习资料！！

刺骨的言语ヽ痛彻心扉 2022-12-01 01:15 146阅读 0赞

### Redis学习目录 ###

*   *  一、NoSQL
     *  二、什么是Redis？
     *  三、redis的功效及应用场景
     *   *  应用场景
     *  四、Redis常用命令
     *   *  4.1、Key-String
         *  4.2、Key-Hash
         *  4.3、Key-List
         *  4.4、Key-Set
         *  4.5、Key-Zset
         *  4.6、key的常用命令
         *  4.7、库的常用命令
     *  五、Java连接Redis
     *  六、Redis的其他配置及集群
     *   *  6.1 Redis 的 AUTH
         *  6.2 面试官：Redis到底有没有事务 ？
         *  6.3、Redis的持久化机制
         *  6.4、Redis的主从架构
         *  6.5、Redis的哨兵
         *  6.6、Redis的集群
     *  七、面试常问
     *   *  7.1、key的生存时间到了，Redis会立即删除吗？
         *  7.2、Redis的淘汰机制
         *  7.3、缓存常见问题
         *   *  1、缓存穿透
             *  2、缓存击穿
             *  3、缓存雪崩（缓存失效）
             *  4、缓存倾斜

## 一、NoSQL ##

[NoSQL学习点击][NoSQL]

## 二、什么是Redis？ ##

**Redis (Remote Dictionary Server)即远程字典服务**，Redis是由C语言去编写，Redis是一款基于Key-Value的NoSQL,而且Redis是 基于内存存储数据的，Redis还提供了多种持久化机制，性能可以达到110000/s读取数据以及81000/s写入数据，Redis还提供了主 从，哨兵以及集群的搭建方式，可以更方便的横向扩展以及垂直扩展。

**有一位意大利人，在开发一款LLOOGG的统计页面，因为MySQL的性能不好，自己研发了一款非关系型数据库，并命名为Redis。这个人就是Antirez（Salvatore Sanfilippo）。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center]

## 三、redis的功效及应用场景 ##

Redis能够解决传统关系型数据库在高并发的情况下读写过慢的问题，是一种以key-value形式存储数据的一款nosql关系型数据库之一，它支持多种数据结构，常用的五种数据结构主要如下：

<table> 
 <thead> 
  <tr> 
   <th>数据结构</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>key-string</td> 
   <td>—个 key 对应一个值</td> 
  </tr> 
  <tr> 
   <td>key-hash</td> 
   <td>:—个 key 对应一个 Map</td> 
  </tr> 
  <tr> 
   <td>key-list</td> 
   <td>一个key对应一个列表</td> 
  </tr> 
  <tr> 
   <td>key-set</td> 
   <td>—个key对应一个集合</td> 
  </tr> 
  <tr> 
   <td>key-zset</td> 
   <td>一个key对应一个有序的集合</td> 
  </tr> 
 </tbody> 
</table>

另外三种数据结构（比较少用）：

<table> 
 <thead> 
  <tr> 
   <th>数据结构</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>HyperLogLog</td> 
   <td>计算近似值的</td> 
  </tr> 
  <tr> 
   <td>GEO</td> 
   <td>地理位置</td> 
  </tr> 
  <tr> 
   <td>BIT</td> 
   <td>一般存储的也是一个字符串，存储的是一个byte[]</td> 
  </tr> 
 </tbody> 
</table>

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 1]

### 应用场景 ###

*  1.好友点赞
 *  2.热点数据缓存
 *  3.社交网络
 *  4.排行榜

## 四、Redis常用命令 ##

### 4.1、Key-String ###

存储的数据结构如下：  
![在这里插入图片描述][2020082513125534.png_pic_center]

**1.添加值**

> set key value  
> 例如:set name zhangsan

**2.取值**

> get key  
> 例如:get name

**3 .批量操作**

> mset key value \[key value…\]  
> 例如:mset name zhangsan age 18  
> mget key \[key…\]  
> 例如:mget name age

**4.自增命令（自增1）**

> incr key  
> 例如:incr age

**5.自减命令（自减1）**

> deer key  
> 例如:deer age

**6.自增或自减指定数量**

> inerby key increment  
> deerby key increment  
> 例如:inerby age 2

**7.设置值的同时，指定生存时间（每次向Redis中添加数据时，尽量都设置上生存时间）**

> setex key second value  
> 例如:setex name 30 zhangsan

**8.设置值，如果当前key不存在的话（如果这个key存在，什么事都不做，如果这个key不存在，和set命令一样）**

> setnx key value  
> 例如:setnx name zhangsan

**9.在key对应的value后，追加内容**

> append key value  
> 例如:append name san 结果name为：zhangsansan

**10.查看value字符串的长度**

> strlen key  
> 例如:strlen name

### 4.2、Key-Hash ###

存储的数据结构如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 2]

**1.存储数据**

> hset key field value

**2,获取数据**

> hget key field

**3 .批量操作**

> hmset key field value \[field value …\]  
> hmget key field \[field …\]

**4.自增（指定自增的值）**

> hincrby key field increment

**5.设置值（如果key-field不存在，那么就正常添加，如果存在，什么事都不做）**

> hsetnx key field value

**6.检查field是否存在**

> hexists key field

**7.删除key对应的field,可以删除多个**

> hdel key field \[field …\]

**8.获取当前hash结构中的全部field和value**

> hgetall key

**9.获取当前hash结构中的全部field**

> hkeys key

**10.获取当前hash结构中的全部value**

> hvals key

**11.获取当前hash结构中field的数量**

> hlen key

### 4.3、Key-List ###

存储的数据结构如下  
![在这里插入图片描述][2020082513341233.png_pic_center]

**1.存储数据（从左侧插入数据，从右侧插入数据）**

> Ipush key value \[value …\]  
> rpush key value \[value …\]

**2.存储数据（如果key不存在，什么事都不做，如果key存在，但是不是list结构，什么都不做）**

> Ipushx key value  
> rpushx key value

**3.修改数据（在存储数据时，指定好你的索引位置，覆盖之前索引位置的数据，index超出整个列表的长度，也会失败）**

> Iset key index value

**4 .弹栈方式获取数据（左侧弹出数据，从右侧弹出数据）**

> Ipop key  
> rpop key

**5.获取指定索引范围的数据（start从。开始，stop输入-1,代表最后一个，-2代表倒数第二个）**

> Irange key start stop

**6.获取指定索引位置的数据**

> lindex key index

**7.获取整个列表的长度**

> lien key

**8.删除列表中的数据（他是删除当前列表中的count个value值，count ＞。从左侧向右侧删除，count ＜。从右侧向左侧删除，count ==。删除列表中 全部的value）**

> Irem key count value

**9.保留列表中的数据（保留你指定索引范围内的数据，超过整个索引范围被移除掉）**

> Itrim key start stop

**10.将一个列表中最后的一个数据，插入到另外一个列表的头部位置**

> rpoplpush listl list2

### 4.4、Key-Set ###

存储的数据结构如下（无序不可以重复  
![在这里插入图片描述][20200825133627113.png_pic_center]

**1.存储数据**

> sadd key member \[member …\]

**2,获取数据（获取全部数据）**

> smembers key

**3.随机获取一个数据（获取的同时，移除数据，count默认为1,代表弹出数据的数量）**

> spop key \[count\]

**4.交集（取多个set集合交集）**

> sinter set1 set2

**5.并集（获取全部集合中的数据）**

> sunion set1 set2 …

**6.差集（获取多个集合中不一样的数据）**

> sdiff setl set2 …

**7.删除数据**

> srem key member \[member …\]

**8,查看当前的set集合中是否包含这个值**

> sismember key member

### 4.5、Key-Zset ###

**1.添加数据（score必须是数值。member不允许重复的。）**

> zadd key score member \[score member …\]

**2.修改member的分数（如果member是存在于key中的，正常增加分数，如果memeber不存在，这个命令就相当于zadd）**

> zincrby key increment member

**3.查看指定的member的分数**

> zscore key member

**4.获取zset中数据的数量**

> zcard key

**5.根据score的范围查询member数量**

> zcount key min max

**6.删除zset中的成员**

> zrem key member \[member…\]

**7.根据分数从小到大排序，获取指定范围内的数据（withscores如果添加这个参数，那么会返回member对应的分数）**

> zrange key start stop \[withscores\]

**8.根据分数从大到小排序，获取指定范围内的数据（withscores如果添加这个参数，那么会返回member对应的分数）**

> zrevrange key start stop \[withscores\]

**9.根据分数的返回去获取member（withscores代表同时返回score,添加limit,就和MySQL中一样，如果不希望等于min或者max的值被查询出来可以采 用’（分数’相当于 < 但是不等于的方式，最大值和最小值使用和-:Lnf来标识）**

> zrangebyscore key min max \[withscores\] \[limit offset count\]

**10.根据分数的返回去获取member（withscores代表同时返回score,添加limit,就和MySQL中一样）**

> zrangebyscore key max min \[withscores\] \[limit offset count\]

### 4.6、key的常用命令 ###

**1 .查看Redis中的全部的key （pattern： \* , xxx\*, \*xxx）**

> keys pattern

**2.查看某一个key是否存在（1 - key存在，0 - key不存在）**

> exists key

**3.删除key**

> del key \[key …\]

**4.设置key的生存时间，单位为秒，单位为毫秒，设置还能活多久**

> expire key second  
> pexpire key milliseconds

**5.设置key的生存时间，单位为秒，单位为毫秒，设置能活到什么时间点**

> expireat key timestamp  
> pexpireat key milliseconds

**6.查看key的剩余生存时间，单位为秒，单位为毫秒（-2 -当前key不存在，-1 -当前key没有设置生存时间，具体剩余的生存时间）**

> ttl key  
> pttl key

**7.移除key的生存时间（1 -移除成功，。- key不存在生存时间，key不存在）**

> persist key

**8.选择操作的库**

> select 。〜15

**9.移动key到另外一个库中**

> move key db

### 4.7、库的常用命令 ###

**1.清空当前所在的数据库**

> flushdb

**2.清空全部数据库**

> flushall

**3.查看当前数据库中有多少个**

> key dbsize

**4.查看最后一次操作的时间**

> lastsave

**5.实时监控Redis服务接收到的命令**

> monitor

## 五、Java连接Redis ##

[点击查看java连接redis][java_redis]

## 六、Redis的其他配置及集群 ##

### 6.1 Redis 的 AUTH ###

Redis的AUTH是Redis的一种密码校验方式，可以通过两种方式来开启Redis的AUTH功能

**方式一：通过修改Redis的配置文件，实现Redis的密码校验**

#redis.conf
    requirepass 密码

添加验证之后三种客户端的连接方式

*  redis-cli：在输入正常命令之前，先输入auth密码即可。
 *  图形化界面：在连接Redis的信息中添加上验证的密码。
 *  Jedis客户端：  
    jedis.auth(password);
 *  使用JedisPoo啲方式  
    //使用当前有参构造设置密码  
    public JedisPool(final GenericObjectPoolConfig poolConfig, final String host, int port,int timeout, final String password)

**方式二：在不修改redis.conf文件的前提下，在第一次链接Redis时，输入命令：Config set requirepass密码  
后续向再次操作Redis时，需要先AUTH做一下校验。**

### 6.2 面试官：Redis到底有没有事务 ？ ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 3]

在学习传统的关系型数据库的时候就一直听说Redis是不支持事务的，**但其实Redis是有自己的事务的，但是这个事务和mysql等数据库的事务不一样，不具备有ACID的特性**

**Redis的事务：一次事务操作，该成功的成功，该失败的失败。**

先幵启事务，执行一些列的命令，但是命令不会立即执行，会被放在一个队列中，如果你执行事务，那么这个队列中的命令全部执 行，如果取消了事务，一个队列中的命令全部作废。

使用事务的步骤：

*  1、开启事务：multi
 *  2、输入要执行的命令：被放入到一个队列中
 *  3、执行事务：exec
 *  4、取消事务：discard

Redis的事务想发挥功能，需要配置watch监听机制  
在幵启事务之前，先通过watch命令去监听一个或多个key,在开启事务之后，如果有其他客户端修改了我监听的key,事务会自动取 消。  
如果执行了事务，或者取消了事务，watch监听自动消除，一般不需要手动执行unwatcho

### 6.3、Redis的持久化机制 ###

**Redis的持久化机制有两种，分别是RDB和AOF**

**一、RDB持久化机制**

RDB是Redis默认的持久化机制，它根据一定时间内的操作变化来决定是否进行持久化

*  RDB持久化文件，速度比较快，而且存储的是一个二进制的文件，传输起来很方便。
 *  RDB持久化的时机：  
    save 900 1：在900秒内，有1个key改变了，就执行RDB持久化。  
    save 300 10：在300秒内，有10个key改变了，就执行RDB持久化。  
    save 60 10000：在60秒内，有10000个key改变了，就执行RDB持久化。
 *  RDB无法保证数据的绝对安全。

**RDB机制无法保证数据的绝对安全是因为这个机制不是实时将数据序列化到磁盘上的，如果在还没有持久化的时候服务器宕机的话就有可能会丢失数据**

**二、AOF持久化机制**

**AOF持久化机制默认是关闭的，Redis官方推荐同时开启RDB和AOF持久化，更安全，避免数据丢失。**

*  AOF持久化的速度，相对RDB较慢的，存储的是一个文本文件，到了后期文件会比较大，传输困难。
 *  AOF持久化时机。  
    appendfsync always：每执行一个写操作，立即持久化到AOF文件中，性能比较低。appendfsync everysec：每秒执行一次持久 化。appendfsync no：会根据你的操作系统不同，环境的不同，在一定时间内执行一次持久化。
 *  AOF相对RDB更安全，推荐同时幵启AOF和RDB。

**三、注意事项**

如果同时幵启了AOF和RDB持久化，那么在Redis宕机重启之后，需要加载一个持久化文件，优先选择AOF文件。  
如果先开启了RDB,再次开启AOF,如果RDB执行了持久化，那么RDB文件中的内容会被AOF覆盖掉。

### 6.4、Redis的主从架构 ###

单机版的Redis存在读写的瓶颈，一个Redis的服务器在面对高并发的时候也依然会可能存在宕机的风险，于是我们可以通过横向扩展，部署主从架构来缓解这个问题，**但是主从架构只能缓解读取数据的压力。**

主从架构图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 4]

配置文件yml

version: “3.1“
    services:
    redisl:
    image: daocloud.io/library/redis:5.0.7
    restart: always
    container_name: redisl
    environment:
    -TZ=Asia/Shanghai
    ports:
    -7001:6379
    volumes:
    -./conf/redisl.conf:/usr/local/redis/redis.conf command: ["redis-server","/usr/local/redis/redis.conf"] redis2:
    image: daocloud.io/library/redis:5.0.7
    restart: always
    container_name: redis2 environment:
    -TZ=Asia/Shanghai
    ports:
    -7002:6379
    volumes:
    -・/conf/redis2.conf:/usr/local/redis/redis.conf links:
    -redisl:master
    command: ["redis-server","/usr/local/redis/redis.conf"] redis3:
    image: daocloud.io/library/redis:5.0.7 restart: always
    container_name: redis3
    environment:
    -TZ=Asia/Shanghai
    ports:
    -7003:6379
    volumes:
    -./conf/redis3.conf:/usr/local/redis/redis.conf links:
    -redisl:master
    command: ["redis-server","/usr/local/redis/redis.conf"]
    # redis2和redis3从节点配置 replicaof master 6379

### 6.5、Redis的哨兵 ###

**哨兵可以帮助我们解决主从架构中的单点故障问题**

哨兵的大概意思就是在每一个主从架构的节点上添加一个哨兵，这些哨兵相互之间是会进行通讯的，大体框架图如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 5]  
比如Redis1这个主节点宕机了，这时候Redis1的哨兵就会将这个宕机的消息告诉其他的哨兵，然后哨兵之间就会进行一次投票，将从节点总数据最多的一个节点选为新的主节点，通过这个方式来保证这个主从架构的正常运行。

配置如下：

version: "3.1"
    services:
    redisl:
    image: daocloud.io/library/redis:5.0.7
    restart: always
    container.name: redisl
    environment:
    -TZ=Asia/Shanghai
    ports:
    -7001：6379
    volumes:
    -./conf/redisl.conf:/usr/local/redis/redis.conf
    -./conf/sentinell .conf :/data/sentinel.conf	# 添加的内容
    command: ["redis-server","/usr/local/redis/redis.conf"]
    redis2:
    image: daocloud.io/library/redis:5.0.7
    restart: always
    container.name: redis2
    environment:
    -TZ=Asia/Shanghai
    ports:
    -7002:6379
    volumes:
    -./conf/redis2.conf:/usr/local/redis/redis.conf
    -./conf/sentinel2. conf : /data/sentinel. conf	# 添加的内容
    links:
    -redisl:master
    command: ["redis-serverM"/usr/local/redis/redis.conf"]
    redis3:
    image: daocloud.io/library/redis:5.0.7
    restart: always
    container_name: redis3 environment:
    -TZ=Asia/Shanghai
    ports:
    -7003:6379
    volumes:
    -./conf/redis3.conf:/usr/local/redis/redis.conf
    -./conf/sentinel3.conf :/data/sentinel.conf	# 添加的内容
    links:
    -redisl:master
    command: ["redis-server","/usr/local/redis/redis.conf"]

准备哨兵的配置文件，并且在容器内部手动启动哨兵即可

#哨兵需要后台启动
    daemonize yes
    #指定Master节点的ip和端口 sentinel monitor master
    #指定Master节点的ip和端口 sentinel monitor master
    #哨兵每隔多久监听一次redis架构
    sentinel down-after-milliseconds mymaster 1G000
    在Redis容器内部启动sentinelBP可
    redis-sentinel sentinel.conf

### 6.6、Redis的集群 ###

Redis集群在保证主从加哨兵的基本功能之外，还能够提升Redis存储数据的能力。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 6]

1.  Redis集群是无中心的。
2.  Redis集群有一个ping-pang机制。（用于集群中各个节点相互通信，判断某个节点是否瘫痪）
3.  投票机制，Redis集群节点的数虽必须是2n + 1。
4.  Redis集群中默认分配了 16384个hash槽，在存储数据时，就会将key进行crc 16 的算法，并且对16384取余根据最终的结果，将key-valued放到指定Redis节点 中，而且每一个Redis集群都在维护看相应的hash槽.
5.  为了保证数据的安全性，每一个集群的节点，至少要跟着一个从节点。（改从节点平时只负责读取所连接节点的数据，在该节点宕机时起作用）
6.  单独的针对Redis集群中的某一个节点搭建主从。（如果某个节点存放这热点数据，可通过此方式提高读取效率）
7.  当Redis集群中，超过半数的节点岩机之后，Redis集群就瘫痪了

## 七、面试常问 ##

### 7.1、key的生存时间到了，Redis会立即删除吗？ ###

**不会立即删除。因为Redis的删除遵循两个删除机制**

*  定期删除：Redis每隔一段时间就去会去查看Redis设置了过期时间的key,会再100ms的间隔中默认查看3个key。
 *  惰性删除：如果当你去查询一个已经过了生存时间的key时，Redis会先查看当前key的生存时间，是否已经到了，直接删除当前 key,并且给用户返回一个空值。

### 7.2、Redis的淘汰机制 ###

**淘汰机制就是在Redis内存已经满的时候，如果添加了一个新的数据，这时候Redis就会根据淘汰机制在内存中删掉某一个数据，以此来为新数据提供存储空间。**

淘汰机制有以下8种。

*  volatile-lru：在内存不足时，Redis会再设置过了生存时间的key中干掉一个最近最少使用的key。
 *  allkeys-lru：在内存不足时，Redis会再全部的key中干掉一个最近最少使用的key。
 *  volatile-lfu：在内存不足时，Redis会再设置过了生存时间的key中干掉一个最近最少频次使用的key。
 *  allkeys-lfu：在内存不足时，Redis会再全部的key中干掉一个最近最少频次使用的key。
 *  volatile-random：在内存不足时，Redis会再设置过了生存时间的key中随机干掉一个。
 *  allkeys-random：在内存不足时，Redis会再全部的key中随机干掉一个。
 *  volatile-ttl：在内存不足时，Redis会再设置过了生存时间的key中干掉一个剩余生存时间最少的key。
 *  noeviction:（默认）在内存不足时，直接报错。

### 7.3、缓存常见问题 ###

#### 1、缓存穿透 ####

缓存穿透指的就是：请求缓存中不存在的数据，导致所有的请求都怼到数据库上，从而数据库连接异常。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 7]

**问题出现的原因：查询的数据，Redis中没有，数据库中也没有。**

**解决方案：**

*  1：根据id查询时，如果id是自増的，将id的最大值放到Redis中，在查询数据库之前，直接比较一下id。
 *  2：如果id不是整形，可以将全部的id放到set中，在用户查询之前，去set中查看一下是否有一个id。
 *  3：获取客户端的ip地址，可以将ip的访问添加限制（恶意攻击）。
 *  4：利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试
 *  5：采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。

#### 2、缓存击穿 ####

所谓缓存击穿是指一个热点数据一直在不停的被大量请求访问，某一个瞬间这个key失效了，于是大量的请求就穿破缓存，直接请求数据库，造成数据库瞬间崩溃。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 8]

问题：缓存中的热点数据，突然到期了，造成了大量的请求都去访问数据库，造成数据库宕机  
**解决方案**

*  1.在访问缓存中没有的时候，直接添加一个锁，限制请求数量，让几个请求去访问数据库，避免数据库宕机。
 *  2.热点数据的生存时间去掉。

#### 3、缓存雪崩（缓存失效） ####

缓存雪崩即Redis里同一时间大量缓存数据同时失效，这个时候依然有大量请求来访，结果请求都怼到数据库上，从而导致数据库宕机。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 9]

**问题原因：缓存同时到期**  
**解决方案：**

*  1、将缓存中的数据的有效时间在一定范围内随机，例如（30~60分钟）
 *  2、双缓存。设置两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点：  
    I 先从缓存A读数据，有则直接返回；  
    II A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程；  
    III 更新线程同时更新缓存A和缓存B。

#### 4、缓存倾斜 ####

在一个Redis集群中、某一个节点对应和hash槽的数据都是热点数据，导致大量的请求只访问同一个节点，导致该节点宕机

**解决方案**

*  1.扩展主从架构，搭建大量的从节点，缓解Redis的压力。
 *  2.可以在Tomcat中做JVM缓存，在查询Redis之前，先去查询Tomcat中的缓存。

[NoSQL]: https://blog.csdn.net/weixin_45680962/article/details/108152362
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/677a90aa0c794580bc7aadcb57e9ae72.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/b58ef43985374376a2a10d748a086024.png
[2020082513125534.png_pic_center]: /images/20221123/489b1415bc16463c9733ce9887e2c85a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/e5076a8235c14109b5a839827a1ecfbf.png
[2020082513341233.png_pic_center]: /images/20221123/e2d6063946d946ab9a20a32c5d4fb510.png
[20200825133627113.png_pic_center]: /images/20221123/cb9e0871d4c14a5d92df1b31d1d5540a.png
[java_redis]: https://blog.csdn.net/weixin_45680962/article/details/108227215
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/c538fcaf2a534d3799fec481b82f5d4e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/fd175adb5d4c419a938f91e40a73b3c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/326a5e08f5d844f38801c3293616697f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/ccd2f9ed496a49938e79337f1725cc58.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221123/a810560bc7f04639a90d3efc4e489992.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221123/45e8286ab6914415a078e5b5c73a80ef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221123/edd2562158cc422f9dd15c8b061d7196.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY4MDk2Mg_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221123/458f8ce7d4a44b8da25b518267978e34.png