redis面试资料超全整理，准备面试的小伙伴们别错过了

Redis面试资料超全整理

Redis到底是什么？它能干什么？ （来源：多数面试文章开篇介绍） Redis全称是Remote Dictionary Server，翻译过来是远程字典服务，你可以把它理解成一个速度超级快、功能挺多的“大Map”或者“键值对缓存”，但它又不仅仅是缓存，它把所有数据都放在内存里操作，所以读写速度极快，常用于解决高并发、高性能的场景，主要干这些事：

1. 缓存：这是最常用的，把经常查询的数据库结果放进去，减轻数据库压力，加快网站速度。
2. 排行榜：利用它的有序集合（Zset）能轻松实现实时更新的排行榜。
3. 计数器：比如文章的点赞数、阅读量，因为Redis命令是单线程原子性的，不会出错。
4. 消息队列：虽然不如专业的RabbitMQ、Kafka，但它的List结构可以简单实现队列功能。
5. 会话缓存：把用户登录后的Session信息存到Redis里，实现分布式系统的会话共享。

为什么Redis这么快？ （来源：几乎所有面试文章的核心考点） 这个问题是必问的，速度快的原因可以总结为以下几点：

1. 基于内存：数据都存在内存里，读写操作直接对内存进行，避免了磁盘I/O的慢速瓶颈，这是最根本的原因。
2. 单线程模型：Redis的核心网络模型是单线程的（指处理命令请求的模块），这样避免了多线程的上下文切换和竞争条件带来的开销，也不用考虑各种锁的问题，注意，Redis 6.0之后引入了多线程处理网络I/O，但执行命令的核心部分仍然是单线程。
3. 高效的数据结构：Redis自己实现了一套精炼高效的数据结构，比如简单动态字符串（SDS）、跳跃表等，这些结构都是为了性能而优化的。
4. I/O多路复用：使用epoll这样的机制，让单个线程能高效地处理大量的网络连接请求。

Redis的数据类型有哪些？分别用在什么场景？ （来源：面试基础题高频汇总） 千万别只说String、List、Set、Zset、Hash这五个基本类型，现在面试官喜欢问更细的。

• String（字符串）：最基础的类型，可以存字符串、整数、浮点数，常用作缓存、计数器（比如incr命令）。
• List（列表）：一个双向链表，可以用来做消息队列（lpush/rpop）、最新消息排行（比如朋友圈时间线lpush+ltrim）。
• Hash（哈希）：类似Java里的Map，是字段和值的映射表，特别适合存储对象，比如把一个用户的信息（姓名、年龄、城市）存成一个Hash，比把每个字段拆成单独的String要高效。
• Set（集合）：无序且元素唯一的集合，可以用来做共同关注（求交集sinter）、好友推荐（求差集sdiff）、随机抽奖（srandmember）。
• Zset（有序集合）：带分数的Set，元素按分数排序，这是Redis的特色数据结构，排行榜（zrevrange）、带权重的消息队列都靠它。
• Bitmaps（位图）：本质是String，但可以对位进行操作，适合做大量数据的布尔统计，比如用户签到记录（每天签到位图setbit）、活跃用户统计。
• HyperLogLog：用来做基数统计的，就是估算一个集合中不重复元素的个数，比如统计一个页面的UV（独立访客），有微小的误差，但占用空间极小。
• Geospatial（地理空间）：可以存储地理位置信息，并进行距离计算、范围查找等，附近的人”功能。

Redis的持久化机制是怎么回事？ （来源：面试重点考察的可靠性问题） 因为数据都在内存里，断电就没了，所以需要持久化到硬盘上，Redis提供了两种方式：

1. RDB（快照）：在指定的时间间隔内，将内存中的数据生成一个快照文件（dump.rdb）保存到磁盘，就像是给数据拍一张完整的照片。
   • 优点：文件紧凑，恢复大数据集速度非常快，适合做灾难恢复。
   • 缺点：可能会丢失最后一次快照之后的数据（比如5分钟备份一次，服务器在第4分钟宕机，就会丢失4分钟的数据），创建快照时，如果数据量大，会占用较多资源。
2. AOF（追加文件）：把每一个写命令都记录到一个日志文件里，当Redis重启时，会重新执行AOF文件中的所有命令来恢复数据，就像是记流水账。
   • 优点：数据安全性高，最多丢失1秒的数据（如果配置为每秒同步一次），AOF文件易读，可以手动修改。
   • 缺点：文件通常比RDB大，恢复速度比RDB慢。
   • AOF重写：因为AOF文件会越来越大，Redis提供了重写机制，会创建一个新的AOF文件，包含恢复当前数据集所需的最小命令集合。

生产环境中通常两者结合使用，用AOF来保证数据不丢失，用RDB来做冷备和快速恢复。

缓存穿透、缓存击穿、缓存雪崩是什么？怎么解决？ （来源：面试高频实战问题） 这是考察缓存使用中经典问题的解决方案。

1. 缓存穿透：指查询一个根本不存在的数据，缓存和数据库都没有，但请求会一直打到数据库上，就像穿透了缓存。

   • 解决：
     • 接口校验：对请求参数做基础校验，比如id<=0的直接拦截。
     • 缓存空对象：即使数据库没查到，也把一个空值（比如null）缓存起来，并设置一个较短的过期时间，下次请求就直接返回空了。
     • 布隆过滤器（Bloom Filter）：在缓存之前加一层布隆过滤器，它能快速判断一个元素“一定不存在”或“可能存在”于集合中，把所有可能存在的key放到布隆过滤器里，请求来时先在这里判断，一定不存在”就直接返回，保护后端。

2. 缓存击穿：指一个热点key在过期瞬间，大量请求同时过来，导致所有请求都击穿缓存，直接访问数据库。

   • 解决：
     • 设置热点数据永不过期。
     • 加互斥锁：第一个请求发现缓存失效后，去查数据库并重建缓存时，给这个key加锁（比如用Redis的setnx命令），其他请求等待，等缓存重建好后直接读缓存。

3. 缓存雪崩：指缓存中大量key在同一时间过期，或者Redis服务宕机，导致所有请求都涌向数据库，造成数据库压力过大甚至宕机。

   

   • 解决：
     • 给过期时间加随机值：避免大量key同时过期，比如基础过期时间+一个随机几分钟。
     • Redis高可用：搭建Redis集群（如哨兵模式、集群模式），防止单点故障导致整个缓存服务不可用。
     • 服务降级和熔断：在数据库压力过大时，对非核心业务数据直接返回预定义默认值，保护数据库。

Redis如何实现分布式锁？ （来源：面试常见分布式问题） 在分布式系统里，要控制多个服务对共享资源的访问，需要用分布式锁，Redis常用setnx命令实现。

• 基本命令：SET lock_key random_value NX PX 30000
  • NX：表示只有当key不存在时才能设置成功，这相当于获取锁。
  • PX 30000：给锁设置一个30秒的过期时间，防止持有锁的服务宕机导致锁永远无法释放。
  • random_value：要设置一个随机值（如UUID），在释放锁时要验证这个值，只能释放自己加的锁，避免误删别人的锁。
• 释放锁：需要先用GET判断值是否是自己设置的，如果是，再用DEL删除，但这不是原子操作，最好用Lua脚本保证原子性。

Redis的内存用完了会怎样？ （来源：面试内存管理问题） 这取决于设置的淘汰策略（maxmemory-policy），当内存使用达到上限时，Redis有几种处理方式：

• noeviction（默认）：新写入操作会报错，这是生产环境最常用的。
• allkeys-lru：在所有key中，移除最近最少使用的key。
• volatile-lru：在设置了过期时间的key中，移除最近最少使用的key。
• allkeys-random：在所有key中，随机移除某个key。
• volatile-random：在设置了过期时间的key中，随机移除某个key。
• volatile-ttl：在设置了过期时间的key中，移除即将过期的key。

什么是Redis事务？ （来源：面试基础概念） Redis事务是一组命令的集合，所有命令会被序列化，按顺序执行，但Redis事务不保证原子性，即中间有命令失败，后面的命令依然会执行，且没有回滚机制，它通过MULTI（开始事务）、EXEC（执行事务）等命令实现。

如何保证缓存和数据库的双写一致性？ （来源：面试高阶问题） 当更新数据时，既要更新数据库，又要更新缓存，这个顺序和时机很重要。

1. 先更新数据库，再删除缓存：这是比较常用的策略（Cache-Aside pattern），即使删除缓存失败，也只会导致一次缓存脏数据，下次读取时会被纠正，但存在一个极端情况：更新数据库后，删除缓存前，另一个线程读了旧数据到缓存，会导致脏数据长期存在（概率低）。
2. 先删除缓存，再更新数据库：这也会导致不一致（请求A删缓存后，请求B读不到缓存，读了数据库旧值并设回缓存），可以用“延迟双删”策略缓解（更新数据库后，再删一次缓存）。 这个问题没有完美方案，需要根据业务对一致性的要求来选择策略，比如允许短暂不一致，或者使用串行化队列等复杂方案。

Redis的集群模式了解吗？ （来源：面试 scalability 问题） 为了高可用和扩展性，Redis有几种集群方案：

• 主从复制：一个主节点（Master）负责写，多个从节点（Slave）负责读和备份，数据从主节点同步到从节点。
• 哨兵模式（Sentinel）：在主从复制基础上，增加了哨兵进程来监控主节点状态，当主节点宕机时，哨兵能自动选举一个从节点升级为主节点，实现自动故障转移。
• 集群模式（Cluster）：Redis官方提供的分布式方案，数据被分片（sharding）到多个节点上存储，每个节点存储一部分数据，通过 gossip 协议通信，支持线性扩展。