Redis进阶学习

注:大部分内容为学习笔记,出处在此

为什么使用Redis

redis和memcached的区别
1.mc可以缓存图片和视频，rd除了k/v支持更多的数据结构、
2.rd可以使用虚拟内存，rd可持久化和aof容灾恢复，rd通过主从支持数据备份
3.rd可以做消息队列。

为什么高并发下有时单线程的 redis 比多线程的

mc 多线程模型引入了缓存一致性和锁，加锁带来了性能损耗。

Redis做消息队列

使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。 list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。

三种特殊的数据结构

Geospatial

这个数据结构专门用于存储地理位置

 #getadd添加地理位置，
 127.0.0.1:6379> geoadd china:city 116.40 39.90 beijing
 (integer) 1
 127.0.0.1:6379> geoadd china:city 121.47 31.23 shanghai
 (integer) 1
 127.0.0.1:6379> geoadd china:city 106.50 29.53 chongqi 114.05 22.52 shengzhen 
 (integer) 2
 #geodist 求两个地点的距离
 127.0.0.1:6379> GEODIST china:city beijing shanghai   [km|k|mi|ft] #可以选择单位
"1067378.7564"
#geopos获取定位，一定是一个坐标值
127.0.0.1:6379> GEOPOS china:city beijing
1) 1) "116.39999896287918"
   2) "39.900000091670925"

#georadius 寻找某个指定半径的
127.0.0.1:6379> GEORADIUS china:city 110 30 1000 km # 以110，30 这个经纬度为中心，寻 找方圆1000km内的城市
 1) "chongqi" 2) "xian" 3) "shengzhen" 4) "hangzhou"

127.0.0.1:6379> GEORADIUS china:city 110 30 500 km withdist  #显示与中心的距离
1) 1) "chongqi"
   2) "341.9374"

#显示与中心的距离加坐标定位+前两条记录
127.0.0.1:6379> GEORADIUS china:city 110 30 500 km withcoord withdist  count 2  
1) 1) "chongqi"
   2) "341.9374"
   3) 1) "106.49999767541885"
      2) "29.529999579006592"


#geohash 返回一个或多个位置元素的geohash表示
# 将二维的经纬度转换为一维的字符串，如果两个字符串越接近，那么则距离越近！ 
127.0.0.1:6379> geohash china:city beijing chongqi 
1) "wx4fbxxfke0" 2) "wm5xzrybty0"

GEO底层的实现原理其实就是Zset！我门可以使用Zset命令来操作geo

127.0.0.1:6379> zrange china:city 0 -1
1) "chongqi"
2) "shengzhen"
3) "shanghai"
4) "beijing"
127.0.0.1:6379> ZREM china:city beijing
(integer) 1
127.0.0.1:6379> zrange china:city 0 -1
1) "chongqi"
2) "shengzhen"
3) "shanghai"

Hyperloglog

Hyperloglog 基数统计的算法！主要用于基数统计。什么是基数，不重复的元素。有点类似于set，

#创建第一组元素
127.0.0.1:6379> PFADD userLatter a b c d e f g h i j
(integer) 1
#查看元素个数
127.0.0.1:6379> PFCOUNT userLatter
(integer) 10
#创建第二组元素
127.0.0.1:6379> pfadd userLatter2 i j z x c v b n m
(integer) 1
#查看元素个数
127.0.0.1:6379> pfcount userLatter2
(integer) 9
#合并两组元素到mergeUserLatter
127.0.0.1:6379> PFMERGE mergeUserLatter userLatter userLatter2
OK
#查看合并后的元素个数
127.0.0.1:6379> pfcount mergeUserLatter
(integer) 15

• 优点

占用的内存是固定，2^64 不同的元素的技术，只需要废 12KB内存！如果要从内存角度来比较的
话 Hyperloglog 首选！基数不大，数据量不大就用不上，会有点大材小用浪费空间，有局限性，就是只能统计基数数量，而没办法去知道具体的内容是什么。一般作统计使用。　统计注册 IP 数，统计每日访问 IP 数，统计页面实时 UV 数，统计在线用户数，统计用户每天搜索不同词条的个数。另外，有一定的错误率。0.81% 错误率！ 统计UV任务，可以忽略不计的！如果允许容错，那么一定可以使用 Hyperloglog ！，如果不允许容错，就使用 set 或者自己的数据类型即可。

Bitmap

bitmap位图，用二进制位来记录，只有0和1两种状态，比如统计用户一年内登录情况（每天的情况只有登录和未登录）
占用大小：365bit=46.x 字节 只占46个字节

假设以下未某用户一周的登录状态

127.0.0.1:6379> setbit user1:loginsatus 0 1
(integer) 0
127.0.0.1:6379> setbit user1:loginsatus 1 1
(integer) 0
127.0.0.1:6379> setbit user1:loginsatus 2 1
(integer) 0
127.0.0.1:6379> setbit user1:loginsatus 3 0
(integer) 0
127.0.0.1:6379> setbit user1:loginsatus 4 0
(integer) 0
127.0.0.1:6379> setbit user1:loginsatus 5 00
(integer) 0

#设置的值超过1bit
127.0.0.1:6379> setbit user1:loginsatus 5 44
(error) ERR bit is not an integer or out of range

127.0.0.1:6379> setbit user1:loginsatus 6 1
(integer) 0
127.0.0.1:6379> setbit user1:loginsatus 7 1
(integer) 0

#统计未值1的数量
127.0.0.1:6379> bitcount user1:loginsatus
(integer) 5

事务

Redis 事务本质：一组命令的集合！ 一个事务中的所有命令都会被序列化，在事务执行过程的中，会按照顺序执行！事务中的多个命令被一次性发送给服务器，而不是一条一条发送，这种方式被称为流水线，它可以减少客户端与服务器之间的网络通信次数从而提升性能。服务器在执行事务期间，不会改去执行其它客户端的命令请求。（排他性）Redis事务没有没有隔离级别的概念！ 事务不保证原子性！

#开启事务
127.0.0.1:6379> multi
OK
#排进队列
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
#退出事务
127.0.0.1:6379> exec
#各个命令执行结果
1) OK
2) OK
3) "v2"
4) OK

DISCARD # 取消事务

#编译型异常（代码有问题！ 命令有错！） ，事务中所有的命令都不会被执行！

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set aa bb
QUEUED

#命令错误
127.0.0.1:6379> settt aaa bbb
(error) ERR unknown command 'settt'
#结束事务
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.

#有错误，事务中的命令都未执行
127.0.0.1:6379> get aa
(nil)

运行时异常（1/0）， 如果事务队列中存在语法性，那么执行命令的时候，其他命令是可以正常执行
的，错误命令抛出异常！

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set aaa bbb
QUEUED
127.0.0.1:6379> incr aaa   #这条命令有错误 但是不妨碍其他错误
QUEUED
127.0.0.1:6379> set ooo  iii
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK

Watch

 flushdb  //清空数据库

乐观锁：

• 不上锁！ 更新数据的时候去判断一下，在此期间是否 有人修改过这个数据，
• 获取version
• 更新的时候比较 version
• 用watch来实现乐观锁

127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money # 监视 money 对象
OK
127.0.0.1:6379> multi # 事务正常结束，数据期间没有发生变动，这个时候就正常执行成功！
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY out 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20

127.0.0.1:6379> watch money # 监视 money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> DECRBY money 10
QUEUED
127.0.0.1:6379> INCRBY out 10
QUEUED
127.0.0.1:6379> exec # 执行之前，另外一个线程，修改了我们的值，这个时候，就会导致事务执行失败！
(nil)

Redis持久化

Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中
的数据库状态也会消失。所以 Redis 提供了持久化功能！

RDB

什么是RDB

主进程处理客户机的请求，主进程会fork创建一个子进程，子进程把内存数据写入一个临时文件中，也就是创建一个快照，快照写入完成后，替换掉原来的rdb文件，下次启动的时候，系统就会读取这个rdb文件。

优点：高性能，主进程不需要任何IO操作，而且读取rdb文件速度也比AOF要快。

缺点：最后一次持久化以后的数据可能会丢失。也就是创建了RDB文件以后，父进程又产生了新的数据，这部分数据就不在快照里面

触发机制

1、save的规则满足的情况下，会自动触发rdb规则
2、执行 flushall 命令，也会触发我们的rdb规则！
3、退出redis，也会产生 rdb 文件！
备份就自动生成一个 dump.rdb

适用场景

大规模的数据修复,数据的完整性要求不高.

缺点:fork进程的时候,会占用一定的内存空间,以及可能会有数据丢失

查看Redis运行状态

ps aux | grep redis-server

AOF

将我们的所有命令都记录下来,恢复的时候把这些命令都执行一遍.

以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

默认是不开启的，我们需要手动进行配置！我们只需要将 appendonly 改为yes就开启了 aof！重启，redis 就可以生效了！如果aof文件出错(比如中间被修改),可以修复这个aof文件.

redis 给我们提供了一个工具 redis-check-aof --fix

如果文件正常，重启就可以直接恢复了！

重写规则说明

aof 默认就是文件的无限追加，文件会越来越大！注意aof只会保存写命令,读操作不会影响数据,所以不保存

如果 aof 文件大于 64m，太大了！ fork一个新的进程来将我们的文件进行重写！

appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，
rdb完全够用！
appendfilename "appendonly.aof" # 持久化的文件的名字
# appendfsync always # 每次修改都会 sync。消耗性能
appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据！
# appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快！
# rewrite 重写，

优点：
1、每一次修改都同步，文件的完整会更加好！
2、每秒同步一次，可能会丢失一秒的数据
3、从不同步，效率最高的！
缺点：
1、相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢！
2、Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化！

扩展：
1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始
的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
4、同时开启两种持久化方式
在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
5、性能建议

• 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则
• 如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，**应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，**默认超过原大小100%大小重写可以改到适当的数值。
• 如果不Enable AOF ，仅靠 Master-Slave Repllcation (集群,主从机)实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉(主机和从机同时宕机)，会丢失十几分钟的数据**，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。**

Redis发布订阅

订阅端

127.0.0.1:6379> SUBSCRIBE yxhbilibili
Reading messages... (press Ctrl-C to quit)
1) "subscribe"   
2) "yxhbilibili"
3) (integer) 1
1) "message"       		#消息
2) "yxhbilibili"		#频道
3) "helloworld"			#消息具体内容

发送端

127.0.0.1:6379> publish yxhbilibili helloworld
(integer) 1

实现原理

通过 SUBSCRIBE 命令订阅某频道后，redis-server 里维护了一个字典，字典的键就是一个个 频道！而字典的值则是一个链表，链表中保存了所有订阅这个 channel 的客户端。SUBSCRIBE 命令的关键，就是将客户端添加到给定 channel 的订阅链表中。

通过 PUBLISH 命令向订阅者发送消息，redis-server 会使用给定的频道作为键，在它所维护的 channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。

使用场景

• 实时聊天\消息系统
• 订阅关注系统

比较复杂的场景会使用消息中间件 kafka或者rabbitmq

Redis主从复制

作用

提高性能,提高并发,读写分离,主节点提供写服务,从节点提供写服务

增加容错,从节点从另一个角度来说也实现了数据备份,在主节点故障时,从节点还能继续使用

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的（宕机），原因如下：
1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"。
对于这种场景，我们可以使如下这种架构：

环境配置

只配置从库，不用配置主库。

复制3个配置文件，然后修改对应的信息
1、端口
2、pid 名字
3、log文件名字
4、dump.rdb 名字
修改完毕之后，启动我们的3个redis服务器，可以通过进程信息查看！

运行服务器 ./redis-server /etc/redis/6383.conf #（运行server加指定配置文件）

运行客户端 ./redis-cli -p 6379 #指定端口

127.0.0.1:6382> slaveof 127.0.0.1 6379  #配置从机所属主机
OK
127.0.0.1:6382> info replication         #查看信息
# Replication
role:slave							#角色 从机
master_host:127.0.0.1				
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:28
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:c797d21b7071f6f5b0558d77e5f6301b79cbb5d7
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:28
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:28
127.0.0.1:6382> 

主机信息：

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:3
slave0:ip=127.0.0.1,port=6380,state=online,offset=224,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=224,lag=0
slave2:ip=127.0.0.1,port=6382,state=online,offset=224,lag=1
master_replid:c797d21b7071f6f5b0558d77e5f6301b79cbb5d7
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:238
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:238
127.0.0.1:6379> 

注意：真实的从主配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，暂时的！

细节

主机可以写，从机不能写只能读，主机中所有的信息和数据，都会自动被从机保存。主机断开连接后，又重新连接，这时写入的数据从机仍能够得到。而通过命令行配置的主从，从机重启后，就会变回主机，重新配置为从机后，又会重新获取主机的值。

127.0.0.1:6380> set k1 v1
(error) READONLY You can't write against a read only replica.
#从机写入失败

复制原理

Slave 启动成功连接到 master 后会发送一个sync同步命令
Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行
完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master 继续将新的所有收集到的修改命令依次传给slave，完成同步
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行！ 我们的数据一定可以在从机中看到！

特殊结构

这种也是可以的，但是80此时是从节点

“谋朝篡位”

如果上图79断开连接，我们可以使用slaveof no one 80就会变成81的主节点。

127.0.0.1:6380> slaveof no one
OK
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=402,lag=1
master_replid:d85905ca19c43c4a2cf1f59c986e4477829bfbdc
master_replid2:3c9606628943ed04f95024ec1cdc0d9139c7c983
master_repl_offset:402
second_repl_offset:403
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:402

哨兵模式

（自动选举老大的模式）

哨兵模式是一种特殊的模式，用于选择监控redis节点，可以在主节点宕机后选择新的主节点。首先redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程他会单独运行。其原理是哨兵通过发送命令，等待redis服务器相应，从而监控运行的redis实例。

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

上面的话简而言之就是：只有当多个服务器同时监测到主服务器断开连接后，哨兵之间就会发起选择主节点的投票，并通过订阅模式，让哨兵监控的节点实现主机切换，这个成为客观下线。只有一个哨兵认为服务器不可用成为主观下线。

补充：通常一个哨兵，当哨兵也断开连接后，效果可能就不稳定，通常采用多个哨兵互相监控

演示

1. 配置哨兵的配置文件 sentinel

   [root@hecs-x-medium-2-linux-20200503121820 bin]# cd /etc/redis
   [root@hecs-x-medium-2-linux-20200503121820 redis]# vim sentinel.conf
   
   

# 配置监听的主服务器，这里sentinel monitor代表监控，mymaster代表服务器的名称，可以自定义，192.168.11.128代表监控的主服务器，6379代表端口，2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定义服务的密码，mymaster是服务名称，123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

2. ​ 启动哨兵进程

   [root@hecs-x-medium-2-linux-20200503121820 bin]# ./redis-sentinel /etc/redis/sentinel.conf 
   

3. 断开主节点

   127.0.0.1:6379> shutdown
   not connected> 
   

4. 等待一段时间，6380从节点变成了主节点

127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=10480,lag=0
master_replid:d85905ca19c43c4a2cf1f59c986e4477829bfbdc
master_replid2:3c9606628943ed04f95024ec1cdc0d9139c7c983
master_repl_offset:10480
second_repl_offset:403
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:10480
127.0.0.1:6380> 

5. 当6379重新连接后，也只能为从节点，只能归并到新的主机下，当做从机，这就是哨兵模式的规则！

补充：监控从节点是为了从从节点中选出表现良好的担任主节点

优点

主从模式的升级，提高系统可用性和健壮性，提高可用性，主从机可以切换，故障可以转移。

缺点

redis不好在线扩容，集群容量一旦达到上限，在线扩容十分麻烦，配置比较繁琐

缓存穿透(查不到)

缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中（比如秒杀系统），于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

解决方法

布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力.

通俗解释：就是进入redis查询之前，布隆过滤器把所有可能查询的值都以hash的形式存储起来，如果没有这次查询的hash值，就丢弃这次查询。减少服务器压力。

缓存空对象

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源；通俗解释:没有的值我设置一定时间内用一个空对象返回。

存在的问题：可能会缓存很多无意义的key，同时有可能数据库里有这个key，却没有转发，直接返回了null。

缓存击穿（量太大，缓存过期！）

某个key很多很多次查询，并发十分大，当key失效的瞬间，大并发瞬间就穿破缓存，直接请求数据库，就像在redis层凿开一个洞，所以叫缓存击穿。

解决方案

设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现热点 key 过期后产生的问题。（一般并发量不是非常大的，提前设置热点key不过期就够用了）

加互斥锁

分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

10分钟搞懂分布式锁，程序员进阶之路

大家都知道，如果我们一台机器上多个不同线程抢占同一个资源，并且如果多次执行会有异常，我们称之为非线程安全。一般，我们为了解决这种问题，通常使用锁来解决，像java语言，我们可以使用synchronized。如果是同一台机器里面不同的java实例，我们可以使用系统的文件读写锁来解决，如果再扩展到不同的机器呢？我们通常用分布式锁来解决。

缓存雪崩

缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis 宕机！缓存雪崩是指，缓存层出现了错误，不能正常工作了。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

热点key过期，或者服务器宕机都有可能导致缓存雪崩

解决方案

1. redis高可用

   这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。（异地多活！）。 总结:搭建集群，异地多群redis

2. 限流降级

   在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。(也就是控制进入数据库的线程)

3. 数据预热

   正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

   总结：比如双十一抢购开始前，测试数据，提前载入缓存，设置不同的过期时间，让缓存失效的时间点尽量均匀。（不要同一时间失效）