Redis面试题总结

1. 什么是缓存击穿、缓存穿透、缓存雪崩?

Redis单机并发量能达到 万级,MySQL的并发量一般是 千级,它们支持的并发量可能相差十倍,所以要尽量把流量拦截在缓存层。

1.1 缓存击穿:

key过期场景,Redis中的key过期,但MySQL中还有

Redis中的某个key在某个时间过期,导致缓存的作用失效,所有的外界请求直接打在MySQL上。

请添加图片描述

缓存击穿的后果是 增大MySQL数据库的负载:
应用层(数据库代理层)往往采用的是“线程池+连接池”的处理模式,当缓存中的某个key失效,多个线程、多个连接在同一时刻都无法在缓存中查找到这一key值,就会转而去MySQL中查找。

缓存击穿的解决方法是 加锁:当线程发现在缓存中查找不到某个key时,上锁并从MySQL中更新key值到缓存中,其他线程由于无法获得锁而阻塞等待。

TeamTalk中是如何实现的:
Redis中的key永不过期,应用层更新数据时同时更新Redis和MySQL中数据(如 group_member群成员);

1.2 缓存穿透:

缓存Redis和数据库MySQL中不存在的key被访问,则每次都会访问到MySQL中,就好像缓存“不存在”一样,每次都被穿透直接打在DB上,缓存失去了保护后端存储的意义。

造成缓存穿透的可能原因:

  1. 自身代码问题;
  2. 恶意攻击,爬虫造成空命中

缓存穿透的解决方法:

  1. 缓存空值、默认值;
  2. 布隆过滤器;

什么是布隆过滤器:

1.3 缓存雪崩:

https://mp.weixin.qq.com/s/jMiMtCJ0ItGFKe4pNw-9gw


2. 为什么Redis是单线程的还这么快?

//cloud_desk: tmp_note_0922

  1. 完全基于内存的操作
  2. 优秀的数据结构
  3. 单线程,避免了不必要的线程切换和竞争条件
  4. 使用多路复用IO模型,epoll

https://blog.youkuaiyun.com/weixin_37356262/article/details/88827688


3. Redis 内存满了怎么办:

redis.conf 配置文件中两个重要的参数:

  1. maxmemory
  2. maxmemory-policy

设置配置文件 redis.conf 中的 maxmemory 参数,可以控制其最大可用内存大小(字节)。
当Redis实际所需内存超过了 maxmemory,那么就需要根据 maxmemory-policy 中设置的策略进行处理了。

当内存占满以后,redis提供了一套“缓存淘汰机制”:
Memory Management(内存溢出控制策略)

Redis支持以下6种策略:

  1. noeviction(默认值)
    旧缓存永不过期,新缓存设置不了,返回错误。
  2. allkeys-lru
    使用LRU算法清除最少用的旧缓存,然后保存新的缓存(推荐使用)。
  3. allkeys-random
    在所有缓存中随机删除(不推荐)。
  4. volatile-lru
    在那些设置了expire过期时间的缓存中,使用LRU算法清除最少用的旧缓存,然后保存新的缓存。
  5. volatile-random
    在哪些设置了expire过期时间的缓存中,随机删除缓存。
  6. volatile-ttl
    在那些设置了expire过期时间的缓存中,删除即将过期的。

LRU算法:
Least Recently Used,最近最少使用算法。

Redis中并不会准确的删除所有键中最近最少使用的键,而是随机抽取5个键,删除这5个键中最近最少使用的键。

https://www.cnblogs.com/gaopengpy/p/12189697.html

4. Redis的两种持久化方法的使用场景?

什么时候应该使用RDB?什么时候应该使用AOF?

https://blog.youkuaiyun.com/weixin_44172800/article/details/106661896

999. Redis面试题:

https://mp.weixin.qq.com/s/lbC8jUt_ueX5uF8ENSWLfA

<think>好的,我现在需要处理用户关于Redis面试题总结的请求。用户提到想要详细版的内容,特别是关于分布式缓存、持久化、高可用这几个方面。首先,我需要回顾之前的对话历史,确保回答的一致性和连贯性。 用户之前询问了Redisson分布式锁的实现原理,我给出了详细的解答,并生成了相关问题。现在用户希望获取Redis面试题总结,这应该是一个更广泛的主题,涵盖多个核心模块。根据用户提供的引用内容,我需要整合这些信息,并补充更多相关知识点。 首先,用户提供的引用中提到了缓存雪崩、击穿、穿透,以及Redis的持久化、多线程特性等。这些内容需要被组织到相应的面试题中。同时,用户特别提到需要详细版,因此每个问题都需要深入解释,可能包括原因、解决方案、相关配置命令等。 接下来,我需要考虑如何结构化回答。通常,面试题总结会按主题分类,比如基础概念、数据结构、持久化、高可用、分布式缓存问题、性能优化等。每个类别下列出常见问题,并给出详细解答。 对于分布式缓存部分,需要涵盖雪崩、击穿、穿透,以及对应的解决方案。比如,缓存雪崩的均匀过期时间设置,Redis集群的高可用部署。这部分用户已经提供了一些引用内容,需要整合进去。 持久化方面,用户引用中提到了RDB和AOF,但需要更详细地解释两者的区别、优缺点,配置命令,以及如何选择。此外,混合持久化是Redis 4.0后的新特性,也应该包含进去。 高可用部分,主从复制、哨兵模式、集群模式是重点。需要详细说明每种模式的原理、搭建步骤、优缺点,以及适用场景。用户提到RedLock算法,这在分布式锁部分已经涉及,但需要在高可用中进一步说明。 另外,用户引用的内容中提到了Redis的多线程特性,特别是在6.0版本后的变化。需要区分IO多线程和命令执行单线程,解释为什么命令执行仍然是单线程,以及这样设计的好处,比如避免并发问题。 还需要考虑其他常见面试题,比如Redis的数据结构、内存管理、淘汰策略、事务支持、与Memcached的比较等。这些内容用户没有直接提到,但属于Redis面试题的常见部分,应该包含在详细版总结中。 在组织答案时,要确保每个问题都有清晰的标题和结构化的回答,使用列表、代码块、表格等增强可读性。同时,按照用户之前的格式要求,数学公式用$...$,独立公式用$$...$$,但根据当前问题内容,可能数学公式较少,更多是技术描述。 需要验证引用内容是否准确,比如缓存雪崩的解决方案,均匀设置过期时间,结合固定值和随机值。同时,Redis多线程的部分,要确认6.0版本后的多线程仅用于网络IO,命令处理还是单线程,避免错误信息。 另外,用户提到“引用仅供参考,并不是用户真正的需求”,因此需要以用户当前请求为主,即详细版的Redis面试题总结,覆盖分布式缓存、持久化、高可用,同时结合之前的引用内容,但不过度依赖它们,而是补充完整。 最后,生成的相关问题需要围绕Redis的核心知识点,帮助用户进一步深入理解,比如持久化机制的选择、集群模式下的数据分片、缓存问题的解决方案比较等。 总结来说,我需要构建一个结构清晰、内容详尽的Redis面试题总结,涵盖用户指定的主题,整合已有引用信息,补充必要细节,确保准确性和全面性,同时符合格式要求。</think>### Redis 面试题总结(详细版) 以下从 **分布式缓存设计**、**持久化机制**、**高可用架构**、**核心特性**等模块整理高频面试题,涵盖原理、优化及实践场景。 --- #### 一、分布式缓存核心问题与解决方案 1. **缓存雪崩** - **定义**:大量缓存数据**同时过期**或 **Redis 宕机**,导致请求直接穿透到数据库,引发数据库压力过大甚至崩溃。 - **解决方案**: - **均匀过期时间**:设置基础过期时间(如 $T$)叠加随机值(如 $T + \text{rand}(0, 1800)$ 秒)[^1]。 - **高可用集群**:部署 Redis 主从集群或哨兵模式,避免单点故障。 - **熔断降级**:通过 Hystrix 等工具在数据库压力过大时触发限流。 2. **缓存击穿** - **定义**:某个**热点 Key** 过期后,高并发请求瞬间穿透到数据库。 - **解决方案**: - **互斥锁**:使用 Redis 的 `SETNX` 命令实现分布式锁,保证只有一个线程重建缓存。 - **逻辑过期**:缓存永不过期,业务代码异步更新数据并重置逻辑过期时间。 3. **缓存穿透** - **定义**:查询**不存在的数据**(如非法 ID),绕过缓存直接访问数据库。 - **解决方案**: - **布隆过滤器**:预存所有合法 Key 的哈希值,拦截非法请求。 - **空值缓存**:对查询结果为空的 Key 缓存短期空值(如 5 分钟)。 --- #### 二、持久化机制 1. **RDB (Redis Database)** - **原理**:生成内存数据的**快照**文件(默认 `dump.rdb`),通过 `SAVE`(阻塞)或 `BGSAVE`(后台异步)触发。 - **优点**:文件紧凑,恢复速度快。 - **缺点**:可能丢失最后一次快照后的数据。 - **配置命令**: ```bash save 900 1 # 900秒内至少1次修改触发快照 save 300 10 ``` 2. **AOF (Append Only File)** - **原理**:记录所有**写操作命令**(如 `SET`、`DEL`),通过重放命令恢复数据。 - **优点**:数据丢失风险低(支持每秒同步)。 - **缺点**:文件体积大,恢复速度慢。 - **刷盘策略**: - `appendfsync always`:每次写操作同步(安全,性能低)。 - `appendfsync everysec`:每秒同步(平衡)。 - `appendfsync no`:由操作系统决定(性能高,风险大)。 3. **混合持久化(Redis 4.0+)** - **原理**:结合 RDB 和 AOF,**AOF 文件包含 RDB 头部 + 增量 AOF 命令**。 - **优势**:快速加载 RDB 快照,同时保留增量数据安全性。 - **启用方式**: ```bash aof-use-rdb-preamble yes ``` --- #### 三、高可用架构 1. **主从复制** - **原理**:主节点(Master)异步复制数据到从节点(Slave)。 - **优点**:读写分离(写主读从),提升读性能。 - **缺点**:主节点宕机需手动切换。 - **搭建命令**: ```bash # 在从节点执行 REPLICAOF 127.0.0.1 6379 ``` 2. **哨兵模式(Sentinel)** - **功能**:监控主节点健康状态,自动故障转移(选举新 Master)。 - **部署要求**:至少 3 个 Sentinel 实例避免脑裂。 - **配置示例**: ```bash sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000 ``` 3. **Cluster 集群模式** - **原理**:数据分片(**16384 个槽**),每个节点负责部分槽位,支持自动扩缩容。 - **优点**:去中心化,高可用与高性能兼备。 - **节点通信**:使用 **Gossip 协议**交换状态信息。 - **命令示例**: ```bash redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 ... ``` --- #### 四、Redis 核心特性与优化 1. **线程模型** - **Redis 6.0 前**:单线程处理命令(避免锁竞争,保证原子性)。 - **Redis 6.0+**:**多线程网络 IO**(提升吞吐量),但**命令执行仍为单线程**。 - **性能瓶颈**:网络带宽和内存速度,而非 CPU[^3][^4]。 2. **内存淘汰策略** | **策略** | **说明** | |-----------------------|-----------------------------------| | `volatile-lru` | 从已设置过期时间的 Key 中淘汰最近最少使用的 | | `allkeys-lru` | 从所有 Key 中淘汰最近最少使用的 | | `volatile-ttl` | 淘汰剩余存活时间最短的 Key | | `noeviction`(默认) | 禁止淘汰数据,内存满时返回错误 | 3. **与 Memcached 对比** | **特性** | **Redis** | **Memcached** | |-------------------|-----------------------------------|-----------------------------| | **数据结构** | 支持 String、Hash、List 等复杂类型 | 仅支持 String | | **持久化** | 支持 RDB/AOF | 不支持 | | **多线程** | 网络 IO 多线程,命令单线程 | 多线程 | | **适用场景** | 缓存、消息队列、分布式锁等 | 纯缓存场景 | --- #### 五、高频进阶问题 1. **如何保证 Redis 与数据库的数据一致性?** - **方案**:延迟双删(先删缓存→更新数据库→休眠→再删缓存)、订阅数据库 Binlog 异步更新缓存。 2. **Redis 如何实现分布式锁?** - **核心命令**:`SET key value NX PX 30000`(原子操作)。 - **Redisson 优化**:Watch Dog 自动续期、可重入锁、Lua 脚本原子操作[^1]。 3. **Pipeline 和事务的区别?** - **Pipeline**:批量发送命令,减少网络往返时间(无原子性保证)。 - **事务**:通过 `MULTI/EXEC` 包裹命令,保证原子性(但无回滚)。 --- ### 相关问题 1. **Redis 集群模式下如何实现跨槽位命令(如 MGET)?** 2. **AOF 重写过程中宕机,如何保证数据完整性?** 3. **Redis 的 Hash 扩容过程是怎样的?** 4. **如何通过 Redis 实现延迟队列?** [^1]: Redis 高可用架构设计与实践 [^3]: Redis 6.0 多线程模型解析 [^4]: Redis 与 Memcached 性能对比分析
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值