Java面试-Redis

系统管理员 2024-03-16 19:20 8阅读 0赞

#### Java面试-Redis ####

*  redis 是什么
 *  redis 的基本数据结构有哪些
 *  redis为什么这么快
 *  什么是缓存穿透，如何解决
 *  什么是缓存击穿，如何解决
 *  什么是缓存雪崩，如何解决
 *  什么是热key问题，如何解决
 *  redis过期数据的删除原则
 *  redis的缓存淘汰的策略
 *  redis的持久化机制有哪些，优缺点是什么
 *  redis 是怎么实现高可用的
 *  Redis和Mysql如何保证数据一致性

## redis 是什么 ##

*  redis是一款基于内存的，使用K-V结构存储数据的NoSQL非关系型数据库
 *  redis的核心价值在于，提高查询效率，保护关系型数据库

## redis 的基本数据结构有哪些 ##

*  String（字符串）：以字符串形式储存数据，常用于用户访问次数，文章访问量
 *  hash（哈希）：以对象的形式进行储存，比较方便的是操作对象中的某个字段，用于缓存用户信息
 *  List（列表）：以列表的形式进行储存，有添加顺序，允许重复，用于消息队列，文章列表
 *  Set（集合）：以集合的形式进行储存，无添加顺序，不允许重复，也不保证储存顺序，用于用户标签，生成随机数抽奖，社交需求（共同好友）
 *  Zset（有序集合）：可对数据基于某个权重进行排序，例如排行榜，社交需求（用户点赞）

## redis为什么这么快 ##

*  基于内存存储实现
 *  高效的数据结构
 *  单线程，IO多路复用
 *  虚拟内存机制

## 什么是缓存穿透，如何解决 ##

*  就是一个业务请求先查询redis，redis没有，然后向数据库查询，数据库也没有的情况叫缓存穿透
 *  解决方案
    
     *  接口校验：直接在最外层先做一层校验，用户鉴权、数据合法性校验等，例如商品查询中，商品的ID为正整数，对于非整数的访问直接过滤掉
     *  缓存空值：当访问缓存和数据库都没有查询到值，可以将这个空值写入缓存，但是需要设置一个较短的过期时间，具体的时间需要根据产品业务的特性来设置
     *  布隆过滤器：就所有可能访问的key先提前从数据库查询出来保存到布隆过滤器中，查询的时候，不存在的key直接过滤掉，存在的key再进一步查询缓存和数据库
     *  注意：布隆过滤器存在误判，布隆过滤器中不存在的key，缓存和数据库则一定没有，布隆过滤器存在的key，缓存和数据库不一定有

## 什么是缓存击穿，如何解决 ##

*  一个业务请求先查询redis，redis没有或已过期，然后向数据库查询，数据库有的情况叫缓存击穿
 *  解决方法
    
     *  提前预设热门数据缓存
     *  实时调整过期时间，自动续期
     *  使用锁，缓存数据不存在时，将数据库数据放入缓存

## 什么是缓存雪崩，如何解决 ##

*  redis中大量缓存集中在某一个时间段过期，造成数据库访问量大，压力骤增，系统崩溃的情况叫缓存雪崩
 *  解决方案  
    将数据保存到redis中时在固定的过期时间上加上一个随机数，这样避免在某一个时间段内大量数据同时到期

## 什么是热key问题，如何解决 ##

*  访问频率高的key叫热key
 *  产生热key问题的场景
    
     *  用户消费的数据远远大于生产的数据，如秒杀、热点新闻访问等读多写少的问题
 *  解决方案
    
     *  将热key分散到不同的服务器中
     *  使用本地缓存，减少redis的访问

## redis过期数据的删除原则 ##

*  惰性删除，在查询时，检测到key过期了，将这个key进行删除，缺点是：这个key长期不访问，那么这个key将不会被访问
 *  定期删除，定期检查redis中的数据，检测到key过期了,进行删除，缺点是：并不会检测所有的key，只是随机抽取一部分key进行检测是否过期，过期了就删除

## redis的缓存淘汰的策略 ##

如果redis中的内存已全满时，还需要向redis中保存数据，如何操作，就叫缓存淘汰策略

*  noeviction：返回错误 **（默认）**
 *  allkeys-random：从所有key中随机删除key
 *  volatile-random：从设置过期时间的所有key中随机删除key
 *  allkeys-lru：从所有key中删除上次使用距离现在使用最久的key
 *  volatile-lru：从设置过期时间的所有key中删除上次使用距离现在最久的key
 *  allkeys-lfu：从所有key中删除使用频率最低的key
 *  volatile-lfu：从设置过期时间的所有key中删除使用频率最低的key

## redis的持久化机制有哪些，优缺点是什么 ##

*  RDB：是redis数据库默认的持久化方式，本质是以数据快照（将redis中的数据以二进制数据）的形式保存到磁盘的文件里，对应的数据文件是dump.rdb
    
     *  优点：因为是整体redis数据的二进制格式，所以数据恢复是整体的，恢复速度快，适合大规模的数据恢复场景，如备份，全量复制等
     *  缺点：redis断电，只能恢复到最后一次dump.rdb文件里的数据，即没办法做到实时持久化
 *  AOF：将redis运行过程中的命令（日志）备份下来，保存到磁盘里，即使redis断电，也能根据运行日志恢复数据
    
     *  优点：相对于RDB，信息丢失较少，数据的一致性和完整性更高
     *  缺点：因为保存的redis运行的日志，所以占用空间比较大，数据恢复慢
 *  redis官方建议使用RDB+AOF混合模式
    
     *  优点
        
        1.  实时持久化，避免丢失数据
        2.  使用RDB批量快速恢复数据，使用AOF恢复增量数据

## redis 是怎么实现高可用的 ##

*  主从复制：主机负责读写操作，从机用作备用，主机新增数据，会自动复制到从机，主机出现故障，使用从机
    
     *  缺点：主机没有出现故障，从机就没有用处，浪费资源，主机出现故障，需要人工介入切换到从机，需要时间
 *  读写分离：主机负责读写操作，从机负责读操作，主机新增数据，会自动复制到从机，主机出现故障，使用从机
    
     *  优点：从机可以分担一部分主机的工作，减轻主机的压力
     *  缺点：主机出现故障时，需要人工介入切换到从机，需要时间
 *  哨兵模式：哨兵节点（Sentinel）会每隔固定的时间向所有节点请求，如果请求正常响应，认为节点正常，请求没有回应，认为该节点不正常，哨兵（sentinel）自动切换主从机
    
     *  优点：主机出现故障，会自动切换到从机
     *  缺点：哨兵（sentinel）会出现误判的情况，如果误判导致主机下线，会降低整体的运行性能
 *  哨兵集群：将哨兵做成集群，有多个哨兵监测主从机的运行状态，哨兵集群中的每个哨兵都会每个固定时间向所有节点发送ping（心跳）监测节点的健康状态，哨兵集群半数以上的哨兵（sentinel）节点都没有收到回应，则判断该节点下线，实现主从机切换
    
     *  优点：主从机出现故障，会自动切换，减少误判情况
     *  缺点：业务增多，并发情况下，系统性能降低
 *  分片集群：在高并发情况下，一个节点无法满足系统的性能要求，所以有多个节点，每个节点负责的区域不一样，分片就是每个节点负责不同的区域，这样来满足系统的性能要求
    
     *  特征
        
         *  集群中有多个主机（master）,每个主机（master）都可以有多个save（从机）
         *  每个主机（master）储存不同的数据
         *  主机（master）之间通过 ping （心跳）监测彼此的健康状态
         *  客服端请求可以访问任意节点，最终都会转发到正确的节点  
            ![在这里插入图片描述][86b66b844d4f4299a86959893918623f.png]

## Redis和Mysql如何保证数据一致性 ##

一般情况下，redis是用来实现应用和数据库之间的一个 读操作的缓存层，主要目的是减少数据库的IO，还可以提升数据库的IO性能，当应用程序需要去读取某个数据的时候，首先会去尝试加载redis中的数据，如果命中了直接返回数据，如果没有命中，就直接从数据库中进行查询，查询到数据之后，再将数据保存到redis中，这样就会出现一个问题，一份数据同时保存在redis和数据库中，当数据库发生变化的时候，需要同时去更新数据库和redis中的数据，由于更新操作是由先后顺序的，并不像Mysql中的多表事务操作，可以满足事务的ACID的特性，所以就出现了数据一致性的问题

*  先更新数据库，再更新redis：先更新数据库再更新redis，如果缓存更新失败，就会导致数据库和redis中的数据是不一致的  
    ![在这里插入图片描述][aa8c928310494470829e23b048cea365.png]
 *  先删除redis，再更新数据库：先删除redis，再更新数据库，理想情况下，是应用下次访问redis的时候，发现redis里面的数据是空的，那么就会从数据库中加载，保存到redis中，也就是说数据库从理论上是一致的，但是由于删除redis和更新数据库的操作都不是原子操作，如果删除了redis中的数据，但是在数据库更新之前后其他的线程进行查询，redis就会从数据库中查询到旧的数据保存到redis中，导致之后数据库更新后redis和数据库数据依旧不一致  
    ![在这里插入图片描述][1e1feb59aba3405697aa425a96174967.png]
 *  延时双删：先删除redis，然后更新数据库，然后休眠1s（根据具体业务合理设置，比如几百毫秒），再删除redis，第二次删除可能出现删除数据失败，导致出现数据不一致问题  
    延时删除的原因：是因为更新数据库后，查询数据保存到数据库中需要一定的时间，这个时候还没有将数据保存到redis中，这个时候去删除redis，会出现redis的数据删不掉的问题，延时时间，就是保住将查询到的数据保存到redis之后，再进行删除，保住删除掉redis中的数据  
    ![在这里插入图片描述][1bb0d24dc87a482295152f47cae32f74.png]
 *  最终一致性方案：如果需要在极端情况下，任然去保证redis和MySQL的数据一致性就只能采用最终一致性方案，比如基于MQ的可高性消息通信，来实现最终一致性，还可以通过Cancal组件，监控MySQL中的binlog的日志，把更新后数据同步到redis里面，因为是基于最终一致性来实现的，如果业务场景不能接受数据的短期不一致性，那么就不能使用这样的一个方案来实现  
    ![在这里插入图片描述][33c295d90e014193ab25ba1580c283a1.png]  
    ![在这里插入图片描述][4c611c75188f4df5bf85403746ad2cf5.png]

[86b66b844d4f4299a86959893918623f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/e3a1cdaec3d9455d9eb7718dfcc0199c.png
[aa8c928310494470829e23b048cea365.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/d1f3c457f010484e98e8183b2803a47e.png
[1e1feb59aba3405697aa425a96174967.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/9e48dc971f64467fa8f54a5435719fa9.png
[1bb0d24dc87a482295152f47cae32f74.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/00bbee3788154c16b815d650bb691fa8.png
[33c295d90e014193ab25ba1580c283a1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/c8a84370d66c40459b9e7f9347568ee2.png
[4c611c75188f4df5bf85403746ad2cf5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/2e2d3973e88c47a38e460018459e6e7c.png