基础原理高频面试题（持久化、淘汰机制、IO模型）
本文按面试频率由高到低整理三大核心模块，包含基础概念、原理、区别、踩坑点、生产实践，全部为大厂高频考题，答案适配面试口述场景。
一、Redis 持久化
Redis 是内存数据库，数据默认驻留内存，宕机 / 断电会丢失全部数据。持久化就是将内存数据落地到磁盘，实现数据备份、宕机恢复、主从同步。Redis 提供 RDB、AOF、混合持久化三种方案。
（一）基础概念 & RDB 快照
Redis 为什么需要持久化？
防止进程崩溃、机器断电导致内存数据永久丢失；
实现数据定时备份、异地容灾；
主从复制全量同步、集群扩容依赖持久化文件传输数据。
什么是 RDB？触发方式有哪些？
RDB（Redis Database）即快照持久化：在某个时间点，将内存全量数据以二进制快照写入磁盘，文件后缀 .rdb。
触发方式分为三类：
手动触发
SAVE：主线程直接执行快照，全程阻塞所有客户端，生产禁止使用。
BGSAVE：主线程调用 fork() 创建子进程，由子进程完成快照写入，主线程正常处理请求，是主流手动方式。
自动触发配置 save 秒数 修改次数，例如 save 900 1：900 秒内有至少 1 个 Key 被修改，自动执行 BGSAVE。
隐性触发主从复制全量同步、SHUTDOWN 正常关闭（未禁用持久化）也会自动生成 RDB。
SAVE 和 BGSAVE 核心区别？fork 子进程的问题？
进阶考点：fork & 写时复制 COW
fork 创建子进程时，主线程会短暂阻塞（创建进程、复制内存页表），Redis 内存越大，阻塞时间越长。
父子进程初始共享内存页；当主线程修改数据时，会触发写时复制 (COW)，复制对应内存页给子进程，保证快照数据一致性。
极端场景下，COW 会导致服务器内存占用翻倍，高内存实例风险更高。
RDB 优缺点
优点
- 二进制文件体积小，适合备份、数据迁移；
- 重启恢复速度极快（直接加载二进制快照）；
- 周期执行，磁盘 IO 开销低。
缺点
- 数据丢失风险高：两次快照之间的新增数据会全部丢失；
- 大数据量下，fork + COW 消耗 CPU、内存资源；
- 无法实现实时 / 秒级持久化。
（二）AOF 日志持久化
什么是 AOF？工作原理？
AOF（Append Only File）即日志持久化：只记录 Redis 执行的所有写命令（读命令不记录），以文本形式追加到 .aof 文件；重启时重放日志恢复数据。
流程：写命令执行成功 → 写入 AOF 内存缓冲区 → 根据刷盘策略落地磁盘。
AOF 三种刷盘策略（appendfsync）【必考】
控制缓冲区数据从内存页缓存真正刷入磁盘的时机，共 3 种配置：
appendfsync always每一条写命令执行完立刻刷盘。数据零丢失，但性能极差，线上几乎不用。
appendfsync everysec（默认配置）每秒统一刷一次盘。性能与安全性平衡，宕机最多丢失 1 秒数据，生产首选。
appendfsync no交由操作系统内核自主决定刷盘时机。性能最好，但宕机可能丢失数秒数据，安全性最低。
AOF 重写（Rewrite）是什么？为什么要重写？
背景
AOF 持续追加命令，文件会无限膨胀（例如多次 incr key 会重复记录多条命令），导致磁盘占用高、重启恢复变慢。
AOF 重写定义
Redis 遍历当前内存数据，生成精简版最小命令集，替换旧的大 AOF 文件，本质是日志压缩。
触发方式
- 自动重写：配置文件设置文件大小阈值，达到条件自动触发；
- 手动重写：执行 bgrewriteaof 命令。
重写执行流程
主线程 fork 子进程，子进程遍历内存生成新 AOF 临时文件；
主线程正常处理请求，新的写命令存入AOF 重写缓冲区（防止增量数据丢失）；
子进程重写完成后，主线程把缓冲区命令追加到新文件；
原子替换旧 AOF 文件，后续命令追加到新文件。
AOF 优缺点
优点
- 数据安全性高，默认策略最多丢失 1 秒数据；
- 纯文本日志，可人工查看、简单修复。
缺点
- 同等数据量下，文件体积远大于 RDB；
- 恢复速度慢（需要逐条重放命令）；
- 持续刷盘、定期重写，磁盘 IO 开销更高。
（三）混合持久化 & 方案选型
混合持久化（Redis 4.0+ 新增）【线上最优方案】
开启配置：aof-use-rdb-preamble yes（默认开启）。
原理AOF 重写时，新文件分为两部分：
文件头部：当前全量数据以 RDB 二进制快照写入；
文件尾部：重写期间的增量写命令，以标准 AOF 日志追加。
恢复逻辑：先加载头部 RDB 快照快速恢复全量数据，再重放尾部增量命令。
优缺点
- 优点：兼顾 RDB 恢复快、AOF 数据安全的双重优势，文件体积大幅缩小；
- 缺点：文件是二进制 + 文本混合格式，无法人工编辑。
RDB vs AOF 对比 & 生产选型
表格
|
对比维度
|
RDB
|
AOF
|
生产使用
|
|
存储格式
|
二进制快照
|
命令日志文本
|
仅测试 / 极小数据量
|
|
数据丢失
|
可能丢失大量数据
|
最多丢失 1 秒（默认）
|
生产默认
|
|
文件体积
|
小
|
大
|
|
|
恢复速度
|
极快
|
较慢
|
|
|
IO 开销
|
低（周期执行）
|
高（持续追加 + 重写）
|
|
|
安全性
|
低
|
高
|
|
生产实践方案
允许少量数据丢失、仅做冷备份 / 迁移：单用 RDB；
金融 / 订单等数据零容忍丢失场景：单用 AOF；
通用业务首选：开启混合持久化（RDB+AOF 结合），同时定时手动备份 RDB 文件。
重启加载文件优先级
Redis 重启优先加载 AOF 文件，没有 AOF 文件才会加载 RDB。原因：AOF 数据完整性更高。
二、Redis 内存淘汰机制
Redis 数据全存内存，物理内存有限。通过 maxmemory 限制 Redis 最大可用内存，内存达到上限后，触发内存淘汰策略。
触发条件 & 核心配置
maxmemory <字节数>：设置 Redis 最大可用内存（生产必须配置，否则会耗尽服务器内存引发 OOM）；
内存占用达到 maxmemory 阈值，新写请求无法分配内存，执行淘汰策略；
maxmemory-policy：指定具体淘汰规则。
8 种内存淘汰策略【必背】
分为两大前缀：
- volatile-xxx：仅淘汰设置了过期时间的 Key，永久 Key 不会被删除；
- allkeys-xxx：淘汰所有 Key（无论是否过期）。
完整 8 种策略：
noeviction（默认）：不淘汰任何 Key，内存满后拒绝所有写请求，返回 OOM 错误。生产严禁使用。
volatile-lru：从有过期时间的 Key 中，淘汰最近最少使用 (LRU) 的 Key。
allkeys-lru：从所有 Key 中，淘汰最近最少使用的 Key。互联网通用业务首选。
volatile-lfu：从有过期时间的 Key 中，淘汰访问频率最低 (LFU) 的 Key（Redis4.0+）。
allkeys-lfu：从所有 Key 中，淘汰访问频率最低的 Key。适合冷热数据分明场景。
volatile-random：从有过期时间的 Key 中随机删除。
allkeys-random：从所有 Key 中随机删除。
volatile-ttl：从有过期时间的 Key 中，优先删除剩余存活时间最短的 Key。
LRU 机制详解（高频追问）
什么是 LRU？
LRU（Least Recently Used）：最近最少使用。核心思想：长期未访问的 Key，后续访问概率也极低，优先淘汰。
Redis 是标准 LRU 吗？
不是，Redis 实现的是 近似 LRU（采样 LRU）。原因：
标准 LRU 需要维护全局有序链表记录所有 Key 的访问时间，内存、CPU 开销大；
Redis 采用随机采样：每次淘汰时随机选取 maxmemory-samples 个 Key，在样本中淘汰最久未使用的 Key；
采样数越大，越接近标准 LRU，性能开销也越高。
LFU 机制 & LRU/LFU 区别
什么是 LFU？
LFU（Least Frequently Used）：最少访问频率。优先淘汰被访问次数最少的 Key；Redis 会为 Key 维护访问计数器，并支持计数器自动衰减，避免老旧冷门 Key 计数虚高。
两者区别 & 适用场景
- LRU：关注最后访问时间，适合热点相对稳定的通用缓存（商品、用户信息）；
- LFU：关注访问频次，适合存在临时热点、一次性活动数据的场景。
生产策略选择建议
绝大多数缓存业务：allkeys-lru（最优平衡）；
冷热数据差异大、存在临时热点：allkeys-lfu（Redis4.0+）；
存在永久核心数据（不能删除）：选用 volatile 系列；
绝对禁用默认 noeviction。
延伸：大 Key 对淘汰机制的影响
删除大 Key 会阻塞单线程主线程，引发请求卡顿、超时；
优化方案：拆分大 Key、开启异步删除 lazyfree-lazy-eviction yes（Redis4.0+），让后台线程处理 Key 删除。
三、Redis IO 模型 & 单线程模型
这是面试灵魂考题，核心误区：Redis 不是全程单线程，命令执行、网络 IO 主线程单线程，持久化、异步删除等由子进程 / 后台线程处理。
为什么 Redis 核心采用单线程？【大题，必背】
规避多线程锁开销Redis 数据结构复杂，多线程读写需要加锁，会带来锁竞争、线程上下文切换，严重降低性能；单线程天然无线程安全问题。
CPU 不是瓶颈Redis 是内存数据库，命令执行速度极快，瓶颈集中在网络 IO，而非 CPU 运算。
代码简洁、稳定性高单线程逻辑简单，BUG 更少，维护成本低。
结合 IO 多路复用，支撑高并发单线程配合多路复用，可同时监听上万客户端连接，并发能力极强。
补充：Redis 6.0 引入IO 多线程，仅负责网络读写、协议解析，命令执行依旧是单线程，保证线程安全。
单线程 / 多线程分工（纠正误区）
单线程（主线程，核心）
监听 Socket、接收连接、解析命令、执行命令、返回响应。
多线程 / 子进程 / 后台任务
子进程：RDB 快照、AOF 重写（fork 创建，属于进程）；
后台线程（4.0+）：异步删除 lazyfree（大 Key、过期 Key、淘汰 Key）；
IO 多线程（6.0+）：网络数据读写、协议解析；
定时任务线程：过期 Key 清理、集群心跳、持久化辅助任务。
IO 多路复用 原理
概念
一个线程通过一个监听对象，同时监听多个客户端 Socket 连接。只有当某个连接有读写事件就绪时，线程才去处理，无需轮询所有连接，实现单线程管理上万并发连接。
通俗比喻：一个前台（单线程）同时看管多个窗口，哪个窗口有请求就处理哪个。
Redis 支持的多路复用模型（按系统自动选择）
- Linux：epoll（性能最优，Redis 主力）；
- Mac/BSD：kqueue；
- Windows：select；
- 通用兼容：poll。
Redis 事件驱动模型
基于 Reactor 模型，主线程处理两类事件：
文件事件（IO 事件）：客户端连接、读命令、写响应，依赖 IO 多路复用；
时间事件：定时任务，如过期 Key 清理、定时持久化、集群心跳。
单线程 Redis 的性能瓶颈 & 优化方案
主要瓶颈
慢命令阻塞：串行执行命令，keys、hgetall、长 Lua 脚本、大事务会阻塞全局请求；
大 Key 操作：删除 / 修改大 Key 耗时久，阻塞主线程；
fork 阻塞：内存过大时，fork 创建子进程耗时变长；
高并发下网络 IO 压力。
优化方案
禁用高危慢命令，用 scan 替代 keys，限制 Lua 脚本执行时长；
拆分大 Key，开启异步删除 lazyfree；
控制单实例内存（建议≤10G），减少 fork 阻塞；
Redis6.0+ 开启 IO 多线程，提升网络吞吐；
数据分片集群，水平分摊压力；
开启慢查询日志 slowlog，持续监控慢命令。
单线程为什么没有线程安全问题？
所有客户端命令串行执行，同一时刻只会处理一条命令，不存在多线程并发修改数据的场景，因此无需加锁，天然保证线程安全。
延伸：过期 Key 删除策略（关联单线程）
Redis 采用组合策略处理过期 Key：
惰性删除：访问 Key 时才检查过期，过期则删除。优点：不占用 CPU；缺点：无效 Key 长期占用内存。
定期删除：主线程定时随机抽样检查、删除过期 Key，平衡 CPU 与内存。
异步删除（4.0+）：过期 Key 交由后台线程删除，避免阻塞主线程。
默认组合：惰性删除 + 定期删除，生产建议开启异步删除。
四、综合场景面试题（三合一考点）
线上 Redis 数据丢失，可能是什么原因？
仅开启 RDB：丢失两次快照之间的数据；
AOF 刷盘策略配置为 no：内核未及时刷盘；
AOF 默认 everysec：宕机刚好丢失 1 秒数据；
未开启任何持久化。
线上 Redis 内存打满、写失败如何排查？
检查 maxmemory 和淘汰策略，确认不是默认 noeviction；
排查大 Key、无效过期 Key；
开启异步删除，拆分大 Key；
集群分片扩容，分摊内存压力。
线上标准持久化配置方案？Redis4.0+ 开启混合持久化 + AOF everysec 刷盘，配合定时脚本备份 RDB 文件。
分布式架构面试题（主从、哨兵、集群核心原理）
本文按主从复制 → 哨兵 (Sentinel) → Redis 集群 (Cluster) 三大模块整理，包含基础概念、核心原理、高频面试题 + 标准答案、经典追问、踩坑点，完全对标一线 Java / 后端面试，由浅入深。
一、Redis 主从复制（Replication）
基础概念 & 核心作用
面试题 1：什么是 Redis 主从复制？有什么作用？
答案：主从复制是 Redis 实现数据多副本的基础架构，采用一主多从模式：
- 主节点 (master)：负责接收客户端写请求，同时将数据同步给从节点；
- 从节点 (replica/slave)：默认只读，不处理写请求，持续同步主节点数据。
核心作用：
读写分离：主节点扛写、从节点扛读，提升整体并发能力；
数据热备份：多个副本防止单节点数据丢失；
高可用基础：主从是哨兵、集群实现故障转移的前置架构；
负载均衡：分担主节点压力。
补充：Redis 5.0 后废弃 slaveof 命令，统一使用 replicaof，功能完全一致。
面试题 2：主从架构默认是多少个节点？从节点能否写数据？
答案：无强制数量限制，常规一主一从、一主多从；从节点默认只读，可通过 replica-read-only no 手动开启写，但生产绝对不推荐，会造成主从数据双向冲突。
主从复制核心原理（面试重中之重）
Redis 2.8 是分水岭，分为旧版全量复制和新版 全量复制 + 部分重同步，目前线上均使用 2.8+ 版本。
核心三大组件（必背）
复制偏移量 (offset)：主 / 从节点各自记录当前已同步的命令字节位置，双方偏移量一致代表数据完全同步；
复制积压缓冲区 (repl_backlog)：主节点环形缓冲区，记录近期已同步的写命令（固定大小），用于断线后部分重同步；
运行 ID (runid)：每个 Redis 节点启动后生成唯一 40 位 ID，标识节点身份。
面试题 3：新版主从复制完整流程（全量 + 增量）
完整步骤：
建立 TCP 连接从节点执行 replicaof master_ip port，主动和主节点建立长连接。
握手认证双方协商复制版本、密码、端口，从节点发送心跳，主节点确认身份。
全量数据同步（RDB）
主节点执行 bgsave 生成 RDB 快照文件；
生成 RDB 期间，主节点将新的写命令写入复制积压缓冲区；
主节点把 RDB 文件全量发送给从节点；
从节点清空本地原有数据，加载 RDB 文件。
缓冲区命令补发RDB 加载完成后，主节点把缓冲区中积压的写命令逐一向从节点同步。
增量命令传播（持续同步）全量同步完成后进入长轮询：主节点每执行一条写命令，立即异步转发给所有从节点，保持实时同步。
面试题 4：什么是部分重同步？和全量重同步的区别？什么时候触发？
答案：针对从节点短暂断线重连的优化机制，避免每次断线都全量拷贝 RDB。
触发规则：
部分重同步（增量同步）满足两个条件则触发：
从节点断线时间短，自身偏移量仍存在于主节点的复制积压缓冲区中；
主节点运行 ID (runid) 未改变（主节点未重启）。流程：从节点上报偏移量 → 主节点从缓冲区补发缺失命令，无需生成 RDB。
全量重同步（两种场景必触发）
从节点断线太久，偏移量已被缓冲区覆盖；
主节点重启 / 宕机恢复，runid 改变，从节点判定为新主节点，强制全量同步。
面试题 5：主从复制是同步还是异步？优缺点？
答案：Redis 默认 异步复制：
- 主节点执行完写命令，立刻返回结果给客户端，不等从节点同步完成；
- 优点：主节点写入性能极高，无阻塞；
- 缺点：极端场景下主从存在数据延迟，主节点宕机可能丢失少量未同步数据，无法保证强一致性。
补充优化配置：min-replicas-to-write N，指定主节点至少有 N 个正常从节点，才允许接收写请求，降低数据丢失风险。
主从复制高频问题 & 踩坑
面试题 6：主从延迟产生的原因？如何优化？
原因：
主节点写入 QPS 极高，命令转发跟不上；
主从节点硬件性能差距大；
网络带宽 / 网络抖动；
从节点全量同步时 RDB 加载、持久化阻塞。
优化方案：
拆分读写压力，合理分配从节点数量；
主从节点硬件、网络配置对齐；
调大 repl_backlog_size 缓冲区，减少全量同步次数；
从节点关闭不必要的持久化（RDB/AOF），避免阻塞同步；
避免主节点执行 flushall/flushdb 等高危命令。
面试题 7：主节点宕机后，从节点会自动升级为主节点吗？
答案：不会。单纯主从复制没有故障转移能力，从节点只会原地等待，这也是哨兵架构出现的核心原因。
面试题 8：主节点执行 flushall，从节点数据会被清空吗？
答案：会。flushall 属于写命令，会正常同步到所有从节点，生产严禁随意执行。
二、Redis 哨兵（Sentinel）
基础概念 & 定位
面试题 1：什么是 Redis 哨兵？解决什么问题？
答案：哨兵是独立运行的轻量进程，基于「主从复制」搭建，专门解决主节点宕机后无法自动故障转移的问题，实现主从架构的高可用 (HA)。
三大核心功能：
监控：持续心跳检测主、从节点运行状态；
通知：节点异常时向运维 / 客户端发送告警；
自动故障转移：主节点宕机后，自动挑选从节点升级为新主，修改剩余从节点的复制指向。
面试题 2：哨兵集群为什么必须部署奇数个节点（3/5 个）？单机哨兵行不行？
答案：
不建议单机哨兵：哨兵本身是单点，若哨兵进程宕机，整个集群失去监控，无法故障转移；
奇数节点原因：哨兵使用投票机制判定节点下线、选举领头哨兵，奇数节点可避免平票，保证选举结果唯一；
生产标准架构：1 主 2 从 + 3 个哨兵。
哨兵默认端口：26379（Redis 服务端口 6379）。
哨兵核心原理（下线判定 + 故障转移）
面试题 3：主观下线 (SDOWN)、客观下线 (ODOWN) 区别？
高频考点，必区分
主观下线 SDOWN单个哨兵通过 PING 心跳，检测到某节点超时无响应，仅当前哨兵标记该节点为下线。只是单方判断，不可信。
客观下线 ODOWN（仅针对主节点）配置 quorum（法定票数），当至少 quorum 个哨兵都判定主节点主观下线，才标记为客观下线，正式确认主节点故障。
quorum 是哨兵核心配置，一般设置为哨兵节点数的一半 + 1。
从节点宕机只会标记主观下线，不会走客观下线流程。
面试题 4：主节点客观下线后，完整故障转移流程？（大厂常考大题）
完整 6 步流程：
主节点被标记为客观下线，确认故障；
选举领头哨兵：哨兵集群基于Raft 算法投票，选出 1 个领头哨兵，只有它负责执行故障转移；
挑选新主节点（挑选规则优先级从高到低）：
优先选择状态正常、网络连通的从节点；
优先 复制偏移量最大（数据最新）的从节点；
最后比较节点运行 ID，ID 最小者胜出；
领头哨兵向选中的从节点发送 replicaof no one，使其脱离原主，成为新主节点；
领头哨兵遍历所有剩余从节点，修改配置，让它们全部复制新主节点；
旧主节点恢复上线后，哨兵会强制将其改为新主的从节点，加入集群。
面试题 5：客户端如何连接哨兵架构的 Redis？
答案：客户端不直接硬编码主节点地址，流程：
客户端先连接哨兵节点，询问「当前有效主节点地址」；
哨兵返回最新主节点 IP + 端口；
客户端再连接真实主节点进行读写；
故障转移后，客户端重新向哨兵拉取新主地址，自动切换。
哨兵高频追问 & 踩坑
面试题 6：哨兵可以监控多套主从集群吗？
答案：可以。单个哨兵实例可同时监控多组独立的主从架构。
面试题 7：哨兵架构存在脑裂问题吗？如何规避？
答案：存在。脑裂：网络分区导致哨兵和原主节点失联，哨兵触发故障转移选出新主；但原主节点仍在接收写请求，出现两个主节点，数据分裂。
规避方案：
配置 min-replicas-to-write 限制主节点写入；
合理调大 sentinel-down-after-milliseconds 心跳超时时间，避免网络抖动误判下线；
保证哨兵集群网络稳定性。
面试题 8：哨兵和主从的关系？二者能不能独立使用？
答案：
- 哨兵依赖主从复制，不能脱离主从单独运行；
- 主从可以独立使用（仅做读写分离、备份），不需要哨兵。
三、Redis Cluster 集群（分片集群）
基础概念 & 定位
面试题 1：什么是 Redis Cluster？解决什么问题？
答案：Redis 3.0+ 正式推出的去中心化分片集群，是 Redis 官方原生分布式方案。
解决两大痛点：
容量瓶颈：单 Redis 节点内存有限，通过数据分片把数据分散到多个主节点，横向扩展存储；
并发瓶颈：读写请求分散到多个节点，提升整体吞吐；
集群内部集成了类似哨兵的故障转移机制，自带高可用，无需额外部署哨兵。
标准架构：3 主 3 从（最少 6 个节点），3 个主节点负责分片读写，每个主节点搭配 1 个从节点做备份。
面试题 2：Cluster 和 主从 + 哨兵 的选型区别？
答案：
- 主从 + 哨兵：数据全量存在每一个节点，适合数据量小、单节点可容纳，只需要高可用、读写分离的场景；
- Redis Cluster：数据分片存储，适合数据量大、单节点存不下、高并发，需要横向扩容的海量数据场景。
Cluster 核心原理（哈希槽、通信、重定向、故障转移）
面试题 3：什么是哈希槽 (Hash Slot)？总共有多少个槽？分配规则？
必考题
集群固定划分 16384 个哈希槽，编号 0 ~ 16383；
所有槽均匀分配给集群内主节点，从节点不分配槽，只做备份；
数据路由规则：对 key 做 CRC16 哈希 → 结果对 16384 取模 → 得到对应槽位 → 路由到该槽位所属主节点。
面试题 4：为什么哈希槽是 16384 个，不是 65536？（经典灵魂追问）
标准答案：
网络带宽考量集群节点间同步槽位信息使用位图存储：
16384 位 = 2KB，节点间频繁交换状态，带宽占用极小；
65536 位 = 8KB，带宽开销翻倍，无意义；
节点数量限制Redis 集群主节点建议不超过 1000 个，16384 个槽足够均匀分片；65536 槽过于冗余；
源码设计约定：Redis 作者最终选定 16384 作为固定值，槽数量无法修改。
面试题 5：集群节点之间用什么协议通信？端口是多少？
答案：
节点间使用 Gossip（八卦协议） 去中心化通信，节点之间互相同步槽位、上下线、主从状态；
集群总线端口 = Redis 服务端口 + 10000；例：服务端口 6379 → 集群通信端口 16379。
面试题 6：MOVED 和 ASK 重定向的区别？（高频区分题）
客户端访问集群核心两种重定向，场景完全不同：
|
类型
|
触发场景
|
客户端行为
|
|
MOVED
|
槽位永久迁移完成，槽位归属已彻底变更
|
客户端更新本地槽位映射表，后续直接访问新节点
|
|
ASK
|
槽位正在迁移中（部分 key 在源节点、部分在目标节点）
|
仅本次请求重定向，不更新本地映射，下次仍访问原节点
|
面试题 7：什么是哈希标签 (Hash Tag)？作用是什么？
答案：默认情况下，同一个业务的多个 key 会被分到不同槽位，导致跨槽位不支持事务、Lua、批量命令。
哈希标签用法：用 {} 包裹 key 的一部分，仅对大括号内内容做哈希计算，保证多个 key 落在同一个哈希槽。
示例：
- {user}:1、{user}:2、{user}:3 → 哈希值一致，同槽位；
- 作用：支持多 key 事务、mget/mset、Lua 脚本、管道等功能。
Cluster 故障转移 & 集群可用性
面试题 8：Cluster 主节点宕机，集群如何处理？集群什么时候彻底不可用？
答案：
主节点故障流程集群节点间心跳检测 → 主观下线 → 客观下线 → 从节点被选举为新主节点，接管原有哈希槽，集群继续对外提供服务。
集群彻底不可用条件（重点）当某一个哈希槽对应的所有主、从节点全部宕机，该槽位数据丢失，整个集群停止对外服务。
所以标准 3 主 3 从 架构：单个主 + 从同时宕机，集群直接挂掉。
面试题 9：Redis Cluster 支持事务、管道、多 key 命令吗？
答案：
事务：单槽位 key 支持事务；跨槽位 key 不支持事务（可用哈希标签规避）；
管道 (Pipeline)：智能客户端支持，但不建议跨节点使用；
多 key 命令：mget/mset/del 等跨槽位会报错，必须用哈希标签让 key 落在同一槽。
面试题 10：Cluster 是强一致性吗？主从复制逻辑和独立主从一样吗？
答案：
非强一致性：底层依旧是异步主从复制，存在数据延迟，主宕机仍可能丢失少量数据，最终一致性；
复制逻辑完全一致：Cluster 内部主从依然使用「全量复制 + 部分重同步 + 复制积压缓冲区」，和独立主从架构底层无区别。
Cluster 扩容 & 缩容简述
面试题 11：集群如何扩容（新增主节点）？
步骤：
启动新 Redis 节点，加入现有集群；
手动执行槽位迁移，把原有主节点的部分哈希槽迁移到新主节点；
可选：为新主节点添加从节点，保证高可用。
面试题 12：集群缩容（下线节点）？
步骤：
先把待下线主节点的所有哈希槽迁移到其他主节点；
槽全部迁移完成后，再下线该节点；
直接下线带槽位的主节点会导致集群不可用。
四、三大架构综合对比 & 面试总结
架构选型对照表
|
架构
|
核心能力
|
数据分布
|
高可用
|
适用场景
|
|
单纯主从
|
读写分离、数据备份
|
全量数据同步
|
无自动故障转移
|
数据量小、仅做备份 / 读写分离
|
|
主从 + 哨兵
|
读写分离 + 自动故障转移
|
全量数据同步
|
支持高可用
|
数据量不大、单节点可容纳、要求高可用
|
|
Redis Cluster
|
分片扩容 + 读写分离 + 内置高可用
|
数据分片存储
|
内置故障转移
|
大数据量、高并发、需要横向扩容
|
面试高频总结（背诵要点）
主从：异步复制、全量 / 部分重同步、偏移量 / 积压缓冲区 /runid，无自动故障转移；
哨兵：基于主从，奇数节点、主观 / 客观下线、Raft 选举、自动故障转移；
Cluster：16384 哈希槽、Gossip 协议、MOVED/ASK、哈希标签、分片扩容、槽全挂则集群不可用。
通用踩坑点
所有架构默认异步复制，都无法做到强一致性；
Cluster 跨槽位多 key 命令受限，优先使用哈希标签；
生产环境禁止单机哨兵、禁止 Cluster 主节点不配从节点。
缓存问题面试题（穿透/击穿/雪崩/一致性）标准答案
本文为互联网面试通用标准答案，分问题定义、产生原因、解决方案、优劣分析、面试追问、场景选型，区分初级回答（基础方案）、中高级回答（生产级方案 + 架构设计），可直接背诵。
一、缓存穿透
问题定义
查询数据库和缓存中都不存在的数据，请求绕过缓存直接打到数据库。高并发 / 恶意请求下，数据库压力剧增甚至被压垮。
典型场景 & 成因
正常业务：查询逻辑上不存在的数据（如已删除订单、非法 ID）；
恶意攻击：攻击者批量请求随机非法 Key（如 id=-1、超大随机 ID），缓存永远不命中；
根因：缓存未对空查询结果做处理，无效请求持续穿透至 DB。
全套解决方案（按优先级排序）
（1）接口层参数校验（前置拦截，成本最低，必做）
在网关、Controller 层做参数合法性校验：
- 限制 ID 为正整数、手机号 / 邮箱格式校验、参数范围拦截；
- 非法参数直接返回，不进入缓存查询逻辑。优点：零额外组件、性能无损；缺点：仅能拦截明显非法参数，无法应对合法但不存在的 Key。
（2）缓存空值 / 空对象（业务最常用，简单易落地）
查询 DB 发现数据不存在时，向缓存写入空值 / 自定义空对象，并设置较短过期时间（如 3~5 分钟）。
- 逻辑：同一条无效请求再次访问，直接命中缓存，不再查询 DB；
- 优化：空值 TTL 必须设短，避免大量空 Key 占用 Redis 内存。优点：实现简单、无架构侵入；缺点：恶意批量随机 Key 会产生大量空缓存，占用 Redis 空间。
（3）布隆过滤器 BloomFilter（大数据量、高防攻击首选）
在 Redis 之前部署布隆过滤器，提前加载全量合法数据的 Key：
客户端请求先经过布隆过滤器；
过滤器判断 Key 不存在 → 直接拦截，不查缓存和 DB；
判断存在 → 再走正常缓存 + DB 流程。
核心特性 & 面试考点：
- 只存在误判（把不存在的 Key 判定为存在），不会漏判（存在的 Key 一定能识别）；
- 误判可通过增大位数组、增加哈希函数数量降低；
- 传统布隆过滤器不支持删除，数据频繁删除场景改用计数布隆过滤器。
适用场景：商品、用户、账号等海量静态 / 少变更数据。
面试追问
Q：空缓存和布隆过滤器怎么选型？A：数据量小、攻击少 → 用缓存空值；海量数据、存在恶意刷接口 → 布隆过滤器。
二、缓存击穿
问题定义
单个热点 Key（高并发访问的 Key）缓存过期瞬间，海量并发请求同时绕过缓存，直接压向数据库。
核心区分：穿透是查不存在数据；击穿是查存在的热点数据，仅因缓存过期引发。
典型场景 & 成因
- 秒杀商品、首页爆款、热门榜单等热点数据；
- 热点 Key 统一设置 TTL，同一时刻集体过期；
- 根因：高并发 + 单个热点 Key 缓存失效。
全套解决方案（分场景选型）
（1）过期时间随机化（基础兜底方案）
给热点 Key 的 TTL 增加随机偏移值，例如：基础过期时间 1h + 0~10min 随机值。
- 作用：打散过期时间，避免多个热点 Key 同时失效；
- 定位：辅助方案，只能缓解，无法彻底解决极端单点热点击穿。
（2）分布式互斥锁（强一致性首选）
缓存失效时，只允许一个线程查询 DB 并更新缓存，其余线程等待重试，串行化避免并发打 DB。实现流程：
请求查询 Redis，缓存未命中；
尝试获取 Redis 分布式锁（SETNX + EXPIRE / Redisson）；
加锁成功 → 查询 DB → 写入缓存 → 释放锁；
加锁失败 → 短暂休眠后重试查询缓存。
注意事项：
- 锁必须设置过期时间，防止服务宕机引发死锁；
- 高并发场景下，锁会带来少量等待，略微降低吞吐量。
适用：对数据一致性要求高、不能容忍旧数据的业务。
（3）逻辑过期（热点高并发首选，主流方案）
不给 Key 设置物理过期时间（永不过期），而是在 Value 中存入逻辑过期时间。实现流程：
查询缓存，判断逻辑时间是否过期；
未过期 → 直接返回数据；
已过期 → 当前请求直接返回旧数据，同时启动一个异步线程去更新缓存。
优缺点：
- 优点：无锁、高并发、性能极强；
- 缺点：会短暂返回旧数据，数据存在短暂不一致。
适用：商品详情、首页推荐等允许短暂脏数据的超高并发热点场景。
面试追问
Q：分布式锁 vs 逻辑过期，如何选择？A：强一致性 → 分布式锁；超高并发、容忍短暂旧数据 → 逻辑过期。
三、缓存雪崩
问题定义
两种触发形式，影响范围远大于击穿：
大面积缓存 Key 同时过期：海量请求全部直达 DB，压垮数据库；
Redis 服务整体不可用（宕机、断网、集群故障）：缓存完全失效，流量全部打向 DB，引发连锁故障（服务雪崩）。
成因
批量 Key 设置相同 TTL，集体过期；
Redis 单点部署，无高可用，节点宕机；
未做限流、熔断，流量无兜底。
全套解决方案（分层防护：事前预防 → 事中应急 → 事后恢复）
第一类：解决「大量 Key 同时过期」引发的雪崩
TTL 随机化（基础必做）：打散所有 Key 过期时间，从源头避免集体失效；
核心热点 Key 永不过期：对 TOP 热点数据取消物理过期时间；
多级缓存架构（生产主流）：JVM本地缓存（Caffeine/Guava） + Redis分布式缓存流程：请求先查本地缓存 → 未命中再查 Redis → 最后查 DB。即使 Redis 大面积失效，本地缓存仍能承接绝大部分流量。缺点：多实例本地缓存存在数据短暂不一致。
第二类：解决「Redis 宕机 / 不可用」引发的雪崩（核心防线）
（1）Redis 高可用架构（事前预防，生产强制部署）
杜绝单点故障：
- 主从 + 哨兵（Sentinel）：主节点宕机，哨兵自动故障转移，从节点升级为主节点，保证服务可用；
- Redis Cluster 集群：分片集群，单个节点故障仅影响部分分片，支持扩容、自动故障转移，适合大数据量。
（2）限流 + 熔断 + 降级（最后兜底防线，事中应急）
借助 Sentinel、Hystrix、网关层实现：
- 限流：限制接口 QPS，防止海量恶意 / 突发流量涌入；
- 熔断：Redis/DB 压力过载时，直接切断请求，保护核心组件；
- 降级：非核心接口返回静态数据、默认提示页，优先保障核心业务运行。
（3）缓存预热（事前优化）
流量高峰、系统重启前，通过定时任务 / 脚本主动将热点数据加载进缓存，避免启动阶段缓存全空引发雪崩。
三者核心区别（面试必考题）
表格
|
问题
|
访问数据
|
触发原因
|
影响范围
|
|
缓存穿透
|
不存在的数据
|
缓存无空值、恶意请求
|
分散、持续打 DB
|
|
缓存击穿
|
单个热点存在数据
|
热点 Key 过期
|
单点高并发打 DB
|
|
缓存雪崩
|
大量存在数据
|
批量 Key 过期 / Redis 宕机
|
全量流量压垮 DB，服务瘫痪
|
四、缓存与数据库数据一致性
问题背景
读写并发场景下，Redis 缓存和 MySQL 数据库数据不一致（出现脏数据）。行业主流遵循 Cache-Aside（旁路缓存） 设计模式，分读逻辑、写逻辑，核心讨论「更新数据库」和「操作缓存」的先后顺序。
行业共识：优先删除缓存，而非更新缓存。频繁更新缓存会造成性能浪费，删除后由读请求主动回写更合理。
四种基础更新策略（优劣逐一分析）
方案 1：先更新数据库 → 再更新缓存
❌ 不推荐
- 并发问题：多线程同时更新 DB，后更新 DB 的线程反而先更新缓存，最终缓存被旧数据覆盖；
- 性能问题：写多读少场景，缓存频繁无效更新，浪费 Redis 资源。
方案 2：先更新缓存 → 再更新数据库
❌ 严禁使用缓存更新成功，但数据库更新失败 → 永久数据不一致，风险极高。
方案 3：先删除缓存 → 再更新数据库
❌ 不推荐严重并发漏洞：
线程 A（写）：删除缓存；
线程 B（读）：缓存未命中 → 查询 DB（旧数据）→ 写入缓存；
线程 A（写）：更新 DB（新数据）。结果：缓存永久存储旧数据。
方案 4：先更新数据库 → 再删除缓存（✅ 主流标准方案）
标准读写逻辑（旁路缓存）
- 读：查缓存 → 命中返回；未命中 → 查 DB → 写缓存 → 返回；
- 写：先更新 MySQL，再删除 Redis 缓存。
存在的并发漏洞 & 解决方案
漏洞描述：写线程更新 DB 后、删除缓存前，读线程查询到旧缓存，并把旧数据重新写入缓存，造成脏数据。
针对该漏洞的优化方案：
（1）延迟双删（最简单，中小项目首选）
流程：
先更新数据库；
第一次删除缓存；
延迟一段时间（根据业务耗时：500ms~1s）；
第二次删除缓存。
优化：将第二次删除改为异步延迟删除（线程池 / MQ），不阻塞主线程接口耗时。
（2）分布式锁（强一致性方案）
对同一个 Key 的读写请求加分布式锁，串行化执行，杜绝并发插队。缺点：牺牲部分并发性能。
高级生产级方案（高并发、大型分布式系统）
（1）缓存 TTL 兜底（所有方案必备）
无论采用哪种更新策略，所有缓存必须设置过期时间。即使出现短暂不一致，缓存过期后会自动从 DB 加载最新数据，保证最终一致性。
（2）MQ 异步删除缓存（高并发写场景）
流程：更新 DB → 发送消息到 MQ → 消费端异步删除缓存。
- 优点：解耦、异步、不阻塞主流程，支持消息重试，可靠性高；
- 缺点：存在毫秒 / 秒级数据延迟，容忍短暂不一致。
（3）Canal 监听 MySQL Binlog（大厂主流方案）
业务代码正常更新 MySQL；
Canal 伪装成 MySQL 从库，监听 Binlog 日志，捕获数据变更；
Canal 推送变更事件，程序收到后自动删除 / 更新对应缓存。
- 优点：完全解耦业务代码，实时性好、可靠性高；
- 缺点：架构复杂，需要维护 Canal、Binlog，运维成本高。
（4）主从架构额外问题（读写分离场景）
若 MySQL 做主从分离（写主、读从），存在主从同步延迟：更新主库→删缓存→读从库（数据未同步，旧数据）→写入旧缓存。解决：热点读请求直连主库、延长延迟双删时间、优先监听主库 Binlog。
场景选型总结（面试直接背诵）
普通业务、读多写少：先更 DB → 再删缓存 + 延迟双删 + TTL 兜底（通用最优）；
高并发写业务：DB 更新 + MQ 异步删缓存；
大型分布式 / 核心业务：Canal 监听 Binlog 维护缓存；
强一致性（零脏数据）：分布式锁串行读写，或直接放弃缓存查询 DB；
写多读少：建议直接禁用缓存，避免一致性维护成本。
五、整体面试速记总结
穿透：查不存在数据 → 校验参数 / 缓存空值 / 布隆过滤器；
击穿：单个热点 Key 过期 → 分布式锁 / 逻辑过期 / 随机 TTL；
雪崩：批量 Key 过期 / Redis 宕机 → 随机 TTL / 多级缓存 / Redis 高可用 + 限流熔断降级；
一致性：标准做法「先更库、后删缓存」，配套延迟双删 / Canal/MQ/TTL 兜底；
所有缓存问题，TTL 过期时间、Redis 高可用、限流熔断是生产环境三大基础兜底手段。
高阶架构面试题（多级缓存、性能优化、故障排查）
这份面试题覆盖大厂高频考点，分多级缓存架构、性能优化、故障排查三大核心模块，包含基础题、进阶题、实战题，附带标准答案（面试踩分版），适配中高阶 Redis 架构面试。
一、多级缓存架构（高并发核心设计，面试必问）
多级缓存是本地缓存 + 分布式缓存的分层架构，是解决 Redis 热点压力、高并发读的终极方案，核心层级：CDN → Nginx缓存 → 服务本地缓存(Caffeine) → Redis → DB。
基础面试题
什么是多级缓存？为什么要做多级缓存？答：多级缓存是多层级缓存嵌套的架构，将热点数据按访问频率分层存储；核心目的：降低 Redis 压力、减少网络 IO、提升读性能、抗极端高并发，纯 Redis 扛不住 10 万 + QPS 的热点读。
本地缓存（Caffeine）和 Redis 分布式缓存的核心区别？
表格
|
维度
|
本地缓存（Caffeine）
|
Redis 分布式缓存
|
|
速度
|
纳秒级（JVM 内存）
|
微秒级（网络 IO）
|
|
容量
|
小（受 JVM 内存限制）
|
大（独立集群）
|
|
一致性
|
弱一致
|
最终一致
|
|
适用场景
|
极致热点 Key
|
全量业务缓存
|
多级缓存的标准分层？答：CDN（静态资源）→ Nginx 本地缓存（页面 / 接口）→ 服务本地缓存（Caffeine）→ Redis 分布式缓存 → 数据库。
进阶面试题
多级缓存如何保证数据一致性？答：优先保证最终一致性（强一致会牺牲性能），方案：① 过期兜底：本地缓存设置短 TTL（如 5s），自动过期淘汰；② 主动更新：数据修改时，先更新 DB → 再删 Redis → 再通过 MQ / 配置中心通知所有服务删本地缓存；③ 订阅同步：用 Canal 订阅 MySQL binlog，数据变更自动刷新缓存。
本地缓存的更新策略选型？答：① 懒加载（默认）：读时缓存，过期自动淘汰（最简单，适合读多写少）；② 主动失效：写数据时主动删除本地 + Redis 缓存（一致性更好）；③ 广播通知：用 Redis Pub/Sub、MQ 通知所有节点刷新本地缓存（集群场景必备）。
多级缓存下，如何避免双写不一致？答：核心原则禁止双写，用删除代替更新：写流程：更新DB → 延迟删除Redis → 延迟删除本地缓存；兜底：本地缓存短 TTL，即使不一致也会快速自愈。
实战面试题
电商商品详情页多级缓存架构设计（全流程）？答：① 读流程：先查 Caffeine 本地缓存 → 无则查 Redis → 无则查 DB → 回写 Redis + 本地缓存；② 写流程：修改商品 → 更新 DB → 删 Redis → 广播删所有服务本地缓存；③ 防护：本地缓存限制最大容量，Redis 防止雪崩 / 穿透，熔断降级兜底 DB。
多级缓存如何结合熔断、降级？答：① Redis 宕机：熔断 Redis，直接访问本地缓存 + DB；② 高并发压测：限流降级，只访问本地缓存，拒绝穿透到 Redis/DB；③ 本地缓存满：启用 LRU 淘汰，保护 JVM 内存。
Caffeine 本地缓存核心优化配置？答：① 最大容量（maximumSize）：限制内存占用；② 过期策略（expireAfterWrite）：写后过期（5~30s）；③ 淘汰策略：W-TinyLFU（Caffeine 默认，命中率最高）。
二、Redis 性能优化（中高阶面试核心）
聚焦内存、命令、集群、持久化、客户端五大优化方向，解决 Redis 慢、卡、QPS 上不去问题。
基础面试题
Redis 核心性能指标有哪些？答：响应延时（ms）、QPS、内存使用率、连接数、慢查询数、命中率、主从延迟。
Redis 内存优化的核心手段？答：① 数据结构优化：Hash/List/ZSet 用ziplist压缩存储（控制元素个数 / 大小）；② 淘汰策略：用allkeys-lru淘汰冷数据；③ 禁用大 Key：避免超大 String / 集合；④ 清理过期 Key：主动过期 + 惰性过期结合；⑤ 序列化优化：用 Protobuf 代替 JSON/JDK。
进阶面试题
什么是 Redis 大 Key / 热 Key？危害？解决方案？✅ 大 Key定义：String >10KB、集合元素 > 1 万；危害：网络 IO 阻塞、集群分片不均、主从同步延迟；方案：拆分大 Key、批量获取、本地缓存承载。
✅ 热 Key定义：单 Key QPS 过万，打满单节点 CPU / 网络；方案：本地缓存、热 Key 备份（key1/key2/key3）、集群读写分离。
Redis 慢查询排查流程 & 优化？答：① 开启慢查询：slowlog-log-slower-than 10000（10ms）；② 查看慢查询：slowlog get 10；③ 优化：禁用keys */hgetall等全量遍历命令、大 Key 拆分、简化复杂 Lua 脚本。
Redis 持久化如何平衡性能和数据安全？答：① 高并发场景：关闭 RDB 定时快照，AOF 设为everysec（每秒刷盘，性能 & 安全平衡）；② 纯缓存场景：关闭 RDB+AOF，极致性能；③ 数据可靠场景：RDB 全量 + AOF 增量混合持久化。
Pipeline/MGET 批量操作原理与注意事项？答：① Pipeline：合并多个命令为一次网络 IO，减少 RTT（往返时间），非原子性；② MGET/MSET：原子性批量操作，适合批量读 String；③ 注意：批量大小控制在 100 以内，避免大网络包阻塞。
实战面试题
线上 Redis QPS 上不去，如何排查优化？答：① 网络：检查带宽、RTT 延迟，内网部署 Redis；② 命令：禁用慢命令，用批量操作；③ 客户端：优化连接池（最大连接数、最小空闲）；④ 集群：分片扩容、读写分离（读从节点）；⑤ 缓存：提升命中率（避免缓存失效）。
Redis 客户端连接池优化配置？答：① maxTotal：最大连接数（根据 QPS 设置，8~100）；② maxIdle：最大空闲连接（避免频繁创建销毁）；③ minIdle：最小空闲连接（预热连接）；④ 超时时间：连接 / 读取超时（200ms）。
Redis 集群性能优化点？答：① 读写分离：读请求分发到从节点，减轻主节点压力；② 分片均匀：避免单节点热点 / 大 Key；③ 禁用跨槽命令：如mget跨槽会触发多次网络 IO；④ 节点扩容：水平扩容分担流量。
三、Redis 故障排查 & 高可用（实战大厂必考）
聚焦缓存三大问题、集群故障、线上突发问题，考察实战排查能力。
基础面试题
缓存穿透、击穿、雪崩的区别 & 解决方案？
表格
|
问题
|
定义
|
核心解决方案
|
|
穿透
|
查不存在的数据，直接打 DB
|
布隆过滤器、空值缓存
|
|
击穿
|
热点 Key 过期，瞬间打 DB
|
互斥锁、永不过期
|
|
雪崩
|
大量 Key 同时过期 / 节点宕机
|
随机 TTL、集群高可用、熔断
|
Redis 主从延迟原因 & 优化？答：原因：主节点大 Key 同步、网络延迟、从节点 CPU 过高；优化：拆分大 Key、内网低延迟网络、从节点提升配置、无盘复制。
哨兵 / 集群故障转移流程？答：① 主观下线：单个哨兵检测主节点宕机；② 客观下线：半数以上哨兵确认宕机；③ 选主：从节点中选最优（偏移量最大、优先级最高）；④ 切换：新主上线，旧主变从节点，客户端重连。
进阶面试题
什么是 Redis 脑裂？如何解决？答：脑裂：主节点网络临时隔离，哨兵选新主；旧主恢复后，双主同时写入，数据丢失；解决：配置min-replicas-to-write 1，主节点必须有至少 1 个从节点同步成功才允许写入。
Redis 数据丢失场景 & 兜底方案？答：场景：AOF 丢盘、脑裂、主从未同步完成宕机；方案：混合持久化、哨兵 + 集群高可用、定期 RDB 备份、DB 数据兜底回补。
Redis 阻塞场景有哪些？答：① 大 Key 读写 / 删除；② 持久化 fork 阻塞；③ 慢命令执行；④ 内存满阻塞；⑤ 网络阻塞。
实战面试题
线上 Redis 突然超时、响应慢，完整排查思路？答：按优先级从快到慢排查：① 看监控：CPU / 内存 / 网络 / 连接数 / 慢查询；② 查大 Key / 热 Key：用redis-cli –bigkeys扫描；③ 查持久化：是否触发 fork 阻塞、AOF 刷盘阻塞；④ 查集群：主从延迟、节点宕机、分片不均；⑤ 查客户端：连接池耗尽、序列化耗时。
Redis OOM（内存溢出）如何处理？答：① 临时：执行memory purge主动清理、删除无用 Key；② 配置：开启 LRU 淘汰策略、限制最大内存；③ 根本：拆分大 Key、清理冷数据、集群扩容。
Redis Too many connections（连接数耗尽）解决？答：① 客户端：优化连接池，及时释放空闲连接；② 服务端：调大maxclients、关闭闲置连接；③ 排查：是否有恶意连接、客户端泄漏。
Redis 集群节点宕机，如何快速恢复业务？答：① 自动：哨兵 / 集群自动故障转移（分钟级）；② 手动：宕机节点快速重启，加入集群；③ 业务：熔断降级，优先访问本地缓存，避免 DB 压垮。
四、综合架构面试题（大厂压轴题）
设计一个高并发、高可用的 Redis 缓存架构，需要考虑哪些点？答：① 缓存分层：多级缓存（本地 + Redis）；② 高可用：主从 + 哨兵 / 集群，故障自动转移；③ 性能：大 Key / 热 Key 优化、批量操作、连接池优化；④ 一致性：最终一致，主动删除 + 过期兜底；⑤ 防护：穿透 / 击穿 / 雪崩防护、熔断降级限流；⑥ 运维：监控告警、慢查询、故障排查。
结合多级缓存、性能优化、故障排查，说说 Redis 架构设计核心逻辑？答：核心是 **「分层减负、性能优先、高可用兜底、故障自愈」：用多级缓存扛住高并发读，用性能优化避免 Redis 瓶颈，用高可用和故障排查保证业务不中断，最终实现 Redis 架构的高并发、低延迟、高可用 **。
总结
多级缓存：核心是本地缓存 + Redis分层，解决热点读压力，保证最终一致；
性能优化：抓大 Key / 热 Key、慢命令、持久化、客户端四大核心；
故障排查：熟记缓存三大问题、线上突发问题排查流程，实战优先。
