redis高频基础面试题10问1. 什么是Redis，它有哪些特点？ Redis即远程字典服务（Remote Dicti

1. 什么是Redis，它有哪些特点？

Redis即远程字典服务（Remote Dictionary Server），是一个开源的、基于内存的数据结构存储系统，可用作数据库、缓存和消息中间件。它具备以下特点：

高性能：由于数据存储在内存中，避免了磁盘I/O的开销，读写速度极快，能轻松支持每秒数万甚至数十万次的读写操作。例如在高并发的秒杀场景中，Redis能够快速处理库存扣减等操作，保证系统的响应速度。
丰富的数据类型：支持String（字符串）、Hash（哈希）、List（列表）、Set（集合）、ZSet（有序集合）等多种数据类型。String可用于缓存简单文本或作为计数器；Hash适合存储对象，方便对对象的字段进行单独操作；List常用于实现消息队列或最新消息排行；Set可处理共同关注、去重等场景；ZSet常用于排行榜、延迟队列等。
持久化支持：提供RDB（Redis Database）和AOF（Append - Only File）两种持久化方式。RDB通过生成内存快照来持久化数据，文件体积小，恢复速度快，但可能丢失最后一次快照后的部分数据；AOF则是通过追加写操作日志，数据安全性更高，不过日志文件可能较大，恢复时需重放命令。
集群模式：支持主从复制和Redis Cluster集群模式。主从复制实现读写分离，Master负责写，Slave负责读，同时Slave作为备份增强可靠性；Redis Cluster采用数据分片，将数据分布在多个节点上，通过16384个slot（槽位）分配数据，具备自动故障转移和高可用性。
原子性操作：单线程模型确保了命令执行的原子性，对同一数据的多个操作不会被打断，保证数据一致性。像INCR（自增）、DECR（自减）等操作，在高并发下也能正确执行。

2. Redis与Memcached有什么区别？

数据类型支持：Memcached仅支持简单的字符串类型；而Redis支持多种数据类型，如String、Hash、List、Set、ZSet等，这使得Redis能满足更复杂的业务场景需求。例如，在存储用户信息时，Redis的Hash类型可以方便地将用户的多个属性（姓名、年龄、地址等）存储在一个键值对中，并且可以对单个属性进行独立更新。
持久化功能：Memcached不支持数据持久化，数据仅存储在内存中，服务器重启后数据丢失；Redis提供RDB和AOF两种持久化方式，可将内存数据保存到磁盘，在服务器重启时恢复数据，保证数据的持久性。
性能表现：虽然两者都基于内存，性能出色，但Redis在某些复杂操作上可能略慢于Memcached。因为Redis要支持多种数据类型和持久化等功能，内部实现相对复杂。不过在简单的读写场景中，Redis的速度也非常快，能满足大多数高性能需求。
分布式架构：Memcached的分布式需要依赖客户端来实现，通过客户端的算法将数据分布到不同节点；Redis原生支持主从复制和Redis Cluster集群模式，集群的搭建和管理相对更方便，具备更好的扩展性和高可用性。
内存管理：Memcached使用预分配内存池的方式管理内存，在存储不同大小的数据时，可能会造成内存浪费；Redis采用自适应内存管理机制，根据数据类型和使用情况动态分配内存，内存利用率更高。

3. Redis支持哪些数据类型，各自的适用场景是什么？

String（字符串）：
- 适用场景：常用于缓存简单数据，如文本内容、JSON字符串等。也可作为计数器，通过INCR、DECR等命令对数值进行原子性增减，用于统计页面访问量、点赞数等。例如，将一篇文章的内容缓存为String类型，键为文章ID，值为文章内容；或者使用INCR命令统计用户对某个内容的点赞次数，键为“content:点赞数:内容ID” 。
Hash（哈希）：
- 适用场景：适合存储对象，如用户信息、商品详情等。可以对哈希表中的单个字段进行独立更新，避免更新整个对象时的额外开销。例如，将用户信息（包含姓名、年龄、邮箱等）存储在一个Hash中，键为“user:用户ID”，字段为属性名（如“name”“age”“email”），值为对应属性值。
List（列表）：
- 适用场景：可实现消息队列，通过LPUSH（从列表左侧插入元素）和BRPOP（阻塞式从列表右侧弹出元素）等命令组合，保证消息的顺序处理。也用于展示最新消息排行，如新闻列表、评论列表等，通过LTRIM命令控制列表长度，只保留最新的若干条消息。例如，在一个即时通讯系统中，使用List存储用户的聊天消息，通过LPUSH不断添加新消息，客户端通过BRPOP获取消息。
Set（集合）：
- 适用场景：可用于计算共同关注、共同喜好等交集场景，通过SINTER命令实现。也常用于抽奖、点赞等去重场景，利用SADD命令向集合中添加元素，由于集合元素的唯一性，重复元素不会被再次添加。例如，在社交平台中，使用Set存储用户的关注列表，通过SINTER命令可以获取两个用户的共同关注列表。
ZSet（有序集合）：
- 适用场景：常用于排行榜相关场景，如游戏排名、商品销量排行等，通过ZRANGE命令可按分数范围获取排名范围内的元素。也可实现延迟队列，将任务的执行时间作为分数，根据分数排序确定任务的执行顺序。例如，在电商平台中，使用ZSet存储商品的销量排行榜，score为销量值，通过ZRANGE命令获取销量前N的商品。

4. Redis为什么快，单线程模型有什么优势？

Redis快主要源于以下几点：

基于内存操作：内存的读写速度远快于磁盘，Redis将数据存储在内存中，避免了磁盘I/O的延迟，大大提高了读写性能。
I/O多路复用：通过epoll（Linux）、kqueue（FreeBSD）等机制实现非阻塞I/O。单线程可以同时处理多个客户端连接，当某个连接没有数据可读或可写时，线程不会阻塞等待，而是继续处理其他活跃的连接，提高了系统的并发处理能力。
单线程优势：避免了多线程编程中常见的上下文切换开销以及锁竞争问题。由于所有操作都在一个线程中顺序执行，对于共享资源（如数据结构）的访问无需加锁，保证了原子性操作，简化了编程模型，提高了执行效率。
优化的数据结构：采用全局哈希表来存储键值对，查找和插入操作的平均时间复杂度为O(1)。对于有序集合等数据结构，使用跳表（Skip List）实现，在保证高效插入、删除和查找操作的同时，相比平衡树等结构，代码实现更简单，时间复杂度为O(logN) 。

例如在电商秒杀场景中，Redis单线程能够高效处理大量的库存扣减请求。通过内存操作和I/O多路复用，避免了多线程锁竞争带来的性能损耗，同时利用原子性操作（如DECR命令）保证了库存扣减的准确性和一致性。

5. Redis的持久化机制有哪些，RDB和AOF有什么区别？

RDB（Redis Database）

持久化方式：通过生成内存快照来进行持久化。Redis会在特定条件下（如配置的save m n，表示在m秒内至少有n个键发生变化时），将当前内存中的数据以二进制的形式保存到磁盘上的一个RDB文件中。
数据安全性：由于是定期生成快照，可能会丢失最后一次快照后到服务器崩溃期间的数据。例如，若配置为每60秒生成一次快照，在第59秒时写入了大量数据，此时服务器崩溃，这些数据将丢失。
恢复速度：恢复时直接加载RDB文件到内存，速度相对较快，因为只需读取一次磁盘文件并反序列化数据。
文件大小：RDB文件采用二进制压缩格式，文件体积相对较小，占用磁盘空间少。

AOF（Append - Only File）

持久化方式：以追加的方式将Redis服务器接收到的每一个写操作命令记录到AOF文件中。文件格式为文本，记录了每个写操作的命令及其参数。
数据安全性：数据安全性更高，通过配置不同的刷盘策略（如appendfsync always表示每次写操作都同步到磁盘，appendfsync everysec表示每秒同步一次到磁盘，appendfsync no表示由操作系统决定何时同步到磁盘），可以在一定程度上保证数据不丢失。例如，采用appendfsync always策略时，只要写操作成功执行，数据就会立即持久化到磁盘，但这种方式会对性能有一定影响。
恢复速度：恢复时需要重新执行AOF文件中的所有写操作命令来重建数据，速度相对较慢，尤其是AOF文件较大时，重放命令的时间会较长。
文件大小：AOF文件是文本格式，且记录了所有写操作命令，文件体积通常较大，随着时间推移和写操作的增多，文件会不断膨胀。为了解决AOF文件过大的问题，Redis提供了AOF重写机制，通过创建一个新的AOF文件，将原文件中的冗余命令合并，从而减小文件大小。

6. 如何用Redis实现分布式锁？

使用SET lock_key unique_value NX EX 30命令来实现分布式锁。其中，lock_key是锁的键名；unique_value是客户端生成的唯一标识，用于区分不同客户端的锁；NX表示只有当lock_key不存在时才进行设置操作，确保了锁的唯一性；EX 30表示设置锁的过期时间为30秒，防止因程序异常导致锁一直未释放。

实现过程中需要注意：

锁的持有标识：每个客户端获取锁时设置的unique_value必须唯一，这样在释放锁时才能确保释放的是自己持有的锁，避免误释放其他客户端的锁。
锁的过期时间：合理设置锁的过期时间非常重要。若过期时间过短，可能导致业务尚未执行完锁就已过期，出现并发问题；若过期时间过长，在锁持有者出现故障时，会导致其他客户端长时间等待无法获取锁。设置过期时间时，需保证其原子性，通过上述SET命令的扩展参数即可实现。也可使用Lua脚本结合SET和EXPIRE命令来保证原子性。
释放锁的原子性：释放锁时，需先验证锁的持有者是否为自己，再进行删除操作。这一过程需保证原子性，否则在高并发场景下可能出现问题。可以使用Lua脚本实现，示例代码如下：

if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

在上述Lua脚本中，KEYS[1]为锁的键名，ARGV[1]为客户端持有的锁的唯一标识。

7. Redis的主从复制机制是怎样的，有什么作用？

同步流程

全量同步（初次同步）：
- 当一个新的Slave节点启动并连接到Master节点后，会向Master发送一个PSYNC命令（Redis 2.8及以上版本）请求同步数据。如果是全新连接，Master节点会触发一次RDB持久化操作，在后台生成一个RDB快照文件，同时收集从此时起到RDB生成完成期间所有接收到的写操作命令，缓存起来。
- Master节点完成RDB快照生成后，将RDB文件发送给Slave节点。Slave节点接收到RDB文件后，先清空自身原有的数据，然后将RDB文件加载到内存中，完成数据的初始化。
- Master节点将缓存的写操作命令依次发送给Slave节点，Slave节点执行这些命令，使自身数据与Master节点保持一致。
增量同步：在全量同步完成后，Master节点会继续将新接收到的写操作命令发送给Slave节点，保持数据的实时同步。Master节点会维护一个复制积压缓冲区（repl_backlog），用于记录最近一段时间内的写操作命令。当网络出现短暂中断等情况导致Slave节点与Master节点断开连接后重新连接时，如果Slave节点断开期间Master节点的写操作命令在复制积压缓冲区中还有记录，那么可以通过增量同步，只同步这部分缺失的写操作命令，而无需再次进行全量同步。
心跳机制：Slave节点会定期向Master节点发送心跳包（默认每秒一次），以维持连接状态并汇报自身的复制进度。Master节点也会通过心跳包向Slave节点发送一些信息，如复制偏移量等。

作用

读写分离：Master节点负责处理写操作，保证数据的一致性；Slave节点负责处理读操作，可以将读请求分摊到多个Slave节点上，提高系统的并发读性能。例如，在一些读多写少的应用场景中，如新闻资讯网站、电商商品详情页展示等，大量的读请求可以由Slave节点处理，减轻Master节点的压力。
数据冗余与备份：多个Slave节点保存了Master节点的数据副本，当Master节点出现故障时，可以从Slave节点中选举出新的Master节点，继续提供服务，保证数据的可用性和系统的高可靠性。即使某个Slave节点出现故障，也不会影响整个系统的正常运行，因为其他Slave节点仍保存有完整的数据。
数据恢复：当Master节点的数据丢失或损坏时，可以从Slave节点中选择一个数据较新的节点，将其数据复制回Master节点，实现数据恢复。

8. Redis的缓存雪崩、缓存穿透和缓存击穿是什么，如何解决？

缓存雪崩

问题描述：缓存雪崩是指在某一时刻，大量的缓存数据同时过期失效，导致大量原本应该访问缓存的请求直接落到数据库上，造成数据库瞬间压力过大，甚至可能导致数据库崩溃。例如，在电商大促活动中，为了减轻数据库压力，设置了大量商品缓存，若这些缓存都设置了相同的过期时间，在过期时间到达时，大量用户对商品信息的请求就会直接访问数据库。
解决方案：
- 随机过期时间：在设置缓存过期时间时，为每个缓存数据设置一个随机的过期时间，避免大量缓存同时过期。例如，原本设置商品缓存过期时间为1小时，可以改为在50分钟到70分钟之间随机取值作为过期时间。
- 缓存永不过期：对于一些重要且数据更新频率较低的缓存数据，设置为永不过期。同时，通过定时任务或者数据变更监听机制，在数据发生变化时主动更新缓存。比如商品的基本信息（如名称、图片等很少变动的数据）可以设置为永不过期，当商品信息更新时，触发缓存更新操作。
- 二级缓存：采用二级缓存架构，例如在Redis之前再加一层本地缓存（如Guava Cache）。当Redis中的缓存失效时，先从本地缓存获取数据返回给客户端，同时异步更新Redis缓存。这样可以在一定程度上减轻数据库压力。
- 限流降级：在缓存失效期间，对访问数据库的请求进行限流，如使用令牌桶算法、漏桶算法等限制单位时间内访问数据库的请求数量。对于非核心业务，可以进行降级处理，如返回默认数据、提示信息等，优先保障核心业务的正常运行。

缓存穿透

问题描述：缓存穿透是指客户端请求的数据在缓存和数据库中都不存在，导致请求每次都绕过缓存直接访问数据库。这种情况可能是由于恶意攻击（如黑客故意请求不存在的数据）或者业务逻辑漏洞导致。例如，在用户查询系统中，若有人恶意构造大量不存在的用户ID进行查询，这些请求会不断穿透缓存访问数据库。
解决方案：
- 布隆过滤器（Bloom Filter）：在缓存之前添加布隆过滤器，布隆过滤器可以快速判断一个数据是否存在。当客户端请求到达时，先通过布隆过滤器进行判断，如果布隆过滤器判断数据不存在，则直接返回，不再访问缓存和数据库；如果判断数据可能存在，再去查询缓存和数据库。例如，在电商商品查询系统中，将所有商品ID添加到布隆过滤器中，当用户查询商品时，先经过布隆过滤器判断，减少无效查询。
- 空值缓存：当查询数据库发现数据不存在时，也将空值缓存起来，并设置一个较短的过期时间（如几分钟）。下次再查询相同数据时，直接从缓存中获取空值返回，避免再次访问数据库。例如，对于不存在的用户ID查询结果，缓存空值10分钟，10分钟内相同请求直接从缓存获取空值。

缓存击穿

问题描述：缓存击穿是指一个热点Key（访问频率非常高的Key）在缓存过期的瞬间，大量请求同时访问该Key，由于缓存失效，这些请求会同时落到数据库上，造成数据库瞬间压力过大。例如，在秒杀活动中，秒杀商品的Key是热点Key，当该Key的缓存过期时，大量用户的秒杀请求会同时访问数据库查询商品库存。
解决方案：
- 互斥锁：在缓存过期时，使用互斥锁（如Redis的分布式锁）来保证只有一个请求能够访问数据库并更新缓存，其他请求等待。当第一个请求更新完缓存后，释放锁，其他请求再从缓存中获取数据。例如，在秒杀场景中，当秒杀商品缓存过期时，第一个请求获取分布式锁，查询数据库获取商品库存并更新缓存，然后释放锁，后续请求直接从缓存获取商品库存信息。
- 热点Key永不过期：对于热点Key，设置为永不过期，同时通过定时任务或者数据变更监听机制，在数据发生变化时主动更新缓存。例如，将热门商品的库存信息设置为永不过期，当库存发生变化时，立即更新缓存。

9. Redis的哨兵机制是什么，它的主要作用是什么？

Redis哨兵（Sentinel）是一个分布式系统，用于监控Redis主从集群中的节点状态，实现自动故障转移。它通常由多个哨兵节点组成，共同协作完成监控和故障处理工作。

主要作用包括：

监控：哨兵节点会定期向主节点、从节点发送PING命令，检查节点是否存活。通过持续监控，及时发现节点故障。
自动故障转移：当主节点出现故障时，哨兵会先判断主节点是否真正下线（经历主观下线和客观下线过程），然后从该主节点的从节点中选举一个新的主节点，并让其他从节点复制新主节点的数据，实现集群的自动恢复，无需人工干预。
配置提供者：客户端通过连接哨兵，可以获取当前集群的主节点地址。当主节点发生切换后，哨兵会将新的主节点地址告知客户端，确保客户端能正确连接到集群。
通知功能：哨兵可以通过发布/订阅机制，将集群的状态变化（如主节点故障、新主节点选举完成等）通知给客户端，方便客户端做出相应处理。

10. Redis的过期键删除策略有哪些，各自的特点是什么？

Redis采用三种策略结合的方式处理过期键：

惰性删除：只有当客户端访问某个键时，才会检查该键是否过期，若过期则删除。
特点：节省CPU资源，不需要主动扫描过期键，但可能浪费内存空间（过期键未被访问时会一直占用内存）。
定期删除：Redis会每隔一段时间（可配置）扫描部分过期键并删除。扫描时采用随机抽查的方式，避免因扫描全部键导致性能开销过大。
特点：平衡了CPU和内存资源，既能主动删除部分过期键释放内存，又不会因频繁全量扫描影响性能，但可能存在部分过期键未被及时删除的情况。
内存淘汰机制：当Redis内存使用达到设置的最大内存限制（maxmemory）时，会触发内存淘汰策略，删除部分键以释放内存。
常见的淘汰策略包括：
- volatile-lru：从设置了过期时间的键中，删除最近最少使用的键。
- allkeys-lru：从所有键中，删除最近最少使用的键。
- volatile-ttl：从设置了过期时间的键中，删除剩余生存时间最短的键。
- noeviction（默认）：不删除任何键，而是返回错误，适用于不允许数据丢失的场景。
特点：用于在内存不足时保证Redis的正常运行，具体策略可根据业务需求选择，例如缓存场景常用volatile-lru或allkeys-lru。

这三种策略相互配合，既保证了Redis的性能，又能在一定程度上避免过期键长期占用内存。