Redis缓存穿透、击穿、雪崩及主从复制

最新推荐文章于 2024-09-21 11:30:16 发布

liangcheng0213

最新推荐文章于 2024-09-21 11:30:16 发布

阅读量111

点赞数

文章标签：数据库 redis

本文链接：https://blog.csdn.net/liangcheng0213/article/details/118971175

版权

本文详细介绍了Redis缓存中的穿透、击穿和雪崩问题及其解决方案。针对缓存穿透，提出了布隆过滤器和缓存空对象的策略；缓存击穿的解决方案包括热点数据永不过期和加互斥锁；缓存雪崩的处理方法涉及Redis高可用、限流降级和数据预热。此外，还探讨了Redis主从复制的配置和哨兵模式在故障恢复中的应用。

摘要由CSDN通过智能技术生成

Redis缓存穿透

查不到

概念

用户需要查询数据时，发现Redis中没有，也就是缓存没有命中，于是就向持久层数据库发起查询，发现也没有这个数据，于是本次查询失败。
当用户很多的时候，缓存都没有命中，又会请求数据库，就会给数据库带来很大的压力，这个就是缓存穿透
在这里插入图片描述

解决方案1-布隆过滤器

布隆过滤器是一种算法，是用户检测一个元素是否在一个集合中，存在一定的误差
在这里插入图片描述
可以将所有可能查询的参数以hash形式来进行存储，在控制层进行校验，不符合的则丢弃，从而避免对数据库的查询压力

解决方案2-缓存空对象

当存储层不命中时，及时返回一个空对象也将其缓存起来，同时会设置一个过期时间，之后在访问这个数据会从缓存中获取，既能保证数据的有效性也能保护后端数据库
在这里插入图片描述
注意：
即使对缓存设置了过期时间，还是会有缓存和数据库数据不一致的窗口期，对于需要保持一致性的业务会有影响

缓存击穿

量太大，缓存过期

概念

缓存击穿，指一个热门的key在不停的高并发访问，当这个key过期的瞬间，持续的高并发的请求就穿破了缓存，直接请求数据库当key在过期的瞬间，大量的请求并发访问，会同时访问数据库来处查询最新的数据，回写到缓存，会导致数据库瞬间压力过大

解决方案1-热点数据永不过期

热点数据在缓存时不设置过期时间，所以不会出现热点key过期后造成的数据库压力

解决方案2-加互斥锁

分布式锁的：使用分布式锁，保持对每个key同时只有一个线程去查询后端服务，其他的线程没有获取分布式锁的权限，只能等待。

缓存雪崩

概念

指在某一个时间段，缓存集中过期失效
集中过期，并不是致命问题，比较致命的是，是缓存服务器在某个节点宕机或者断网，一定的时间段内，数据库的压力聚增，对数据库的压力是不可预估的，很有可能就把数据库压宕机了

解决方案1-Redis高可用

单个Redis可能会挂点，多增设几台Redis，这样一台挂掉之后其他的也可以继续服务，就是搭建缓存服务器集群(异地多活)

解决方案2-限流降级

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

解决方案3-数据预热

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

Redis主从复制

简介

主从复制：指的是一个Redis服务器的数据，复制到其他的Redis服务器，前者称为主节点(mater/leader)后者称为从节点(slave/follower)，数据的复制是单向，只能从主节点到从节点，master以写为主，slave节点以读为主

默认情况，每台Redis服务器都是主节点，且一个主节点可以有多个从节点(或者没有从节点)，但是一个从节点只能有一个主节点
在这里插入图片描述
主从复制作用：
1、数据冗余：主从复制实现的数据的热备份，是持久化之外的一种数据冗余方式
2、故障恢复：当节点出现问题，可以从其他的节点提供数据服务，实现快速的故障恢复
3、负载均衡：在主从复制的基础上，配合读写分离，可以有主节点来提供写服务，由从节点提供读服务，分担服务器负载，可以提高Redis的并发量
4、高可用：主从复制还是哨兵和集群实现的基础，主从复制是高可用的基础

配置环境

配置环境主要配置从库，不需要配置主库
在这里插入图片描述
复制redis.conf配置文件，修改对应信息 slaveof host ip
1、端口号
2、pid文件名
3、dump.rdb名称

一主两从

默认的情况下，每台Redis服务器都是主节点，主要来配置从节点

两种模式

一个主机两个从机
在这里插入图片描述
链路模式

主机可以写，从机是可以读不能写，主机中的所有的信息和数据，都会保存到从机中

哨兵模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

概述

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
在这里插入图片描述

哨兵的作用

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

然而一个哨兵进程对Redis服务器进行监控，可能会出现哨兵宕机问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
在这里插入图片描述

故障切换的过程

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