redis高频深度面试题10问

码出极致
67 阅读21分钟

1. Redis单线程模型为何能支撑高并发，在Redis 6.0引入多线程后有哪些变化？

Redis基于内存操作，数据读写速度极快，避免了磁盘I/O的延迟。同时采用I/O多路复用技术，如在Linux环境下通过epoll机制，单线程可同时处理多个客户端连接。当某个连接暂时无数据可读或可写时，线程不会阻塞等待，而是继续处理其他活跃连接，极大提高了并发处理能力。而且单线程模型避免了多线程编程中常见的上下文切换开销以及锁竞争问题，对于共享资源（如数据结构）的访问无需加锁，保证了原子性操作，简化了编程模型，提升了执行效率 。

在Redis 6.0版本中引入了多线程，主要用于处理网络I/O操作，而命令执行仍由主线程负责。通过配置io-threads参数可启用多线程I/O，默认情况下该功能是关闭的。例如设置io-threads 4，即启用4个I/O线程。这一改进尤其适用于大value读取（如1MB以上的数据）以及高并发连接数（万级以上）的场景，能够进一步提升Redis在高负载下的性能表现 。

2. 深入讲讲Redis持久化机制，RDB和AOF除了基本特性外，在实际应用中如何选择，混合持久化又是怎么回事？

RDB通过生成内存快照来持久化数据。在特定条件下（如配置的save m n，表示在m秒内至少有n个键发生变化时），Redis将当前内存数据以二进制形式保存到RDB文件。恢复时直接加载RDB文件到内存，速度较快，文件采用二进制压缩格式，体积相对较小。但其数据安全性相对较低，可能丢失最后一次快照后到服务器崩溃期间的数据 。例如在电商系统凌晨进行全量数据备份场景中，RDB的快速恢复特性可以迅速让系统恢复到备份时的状态，用于数据恢复测试等场景 。

AOF以追加方式将Redis服务器接收到的每一个写操作命令记录到AOF文件，文件为文本格式。通过配置不同的刷盘策略（如appendfsync always表示每次写操作都同步到磁盘，数据安全性高，但对性能有一定影响；appendfsync everysec表示每秒同步一次到磁盘；appendfsync no表示由操作系统决定何时同步到磁盘）。恢复时需重放AOF文件中的所有写操作命令，速度相对较慢，且文件体积通常较大 。在金融交易系统中，由于对数据一致性要求极高，采用appendfsync always策略的AOF持久化可确保每一笔交易记录都不会丢失 。

在实际应用中，若对数据恢复速度要求较高，且能容忍一定时间内的数据丢失，可优先选择RDB，如一些缓存场景，丢失少量缓存数据影响不大，但需要快速恢复缓存数据。若对数据安全性要求极高，不允许丢失任何数据，则应选择AOF，如涉及资金交易、重要订单数据存储等场景 。

Redis 4.0后引入混合持久化，结合了RDB和AOF的优点。在进行AOF重写时，不再是单纯将内存数据以命令形式追加到AOF文件，而是先将内存中的数据以RDB格式写入AOF文件开头，之后再将重写过程中产生的增量写命令追加到RDB数据之后。这样在恢复时，先快速加载RDB部分的数据，再重放后面少量的AOF增量命令，既能保证数据恢复速度，又能提高数据安全性 。

3. Redis事务是如何实现的，它与传统数据库事务有何异同，在实际应用中有哪些需要注意的地方？

Redis事务通过MULTI、EXEC、DISCARD和WATCH等命令实现 。当客户端发送MULTI命令时，开启一个事务块，后续发送的命令不会立即执行，而是被放入一个队列中。直到客户端发送EXEC命令，Redis才会依次执行队列中的所有命令 。DISCARD命令用于取消事务，清空事务队列。WATCH命令用于监视一个或多个键，在执行EXEC之前，如果被监视的键发生了变化，则事务会被取消 。

与传统数据库事务相比，相同点在于都提供了一种将多个操作组合在一起，保证原子性和一致性的机制 。不同点在于，Redis事务不支持回滚，即事务中的部分命令执行失败，其他命令仍会继续执行，这是因为Redis设计初衷是追求高性能，回滚机制会增加复杂性和性能开销 。而传统数据库事务一般支持回滚，以确保数据的完整性 。

在实际应用中，需要注意由于Redis事务不支持回滚，在编写事务内的命令时，要确保每个命令的正确性，避免因部分命令失败导致数据不一致 。同时，在使用WATCH命令时，要考虑并发场景下数据变化的情况，防止事务因数据变化被取消而导致业务逻辑异常 。例如在电商库存扣减场景中，使用Redis事务保证库存扣减和订单生成操作的原子性，但要确保库存扣减命令正确执行，否则可能出现超卖等问题 。

4. Redis的分布式锁有哪些实现方式，RedLock算法的原理和应用场景是什么，如何保证分布式锁的可靠性？

基本的Redis分布式锁可通过SET lock_key unique_value NX EX 30命令实现 。其中，lock_key是锁的键名，unique_value是客户端生成的唯一标识，用于区分不同客户端的锁 。NX表示只有当lock_key不存在时才进行设置操作，确保了锁的唯一性 。EX 30表示设置锁的过期时间为30秒，防止因程序异常导致锁一直未释放 。在释放锁时，需使用Lua脚本保证释放操作的原子性，先验证锁的持有者是否为自己（通过比较unique_value），再进行删除操作 。

RedLock算法是Redis官方提出的一种分布式锁实现方式，旨在解决单节点Redis分布式锁在节点故障时的可靠性问题 。它基于多个独立的Redis节点（通常为奇数个，如5个），客户端向多个节点依次发送获取锁的请求 。当客户端从多数节点（≥3个）成功获取锁，且总耗时小于锁的有效期时，认为获取锁成功 。例如，在一个分布式电商系统中，多个订单处理服务可能同时竞争对某个商品库存的修改操作，使用RedLock算法可以保证在部分Redis节点出现故障的情况下，仍然能正确实现锁的互斥性，避免超卖等问题 。

为保证分布式锁的可靠性，除了使用RedLock等多节点方案外，还需注意合理设置锁的过期时间，避免因业务执行时间过长导致锁提前过期，出现并发问题 。同时，在获取锁和释放锁的过程中，要保证操作的原子性，防止因网络波动等原因导致锁的状态不一致 。另外，对于长时间持有锁的业务逻辑，要考虑锁的续期机制，确保业务完成前锁不会失效 。

5. Redis集群中的数据分片机制是怎样的，节点间如何通信，在集群环境下客户端如何进行请求路由？

Redis Cluster采用数据分片技术，将整个键空间划分为16384个槽位（0 - 16383） 。每个Redis节点负责一部分槽位，数据的分布通过对键进行哈希计算来决定 。例如，使用CRC16算法对键进行哈希计算，然后对16384取模，得到的结果就是该键对应的槽位编号，进而确定负责该槽位的节点 。

节点间通过Gossip协议进行通信 。每个节点会定期向其他节点发送Gossip消息，消息中包含自身的状态、负责的槽位信息以及其他节点的部分信息等 。通过这种方式，节点之间可以互相了解集群的状态，实现节点故障检测、新节点加入等功能 。例如，当一个新节点加入集群时，它会向已存在的节点发送Gossip消息，告知自己的存在和相关信息，已存在的节点会将这些信息传播给其他节点，从而使新节点能够快速融入集群 。

在集群环境下，客户端进行请求路由有两种方式 。一是客户端缓存槽位映射表，在首次请求时，通过向任意一个节点发送CLUSTER SLOTS命令获取槽位与节点的映射关系，并缓存起来 。后续请求时，根据键计算出槽位编号，直接将请求发送到对应的节点 。当集群拓扑发生变化（如节点故障、新节点加入）时，节点会返回MOVED错误给客户端，客户端收到MOVED错误后，更新本地的槽位映射表 。二是通过代理方式，如使用Twemproxy等代理服务器，客户端将所有请求发送到代理服务器，代理服务器负责根据槽位映射关系将请求转发到正确的Redis节点 。

6. Redis的内存淘汰策略有哪些，在不同的业务场景中如何选择合适的内存淘汰策略？

Redis有8种内存淘汰策略：

  1. noeviction（默认）：当内存不足以容纳新写入数据时，新写入操作会报错，不删除任何键，适用于不允许数据丢失的场景，如某些金融数据的存储 。
  2. allkeys-lru：在键空间中，移除最近最少使用的键，适用于大部分缓存场景，优先保留经常访问的数据 。例如在电商商品详情页缓存中，热门商品的数据会被频繁访问，采用该策略可保证热门商品的缓存数据一直存在 。
  3. allkeys-random：从键空间中随机移除键，这种策略比较适用于对数据访问没有明显冷热区分，或者希望随机淘汰数据的场景，实际应用相对较少 。
  4. volatile-lru：从设置了过期时间的键中，移除最近最少使用的键，适用于希望优先淘汰过期数据，且对缓存数据有冷热区分的场景 。例如在用户会话缓存中，会话数据设置了过期时间，使用该策略可优先淘汰长时间未活跃的会话缓存 。
  5. volatile-random：从设置了过期时间的键中，随机移除键，类似于allkeys-random，但仅针对有过期时间的键，适用于对过期数据淘汰没有特定规律要求的场景 。
  6. volatile-ttl：从设置了过期时间的键中，删除剩余生存时间最短的键，适用于希望优先淘汰即将过期数据的场景，如限时优惠券的缓存，优先淘汰即将过期的优惠券缓存 。
  7. allkeys-lfu：Redis 4.0后引入，从键空间中，移除访问频率最低的键，相较于LRU，更注重数据的访问频率，适用于对数据访问频率有严格要求的场景，如内容推荐系统的缓存，热门推荐内容的缓存应尽量保留 。
  8. volatile-lfu：从设置了过期时间的键中，移除访问频率最低的键，结合了LFU和对过期键的处理，适用于有过期时间且对访问频率有要求的缓存场景 。

7. 谈谈Redis的缓存雪崩、缓存穿透和缓存击穿问题，除了常见解决方案外，在高并发场景下如何优化这些解决方案？

缓存雪崩是指大量缓存数据在同一时刻过期失效，导致大量请求直接落到数据库上，造成数据库瞬间压力过大，甚至可能导致数据库崩溃 。常见解决方案如设置随机过期时间，避免大量缓存同时过期；采用二级缓存架构，在Redis之前再加一层本地缓存（如Guava Cache），当Redis缓存失效时，先从本地缓存获取数据返回给客户端，同时异步更新Redis缓存 。在高并发场景下，可进一步优化，如使用分布式缓存预热机制，在系统启动前或业务低峰期，提前将热点数据加载到缓存中，并设置不同的过期时间 。还可以结合限流降级措施，使用令牌桶算法或漏桶算法对访问数据库的请求进行限流，对于非核心业务进行降级处理，如返回默认数据、提示信息等，优先保障核心业务的正常运行 。

缓存穿透是指客户端请求的数据在缓存和数据库中都不存在，导致请求每次都绕过缓存直接访问数据库，可能由恶意攻击或业务逻辑漏洞引起 。常见解决方案有使用布隆过滤器，在缓存之前添加布隆过滤器，快速判断数据是否存在，若不存在则直接返回，不再访问缓存和数据库；对查询结果为空的情况也进行缓存，设置较短的过期时间，避免重复查询数据库 。在高并发场景下，为优化布隆过滤器性能，可采用分布式布隆过滤器，如RedisBloom模块，将布隆过滤器的数据分布在多个Redis节点上，提高查询效率 。同时，加强对业务逻辑的校验，避免无效请求进入系统，从源头减少缓存穿透的发生 。

缓存击穿是指一个热点Key（访问频率非常高的Key）在缓存过期的瞬间，大量请求同时访问该Key，由于缓存失效，这些请求会同时落到数据库上，造成数据库瞬间压力过大 。常见解决方案有使用互斥锁，在缓存过期时，使用Redis的分布式锁（如SETNX lock_key 1）保证只有一个请求能够访问数据库并更新缓存，其他请求等待；将热点Key设置为永不过期，同时通过定时任务或者数据变更监听机制，在数据发生变化时主动更新缓存 。在高并发场景下，对于互斥锁方案，可使用Redisson等分布式锁框架，其提供了更丰富的锁功能和优化的性能，如公平锁、联锁等，能更好地应对高并发竞争 。并且可以对热点Key进行分级管理，将超高频热点Key单独处理，采用多级缓存等方式进一步降低对数据库的压力 。

8. Redis主从复制过程中，全量同步和增量同步的详细流程是怎样的，可能会遇到哪些问题，如何解决？

全量同步流程如下：

  1. 当新的Slave节点启动并连接到Master节点后，向Master发送PSYNC ? -1命令（Redis 2.8及以上版本）请求同步数据，由于是全新连接，PSYNC命令中的第一个参数为?，第二个参数为-1 。
  2. Master节点收到请求后，触发一次RDB持久化操作，在后台生成一个RDB快照文件，同时收集从此时起到RDB生成完成期间所有接收到的写操作命令，缓存起来 。
  3. Master节点完成RDB快照生成后，将RDB文件发送给Slave节点 。
  4. Slave节点接收到RDB文件后，先清空自身原有的数据，然后将RDB文件加载到内存中，完成数据的初始化 。
  5. Master节点将缓存的写操作命令依次发送给Slave节点，Slave节点执行这些命令，使自身数据与Master节点保持一致 。

增量同步流程如下：

  1. 在全量同步完成后，Master节点会继续将新接收到的写操作命令发送给Slave节点，保持数据的实时同步 。Master节点维护一个复制积压缓冲区（repl_backlog），用于记录最近一段时间内的写操作命令 。
  2. 当Slave节点与Master节点因网络等原因断开连接后重新连接时，Slave节点会向Master节点发送PSYNC replid offset命令，其中replid是Master节点的运行ID，offset是Slave节点断开连接时的复制偏移量 。
  3. Master节点根据接收到的replid和offset，判断是否可以进行增量同步 。如果replid匹配且offset在复制积压缓冲区的范围内，Master节点会从offset位置开始，将积压缓冲区中后续的写操作命令发送给Slave节点，完成增量同步 。

在主从复制过程中，可能遇到以下问题及解决方法：

  1. 数据不一致问题：可能由于网络延迟、复制积压缓冲区设置不合理等原因导致。解决方法是合理设置复制积压缓冲区大小，可通过repl-backlog-size参数配置，确保足够记录主从节点断开期间的写操作命令 。同时，定期检查主从节点的数据一致性，可使用Redis的SYNC命令进行强制全量同步，但此操作可能会对性能有一定影响，应在业务低峰期执行 。
  2. 复制延迟问题：网络状况不佳、Master节点负载过高都可能导致复制延迟。优化网络环境，确保主从节点间网络稳定、带宽充足 。对于Master节点负载过高问题，可通过优化业务逻辑，减少Master节点的写操作压力，或增加从节点数量分担读压力 。还可以通过监控slave_repl_offset（从节点复制偏移量）和master_repl_offset（主节点复制偏移量）等指标，实时了解复制延迟情况 。
  3. 主从切换后数据丢失问题：在哨兵模式下，当主节点故障进行主从切换时，可能会丢失部分未同步的数据 。可通过配置合理的min-slaves-to-write（指定主节点在至少有多少个从节点连接时才进行写操作）和min-slaves-max-lag（指定从节点与主节点数据复制延迟的最大时间）参数，减少数据丢失的风险 。例如设置min-slaves-to-write 2和min-slaves-max-lag 10，表示主节点至少有2个从节点连接且从节点复制延迟不超过10秒时才进行写操作 。

9. Redis中的BigKey问题是什么，如何发现和解决BigKey问题，在业务中如何避免产生BigKey？

BigKey问题是指Redis中存在的键值对，其值占用的内存空间过大 。这些大值可能是大的字符串、包含大量元素的哈希表、列表、集合或有序集合等 。例如，一个包含数万条商品评论的List类型的键值对，或者一个存储了大量用户详细信息（如包含丰富属性的哈希表）的键，都可能成为BigKey 。

发现BigKey问题可以通过以下几种方法：

  1. Redis命令行工具：使用MEMORY USAGE命令可以查看某个键值对占用的内存大小 。例如，执行MEMORY USAGE key_name，即可返回key_name键值对占用的字节数。
  2. 扫描工具：使用redis-cli --bigkeys命令可以扫描Redis中的键，找出那些元素数量较多的键（如大List、大Hash等），虽然不能直接获取内存大小，但能快速定位潜在的BigKey。
  3. 自定义脚本：通过SCAN命令遍历所有键，结合MEMORY USAGE命令批量检查键的内存占用，筛选出超过阈值的BigKey。
  4. 监控工具：使用Redis Insight、Prometheus+Grafana等监控工具，通过监控redis_key_size等指标，实时跟踪键的内存变化，及时发现BigKey。

解决BigKey问题的核心思路是拆分或优化数据结构：

  • 拆分BigKey：
    • 对于大Hash（如存储百万用户信息的Hash），可按用户ID范围拆分，如user:info:1000-2000、user:info:2001-3000，每个子Hash只存储部分用户信息。
    • 对于大List（如存储大量消息的队列），可按时间或类型拆分，如msg:queue:20231001、msg:queue:20231002，避免单个List过大。
    • 对于大String（如超大JSON字符串），可拆分为多个小String，如将user:1000:all拆分为user:1000:name、user:1000:age等。
  • 优化数据结构：
    • 对于集合类BigKey（如大Set、大ZSet），若元素是整数，可启用set-max-intset-entries配置，让Redis优先使用intset存储（更节省内存）。
    • 对于不常用的BigKey，可考虑迁移到其他存储（如MySQL、MongoDB），Redis只缓存热点部分数据。
  • 批量操作优化：避免对BigKey执行HGETALL、LRANGE 0 -1等全量操作，改用HSCAN、LSCAN等增量迭代命令，减少单次操作的性能开销。

在业务中避免产生BigKey的方法：

  • 业务设计规范：明确单个键的最大元素数量或内存阈值（如Hash不超过1000个字段，List不超过5000条记录），超出则强制拆分。
  • 数据生命周期管理：对临时数据设置合理的过期时间，避免长期积累导致BigKey。
  • 接入层控制：在数据写入Redis前，通过网关或业务代码检查数据大小，拒绝超阈值的写入请求。

10. Redis的Gossip协议和Cluster总线协议有什么区别，它们在集群中各自发挥什么作用？

Redis Cluster中存在两种核心通信机制：Gossip协议和Cluster总线协议（Cluster Bus），二者功能不同但协同工作。

Gossip协议：

  • 本质：一种去中心化的节点间信息同步协议，基于“随机散播”策略传播集群状态。
  • 通信方式：节点定期（默认每100ms）随机选择几个节点发送Gossip消息（包含自身状态、槽位信息、其他节点的状态摘要等），接收者再将消息转发给其他节点，最终实现集群信息的全网同步。
  • 特点：
    • 信息传播有延迟（非实时），但节省带宽和CPU资源。
    • 消息内容是“增量更新”，避免全量数据传输的开销。
  • 作用：
    • 维护集群拓扑：节点加入/退出、角色变化（主从切换）等信息通过Gossip同步。
    • 故障检测：节点通过Gossip消息感知其他节点的存活状态，为客观下线（ODOWN）判断提供依据。

Cluster总线协议：

  • 本质：基于TCP的专用通信协议，使用固定端口（节点端口+10000），用于节点间的实时命令交互。
  • 通信方式：节点间建立持久TCP连接，通过发送特定命令（如PING、PONG、FAIL、PUBLISH等）进行实时通信。
  • 特点：
    • 通信实时性高，用于需要立即响应的场景。
    • 消息格式简洁，专注于命令传递而非状态同步。
  • 作用：
    • 实时心跳检测：节点通过PING/PONG命令实时确认对方存活状态，为主观下线（SDOWN）提供依据。
    • 故障通知：当节点判断某个主节点客观下线后，通过FAIL命令向集群广播，触发故障转移。
    • 槽位迁移协调：在集群扩容/缩容时，节点通过总线协议协商槽位迁移的细节（如数据传输、状态确认）。

总结：Gossip协议负责集群状态的“异步扩散”，保证集群最终一致性；Cluster总线协议负责“实时命令交互”，支撑故障检测、故障转移等需要即时响应的操作。二者结合，既降低了通信开销，又确保了集群的高可用性。

avatar
文章
阅读
粉丝