Redis 面试高频问答（从基础到架构）

1. 核心认知

• 在 Redis 中，所有的 Key 始终是字符串（String）类型。虽然可以存入数字或二进制作为 key，但 Redis 内部都会将其视为字节数组（SDS）。
• Key 的核心作用是寻址。统一用 String 作为 Key，有助于保证哈希查找逻辑的一致性与高效性。
• 因为 Key 是 SDS 字符串，所以你可以用任何内容做 Key（比如图片二进制或序列化对象），只要长度不超过 512MB 即可。

2. 类型详解

1. String：二进制安全，Value 最大 512MB。
   底层：Redis 会按内容自动选择编码：
   ① int：当值可用 64 位有符号整数表示时，直接按整数编码，内存占用更小、读写更快。
   ② embstr：短字符串（常见阈值约 44B）使用紧凑布局，对象头与字符串数据尽量靠近，分配/访问更高效。
   ③ raw：长字符串走普通 SDS 布局，更适合较大内容与频繁修改。
   SDS（简单动态字符串）：
   ① 秒回长度 O(1) 。
   ② 绝不溢出： 当你执行追加操作时，Redis 会先判断len (现有长度) + 新增长度 是否大于 alloc (总容量)？ 如果大于，Redis 会先自动扩容，然后再把东西放进去，永远不用担心内存溢出。
   ③ 空间预留：预分配：你申请 10 字节，Redis 可能会给你 20 字节。多出来的 10 字节留着备用；惰性释放：你删掉 5 字节，Redis 不会立刻把这 5 字节还给系统，而是先留着，万一你等会又要加字符呢？
   
   场景：缓存 JSON、计数器。
2. List：有序字符串列表，可左进右出。
   底层：quicklist = 双向链表 + 多个 quicklistNode；每个节点内部承载的是紧凑连续内存容器 listpack
   结构演进认知：它不再是“每个节点只放一个元素”的普通链表，而是“一个节点打包多个元素”的分段链表，显著降低指针开销与内存碎片。
   存储过程示例：写入 ["apple","banana","cherry"] 时，会优先塞进同一个 quicklistNode 的 listpack 连续空间；当该块达到配置上限（常见默认约 8KB，受 list-max-listpack-size 影响）才会新建下一个节点。
   场景：LPUSH + BRPOP 实现轻量消息队列、时间线流式拉取。
3. Hash：字段-值结构，适合对象建模。
   底层：Hash 的核心实现是 listpack 与 hashtable 两阶段策略，目标是在“小对象极致省内存”和“大对象高查询性能”之间动态平衡。
   宏观逻辑：
   • 初期（小数据量）：默认采用 listpack，连续内存布局，指针开销极低。
   • 升级（大数据量）：当字段数超过阈值，或任一字段值超过阈值时，自动转换为 hashtable，查询从顺序扫描转向近似 O(1)。
   结构细节：
   • listpack：按 [field1, value1, field2, value2, ...] 连续存储。优点是省内存、CPU cache 命中率高；缺点是查找需顺序扫描，复杂度 O(N)。
   • hashtable（dict）：字段通过哈希函数映射到槽位，查找平均 O(1)。
4. Set：无序唯一集合。
   底层：整数集合走 intset，否则 hashtable。
   场景：去重、共同好友（交并差）。
5. ZSet：按 score 有序。
   底层：
   小数据量：底层用 listpack。数据按 [member1, score1, member2, score2] 紧凑排列。
   大数据量：一旦超过阈值（默认 128 个元素或单值超过 64 字节），就会转变为 dict + skiplist 的组合。
   场景：排行榜、按权重的任务调度。

为什么 Redis 这么快

1. 纯内存操作：核心数据在内存，避免大量磁盘 I/O，延迟极低。
2. 单线程执行命令：减少锁竞争与线程切换，执行路径短且稳定。
3. I/O 多路复用：一个线程可高效管理大量连接。
4. 数据结构极致优化：SDS、listpack、skiplist 等针对场景做了极致权衡。

Redis 6.0+ 多线程到底做了什么

模块	是否多线程	说明
命令执行	否（主线程）	保持串行语义，避免复杂锁开销
网络读写 I/O	是	并行收发数据包，减轻主线程网络负担
后台任务	是（后台线程/子进程）	避免大任务阻塞主线程

先给结论

Redis 持久化可理解为“给内存数据存档”，主流策略是：RDB 快照、AOF 追加日志、RDB+AOF 混合持久化，外加“关闭持久化（纯缓存）”场景。

1) RDB（快照存档）

• 原理：在时间点触发 bgsave，把当前内存全量写成紧凑二进制快照（如 dump.rdb）。
• 实现要点：主进程 fork 子进程写盘，依赖 Copy-on-Write，主线程继续处理请求。
• 优点：恢复快、文件小、便于备份与跨机房传输。
• 缺点：两次快照间宕机会丢失期间写入；大实例 fork 有瞬时开销。

2) AOF（命令日志）

• 原理：写命令追加到 AOF，重启时重放恢复数据。
• fsync 策略：always（最安全最慢）、everysec（默认折中）、no（性能高但风险大）。
• AOF 重写：不是“压缩旧日志”，而是直接基于当前内存状态重新生成最小命令集（结果导向）。例如多次 INCR/DEL/SET 后，最终可收敛为一条 SET score 100。
• 重写流程：
  1. 主进程 fork 子进程；
  2. 子进程遍历内存，写入新的临时 AOF；
  3. 重写期间主进程仍处理写请求，并记录增量；
  4. 子进程完成后，主进程把增量追加到新文件并原子替换旧文件。
• 优点：数据更安全（everysec 常见最多丢 1 秒）、可审计性较好。
• 缺点：文件通常更大，恢复通常慢于 RDB 直接加载。

3) 混合持久化（当前主流）

• 做法：AOF 重写时，文件前半段写 RDB 快照，后半段写增量 AOF 命令。
• 效果：兼得“RDB 加载快”和“AOF 丢失少”的优点。
• 典型配置：开启 AOF 并使用 aof-use-rdb-preamble yes。

4) RDB vs AOF 对比

维度	RDB（快照）	AOF（日志）
持久化方式	全量时间点快照	增量命令追加
恢复速度	快（直接加载）	较慢（重放命令）
数据安全	较低（看快照间隔）	较高（取决于 fsync）
资源消耗	fork 时有压力	持续写入与重写开销
文件体积	通常更小	通常更大

5) 怎么选

• 默认推荐：混合持久化（AOF everysec + RDB 备份），兼顾恢复速度和数据可靠性。
• 可容忍分钟级丢失：偏 RDB 策略，性能更轻。
• 纯缓存场景：可关闭持久化，换取极致性能（但重启即丢数据）。

两个概念

• 过期键删除：处理“已经设置 TTL 且到期”的 Key。
• 内存淘汰：处理“内存达到 maxmemory 上限”时如何腾空间。

一、过期键删除策略

Redis 不是给每个 Key 挂一个独立定时器，而是“惰性删除 + 定期删除”组合。

1. 惰性删除
   • 访问 Key 时才检查是否过期；过期则即时删除并返回空。
   • 优点：省 CPU；缺点：若长期不访问，过期键会暂留内存。
2. 定期删除
   • 后台周期任务随机抽样过期字典中的 Key（默认 hz=10，每秒多次执行）。
   • 若抽样中过期比例较高，会继续多轮清理，但受时间片约束，避免阻塞主线程。
   • 本质：在 CPU 成本与内存回收效率之间做平衡。
3. Lazy Free
   • 针对大 Key 删除场景，可把内存释放交给后台线程，减少主线程长阻塞。
   • 常见于包含大量元素的 List/Hash/Set/ZSet。

二、内存淘汰策略（maxmemory-policy）

类别	策略	说明
不淘汰	noeviction	写请求报错，读请求可继续
仅过期键	volatile-lru / volatile-lfu / volatile-random / volatile-ttl	只在设置了过期时间的 Key 里淘汰
全量键	allkeys-lru / allkeys-lfu / allkeys-random	在所有 Key 范围内淘汰

三、核心算法：LRU vs LFU

• LRU：淘汰“最近最少使用”数据。Redis 采用近似 LRU（抽样）而非全量链表，降低维护成本。
• LFU：淘汰“使用频率最低”数据。Redis 用近似计数与衰减机制，避免热点历史长期霸占缓存。

四、如何选（实战）

场景	推荐策略	原因
通用纯缓存	allkeys-lru	简单稳妥，保留近期活跃数据
热点访问分层明显	allkeys-lfu	更擅长保留高频热点
核心数据不可淘汰（不设 TTL）	volatile-lru/volatile-lfu	只淘汰设置过期时间的数据
强时效数据	volatile-ttl	优先清掉最接近过期的数据

1. 缓存穿透——“查无此人”

• 现象：请求的数据在 Redis 不存在，在数据库也不存在，请求每次都直达 DB。
• 常见原因：恶意攻击（构造不存在 ID）、参数校验缺失、业务逻辑漏洞。
• 核心风险：缓存层形同虚设，数据库被持续消耗。

解决方案

• 布隆过滤器（优先）：在缓存前增加“存在性校验层”。若判定不存在，直接拒绝请求，不访问 Redis/DB。
• 缓存空值（兜底）：DB 未命中时写入空对象（如 NULL 占位）并设置短 TTL（常见 1~5 分钟）。
• 入口防护：参数合法性校验 + 网关限流，减少无效流量进入核心链路。

2. 缓存击穿——“热点瞬时失守”

• 现象：某个热点 Key 在过期瞬间，大量并发同时回源数据库。
• 特点：是“单点热点”问题，不是全局问题。
• 核心风险：DB 在短时间内被热点流量打爆。

解决方案

• 互斥锁 / SingleFlight：缓存失效后只允许一个请求回源重建缓存，其他请求等待或快速失败重试。
• 逻辑过期（推荐热点场景）：
  • 数据不做物理过期（或设置较长 TTL），在 Value 内维护逻辑过期时间。
  • 读取到逻辑过期时，先返回旧值保障可用性，再异步刷新缓存。
• 热点预热：在活动前预加载关键热点数据，降低首波回源压力。

3. 缓存雪崩 ——“大面积同时失效”

• 现象：大量 Key 在同一时间过期，或 Redis 实例故障，导致请求集体回源 DB。
• 核心风险：数据库与下游服务连锁雪崩。

解决方案

• TTL 随机抖动（Jitter）：过期时间打散（如 30 分钟 ± 1~5 分钟），避免同一时刻集中失效。
• 多级缓存：本地缓存（如 Caffeine） + Redis，Redis 故障时本地缓存可短时兜底。
• 高可用部署：采用 Sentinel 或 Cluster，降低单点故障概率。
• 保护机制：熔断、限流、降级，确保故障可控并快速止损。

4. 三者对比（面试高频）

问题	核心矛盾	典型特征	优先方案
穿透	数据本身不存在	请求持续穿过缓存	布隆过滤器 + 空值缓存
击穿	热点 Key 失效瞬时并发	单热点流量洪峰	互斥锁 / 逻辑过期
雪崩	大批 Key 同时失效或 Redis 故障	全局流量回源	TTL 抖动 + 多级缓存 + 高可用

1. 分布式锁要解决什么问题？

• 目标：在分布式多实例下，保证“同一时刻只有一个节点执行关键代码”。
• 典型场景：防重复下单、库存扣减、定时任务互斥、幂等控制。
• 四个关键属性：互斥性、可重入、超时释放、可恢复（故障后不永久死锁）。

2. Redis 原生实现：SET NX PX + Lua

最小可用方案是使用原子命令抢锁，再用 Lua 原子释放：

• 加锁：SET lock_key requestId NX PX 30000
• 含义：
  • NX：仅当 key 不存在才设置成功（抢锁）
  • PX 30000：30 秒自动过期，避免进程崩溃导致死锁
  • requestId：唯一标识（UUID/雪花 ID），用于“谁加锁谁解锁”
• 解锁必须 Lua：先比对 requestId 再删除，保证原子性，防止误删他人锁。

3. 为什么只写 SET NX 还不够？

• 不可重入：同一线程再次进入临界区会把自己锁死。
• 续期困难：业务超过 30 秒，锁提前过期，可能并发执行。
• 等待成本高：手写 while 重试易造成无效轮询与抖动。
• 主从切换风险：异步复制窗口下，主挂掉可能出现“锁状态丢失”。

4. Redisson 的工业级做法

① 可重入锁（Reentrant）

• 内部用 Hash 记录 客户端ID:线程ID -> 重入次数。
• 同一线程重复加锁时只递增计数，释放时递减到 0 才真正删锁。

② Watch Dog 自动续期

• 默认租期 30s；若业务未结束，后台定时续期（常见每 10s 续一次）。
• 好处：避免“业务没执行完，锁先过期”。
• 安全性：进程宕机后看门狗停止，锁最终会自然过期释放。

③ 阻塞等待优化（Pub/Sub）

• 未拿到锁的线程不必高频自旋，可通过订阅解锁通知再竞争。
• 相比纯轮询，能减少 Redis 压力与 CPU 空转。

④ 高可用策略：MultiLock / Redlock（按场景选）

• MultiLock：组合多个独立锁，全部成功才算成功，强调一致约束。
• Redlock 思路：对 N 个独立主节点加锁，超过半数成功才算成功（如 5 取 3）。
• 实践建议：Redlock 适合对锁正确性要求极高的场景，但复杂度与运维成本更高。

5. 自建方案 vs Redisson 对比

维度	自建 SET NX PX	Redisson（推荐）
实现复杂度	看似简单，细节易踩坑	开箱即用，语义完整
可重入	默认不支持	原生支持
自动续期	需自行实现	Watch Dog 内建
等待机制	多为轮询重试	支持通知唤醒，降低空转
主从故障容错	需手动设计	支持 MultiLock / Redlock 能力

6. 实战建议

• 简单互斥任务（短任务、可容忍少量风险）：SET NX PX + requestId + Lua 足够。
• 核心交易链路（高并发、长事务、强一致需求）：优先成熟库（如 Redisson 思路实现）。
• 锁不是万能：要结合幂等键、状态机、重试退避、超时与告警一起设计。

1. 定位：

Redis 事务更像“把多条命令打包后按顺序执行”，而不是关系型数据库那种完整 ACID 事务。核心价值是减少 RTT（往返时延-从你发出一个请求开始，到你收到服务器响应为止，中间经历的总时间。）、保证队列串行执行，而不是提供复杂回滚能力。

2. Redis 事务四个核心命令

• MULTI：开启事务，后续命令不立即执行，只入队。
• 命令入队：每条命令返回 QUEUED，表示进入事务队列。
• EXEC：一次性按顺序执行队列中的所有命令。
• DISCARD：放弃事务，清空队列。

3. Redis vs MySQL：ACID 维度对比

特性	Redis 事务	关系型数据库（MySQL）
原子性（A）	有限原子性：队列整体提交，但运行时错误不回滚	完整原子性：失败可全量回滚
一致性（C）	可保证协议与数据结构层面一致	依赖约束/日志/回滚实现强一致
隔离性（I）	命令执行阶段串行，不被插队	依赖隔离级别（RC/RR/Serializable）
持久性（D）	取决于 RDB/AOF 策略	依赖 Redo Log，持久性更强
回滚机制	无自动回滚	支持 Rollback

5. WATCH 机制：

• 本质：有时候你怕在“命令入队”到“exec执行”这段时间，别人偷偷改了你的数据。 比如你要买最后一件衣服： 你先 WATCH（盯着）这件衣服的库存。 开启事务，准备下单。 如果在你喊exec执行之前，别人先把这件衣服买走了（库存变了），Redis 会发现你盯的东西动过了，于是直接作废你的整个订单，保护你不买错。
• 流程：先 WATCH 关键 Key，再 MULTI 入队，最后 EXEC 提交。
• 冲突处理：若 EXEC 前被 WATCH 的 Key 被别人改动，EXEC 返回空结果（事务失败），由业务侧重试。

6. 什么时候该用 Redis 事务？

• 适用：多命令打包、减少网络往返、简单并发控制。
• 不适用：强一致资金类场景（需要严格回滚与复杂约束）。

7. 进阶方案：Lua 脚本才是复杂原子操作首选

• 事务内无法“先读结果再决定后续命令”，Lua 可以把“读 + 判断 + 写”放在同一原子单元执行。
• 执行 Lua 时 Redis 主线程串行处理，脚本期间不会插入其他命令。
• 分布式锁释放、库存扣减、限流器等典型场景通常优先 Lua。

结论

Redis 主从复制用于高可用与读写分离，本质是：主库持续产生命令流，从库通过 PSYNC + repl_backlog 尽量做“断点续传”；续不上时再回退到全量同步。

1) 三个核心标识

• Replication ID（runid）：主库复制流身份标识，主库重启或角色切换后可能变化。
• Offset：复制流位点；主从都记录“同步到哪一字节”。
• Replication Backlog：主库内存中的环形缓冲区，保存最近一段写命令字节流，用于部分重同步。

2) 全量同步（Full Resync）— 从零开始

1. 从库首次接入，发送 PSYNC ? -1（未知 runid 和 offset）。
2. 主库触发 BGSAVE 生成 RDB 快照。
3. 主库发送 RDB 给从库；从库加载 RDB 重建数据集。
4. RDB 传输期间主库仍在接收写请求，这些增量会被暂存。
5. RDB 加载完成后，主库补发这段期间的增量命令，从库追平后进入稳定复制。

3) 增量同步（Partial Resync）— 断点续传

1. 从库短暂断线后重连，发送 PSYNC <runid> <offset>。
2. 主库检查 backlog 是否仍保留该 offset 之后的数据。
3. 若命中，主库仅回放缺失片段，从库快速追平，无需重传全量 RDB。

4) 为什么增量会退化为全量

• backlog 覆盖：从库掉线太久，所需增量已被环形缓冲区覆盖。
• runid 失配：主库重启/切换后复制流身份变化。
• 首次接入：新从库没有可续传位点。

5) 全量 vs 增量对比

维度	全量同步（Full Sync）	增量同步（Partial Sync）
触发时机	首次同步 / 续传失败	短时断线重连且 backlog 命中
核心媒介	RDB 快照 + 后续增量	backlog 中的缺失命令
资源开销	高（磁盘、网络、加载成本）	低（仅补缺失片段）
一致性	最终一致	最终一致（通常延迟更小）

6) 生产建议（DreamLog 可直接用）

• 适当调大 repl-backlog-size（如 10MB+，按写入峰值评估），减少“掉线即全量”的概率。
• 监控复制延迟、全量同步次数与 backlog 命中率，提前发现网络抖动或容量不足。
• Redis 主从是异步复制；强一致链路（如扣费）建议读写主库或加业务幂等与校验。

结论

Sentinel 就是 Redis 主从架构的“智能管家团”：持续监控主从健康状态，一旦主库故障就自动完成选主和切换，并对客户端提供最新主库地址。

1) Sentinel 核心职责

职责	作用
监控（Monitoring）	持续检查主从节点是否可达、复制是否正常
通知（Notification）	发现异常后向运维系统与客户端发出事件通知
自动故障转移（Failover）	主库故障时自动挑选新主并重组复制拓扑
配置提供（Config Provider）	客户端可向 Sentinel 查询“当前主库是谁”

2) 如何判定主库“真的挂了”

• 主观下线：哨兵会每秒向它监控的所有节点（主库、从库、其他哨兵）发送一个 PING。如果某个节点在连续 down-after-milliseconds 时间内都没有给出一个有效的回复（比如 PONG 或加载中的错误），哨兵就会在心里给它打个标记：主观下线 (Subjective Down, SDOWN)。
• 客观下线：该 Sentinel 向其他 Sentinel 发起确认，达到 quorum 法定票数后，才认定“集体确认主库故障”。基于raft算法，哨兵会选举出一个leader，由leader来负责故障转移。

3) 故障转移：两次选举

第一步：选 Leader Sentinel

1. 多个 Sentinel 先投票选一个 Leader
2. Leader 才有资格执行后续 failover，避免多个 Sentinel 并发抢着切换。

第二步：选新主 Replica

Leader 会在候选从库中按规则筛选，常见优先级顺序：

1. replica-priority：值越小优先级越高（0 表示不参与晋升）。
2. 复制偏移量（offset）：越接近旧主数据，越优先。
3. runid：前两项相同则按 runid 决定最终人选。

4) 选主后执行三件事

1. 对新主发送 SLAVEOF NO ONE，使其晋升为 Master。
2. 通知其余从库复制新主，完成拓扑重组。
3. 旧主若恢复上线，会被降级并挂到新主之下。

5) 关键参数（面试常追问）

• sentinel monitor：定义监控主库与 quorum。
• down-after-milliseconds：主观下线判定窗口。
• failover-timeout：故障转移阶段超时控制。
• parallel-syncs：故障后并行重建从库复制的并发数。

为什么需要 Cluster

Sentinel 解决的是“高可用切主”，而 Redis Cluster 解决的是“横向扩展 + 高可用”。当单机内存放不下、写入并发持续上涨时，Cluster 通过分片把数据拆到多台机器上。

1) 核心原理：16384 哈希槽

• 集群固定有 16384 个槽（0~16383）。
• Key 映射规则：slot = CRC16(key) % 16384。
• 每个 Master 负责一部分槽，Key 会被路由到槽所属 Master。

例如 3 主节点时可近似分配：A(0~5460)、B(5461~10922)、C(10923~16383)。

2) 为什么是 16384（面试经典追问）

• 心跳包瘦身（最核心）：Cluster 节点会持续交换 Ping/Pong 心跳，里面包含槽位信息（bitmap）。
  • 16384 槽对应位图大小：16384 / 8 = 2048B（约 2KB）。
  • 若改为 65536 槽，位图变为 8KB，单包立刻增加约 6KB。（在计算机底层，最小的存储单位是 Bit（位），它只能存 0 或 1。 而我们常用的内存计量单位是 Byte（字节）。 1 Byte = 8 Bits）
  • 在多节点高频心跳下，这个差值会被放大成显著网络与解析成本。
• 规模够用且灵活：Redis Cluster 的典型设计上限在百到千级节点，16384 槽已能提供足够细的迁移粒度。
• 为什么不是更小（如 1024）：槽数太少会让分片粒度变粗，节点增多后更难均衡，迁移弹性也变差。

3) 扩容（新增节点）怎么做

1. 把新节点加入集群（初始不持有槽）。
2. 执行 reshard，从旧节点迁移一部分槽到新节点。
3. 迁移期间 Key 逐步搬迁，业务不中断。

4) 缩容（下线节点）怎么做

1. 先把目标节点的所有槽迁移到其他在线节点。
2. 确认槽清空后，再将该节点安全移出集群。

5) 客户端重定向：MOVED vs ASK

返回	含义	客户端动作
MOVED	槽已永久迁移到新节点	更新本地槽路由缓存，后续直接请求新节点
ASK	槽正在迁移中的临时重定向	先对目标节点发 ASKING，本次请求转发过去

6) 故障发现与自动切换

• Cluster 内置故障检测与投票机制（不依赖 Sentinel）。
• Replica 是什么：Replica 就是某个 Master 的“从节点/副本节点”，持续复制该 Master 的数据，不负责主写流量，主要用于容灾与读扩展。
• 晋升含义：当 Master 故障时，集群会从它的 Replica 中选一个提升为新 Master，继续接管原 Master 的槽位与写请求。
• 若某主分片“主从都不可用”，在默认配置下集群可能进入 FAIL 状态保护一致性。

架构图：