【redis问题总结】

最新推荐文章于 2024-06-17 22:14:53 发布

沂蒙山旁的水

最新推荐文章于 2024-06-17 22:14:53 发布

阅读量77

点赞数

文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/qq123po/article/details/134683656

版权

redis问题总结

不论是开发中还是面试，redis都是最常见的，因此对redis的深入了解也有助于开发和面试

redis的使用场景

缓存
分布式锁
计数器
保存token
消息队列
延迟队列

缓存的问题

穿透，击穿，雪崩，双写一致性，持久化，数据过期，淘汰策略

分布式锁的问题

setnx，redisson

保存token，消息队列，延迟队列的问题

数据类型

其他的问题

集群（主从，哨兵，集群）
事务
redis为什么这么快

缓存穿透

查询一个不存在的数据，mysql查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库

例：一个GET请求：api/article/getById/-1
缓存穿透请求示例
此时通过url请求id为-1的文章，首先回到redis中请求，如果没有则到数据库中请求，此时数据库中也没有查询到数据，则不写入缓存返回为空，但如果有大量的这样的请求则可能会导致数据库的崩溃，此时就需要采取一些策略防止这样的情况发生。

方案一： 缓存空数据，查询返回的数据为空，扔把这个空结果进行缓存 {key:1,value:null}

优点：简单
缺点：消耗内存，可能发生不一致的问题
- 加入请求了一个id为99的文章，缓存和数据库都没有这条数据，做缓存空数据之后，数据库中添加了这条id为99的数据，这是如果再去请求id为99的数据因为缓存中设置了空数据，则直接从缓存中返回空数据，造成数据不一致的情况

方案二： 使用布隆过滤器

内存占用较少，没有多余的key
实现复杂，存在误判（这个误判是由于布隆过滤器的机制决定的）
布隆过滤器的原理简单介绍
- 布隆过滤器实质上就是一个位图
- bitmap(位图)：相当于是一个以（bit）位为单位的数组，数组中每个单元只能存储二进制数0或1
- 布隆过滤器作用：布隆过滤器可以用于检索一个元素是否存在一个集合中
  假如有一个Id1的数据查看是否存在，只需要三次hash这个id1然后到集合中相应的位置查看该位置是否都为1，如果都为1则表示id1存在，如果有一个不为1则表示不存在
  
  前面说过布隆过滤器存在误判的情况，下图展示了误判的情况
  
  误判率：数组越小误判率就越大，数组越大误判率就越小，但同时带来了更多的内存消耗

缓存击穿

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

解决方案
- 互斥锁
- 逻辑过期
互斥锁原理

当有两个线程同时发起请求的时候，假如线程一查询到数据过期然后获取到了互斥锁，那么线程一就去查询数据库并重建缓存数据，然后写数据到缓存，最后释放所，这时候在线程一还没有完成释放锁的过程的时候线程二也请求的缓存，并发现数据过期，这时候线程二尝试获取锁失败，则线程二会休眠一会再次尝试查询缓存，如果不中就继续尝试直到命中缓存返回数据

互斥锁原理解析
互斥锁特点：强一致，性能差

逻辑过期（不设置过期事件，只是设置一个逻辑过期的值）
{“id”:“123”,“value”:“逻辑过期”,“expire”:153489345}

加入有一个线程1去查询缓存，发现缓存逻辑过期，然后尝试获取互斥锁，如果获取锁成功，则开启一个新的线程，查询数据库重建缓存，线程1则返回过期的数据，新建的线程写入缓存成功后释放互斥锁，如果在线程1新开启的线程还未释放所资源时，线程二访问了缓存发现缓存逻辑过期，则线程二会尝试获取互斥锁，如果获取锁失败则返回过期的数据，如果线程三在线程1新开的线程释放了锁资源的情况下访问缓存，则线程三获取的就是最新的为过期的缓存数据。

逻辑过期流程图
逻辑过期的特点：高可用，性能优，数据有延迟不能保证数据绝对一致

缓存雪崩

缓存雪崩是指在同一时段大量的缓存key同时失效或者redis服务宕机，导致大量请求到达数据库，带来巨大压力。

缓雪崩示例图
解决方案：

给不同的key的TTL添加随机值
利用redis集群提高服务的可用性（哨兵模式，集群模式）
给缓存业务添加降级限流策略（nginx或Spring cloud gateway）
给业务添加多级缓存（Guava或者Caffeine）
注意：降级限流策略，穿透，击穿，雪崩都适用
《缓存三兄弟》
穿透无中生有key，布隆过滤null隔离。
缓存击穿过期key，锁与非期解难题。
雪崩大量过期key，过期时间要随机。
缓存问题三兄弟，降级限流是保底。

数据一致性

场景说明
- 先删除缓存或者先修改数据库
  
  从上图可只无论是先删除缓存还是先操作数据库总会出现数据不一致的情况。解决上面的这个问题可以有两种思路：一致性要求高的方案，允许延迟一致但要保证用户体验的方案。
双写一致性解决数据不一致问题

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

双写一致性流程示意图

读操作：缓存命中，直接返回；缓存未命中查询数据库，写入缓存，设定超时事件
写操作：延迟双删

之所以延迟删除缓存，是为了让数据库集群进行数据同步，删除两次是为了防止脏数据，注意即便这样做之后仍然有脏数据的风险。
分布式锁

分布式锁通过为错做缓存的线程加锁保障每次操作缓存的时候只有一个线程，这样就避免了脏数据的出现，但又因为锁的限制严重降低了系统的性能，因为每次只能有一个线程去处理缓存的写操作，其他的线程读数据的话只能等待写操作释放锁

分布式锁原理图
分布式锁适用于读多写少，要求强一致性的系统
总结：分布式锁具有强一致，低性能的特征

异步通知保证数据的最终一致性
- 适用MQ通知
- 基于Canal的异步通知：
  
  二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。

redis持久化

RDB - 快照模式
AOF

RDB(快照模式)

RDB也被叫做redis数据快照。简单俩说就是把内存中的所有数据都记录到此盘中。当redis实例发生故障重启后，从磁盘读取快照文件，恢复数据

 主动备份
 - 使用save和bgsave这两个命令执行RDB，
 - save 由redis主进程来执行RDB，会阻塞所有命令
 - bgsave 开启子进程执行RDB，避免主进程收到影

redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：
在这里插入图片描述

RDB执行原理

bgsave开始时会fork主进程到子进程，子进程共享主进程的数据。完成fork后读取内存数据并写入RDB文件。

fork采用的是copy-on-write技术：

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

AOF

AOF全称为Append Only File（追加文件）。redis处理的每一个写命令都会记录在AOF文件中，可以看作时命令日志文件

AOF默认是关闭的需=需要到redis.conf文件中手动开启

AOF的命令记录频率也可以通过配置文件进行配置

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

Redis也可以在触发阈值的情况下自动去重写AOF文件，阈值可以在redis.conf文件中配置
总结
RDB与AOF对比：
RDB和AOF各有自己的优缺点，如果对数据的安全性要求较高，在开发中往往结合两者同时使用

数据过期策略

假如redis的key过期后会立即删除吗？
Redis对数据设置的有效时间，数据过期以后，就需要将数据从内存删除掉。可以按照不同的规则进行删除，这种删除规则就被称为数据的删除策略（数据过期策略）。惰性删除、定期删除

惰性删除策略

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

每隔一段时间就会对一些key做过期检查，并删除过期的key（从数据库中取出一定数量的随机key进行检查，并删除其中过期的key）

定期清理有两种模式
- SLOW模式是定时任务，执行频率默认时10hz，每次不超过25ms，通过修改redis.conf的hz选项来调整这个次数
- FAST模式执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms
总结：
- **优点：**可以通过限制删除操作执行的时长和频率来减少删除操作对cpu的影响。另外定期删除，也能有效缓解过期key占用的内存
- **缺点：**难以确定操作执行的时长和频率
Redis的过期删除策略：惰性删除+定期删除这两种策略进行配合使用