分布式缓存架构师高阶面试宝典 - 第3节
第3章 分布式缓存核心原理与底层实现
Redis 的面试考核聚焦三大底层模块：数据结构编码、持久化机制、内存淘汰策略。本章梳理高频问题的回答框架、追问陷阱及项目实战模板，帮助你在架构师面试中展现深度。
知识结构：Redis 核心数据结构编码对比
| 数据结构 | 底层编码 | 切换条件 | 空间优势 |
|---|---|---|---|
| String | SDS（动态字符串） | 无切换 | 二进制安全，预分配 |
| List | quicklist（双端链表+ziplist片段） | 元素少用ziplist，多用linkedlist | 内存碎片少 |
| Hash | ziplist 或 dict | 字段<512且值<64字节用ziplist | 小数据紧凑 |
| Set | intset 或 dict | 元素全部整数且个数<512用intset | 整数数组节省内存 |
| ZSet | ziplist 或 skiplist+dict | 元素<128且值<64字节用ziplist | 跳跃表实现范围查询 |
面试问题 1：请说说 Redis 有哪些核心数据结构，并简述其底层实现？
考察点：对底层编码的理解、内存优化意识、多场景应用能力。
回答框架：先列出5种基本类型 → 说明每种底层编码及切换条件 → 补充Redis 5.0新增的Stream等。
示例回答：Redis有String、List、Hash、Set、ZSet五种基础结构。String底层使用SDS；List使用quicklist；Hash使用ziplist或dict；Set使用intset或dict；ZSet使用ziplist或skiplist+dict。根据元素数量和大小自动切换编码以节省内存。
可能追问：为什么SDS比C字符串安全？quicklist如何解决linkedlist内存碎片？ziplist连锁更新问题如何解决？
面试问题 2：Redis 的持久化机制有哪些？如何选择？
考察点：数据安全与性能平衡、RDB与AOF对比、混合持久化原理、AOF重写触发条件。
回答框架：分三点：RDB快照、AOF日志、混合持久化 → 比较优缺点 → 给出生产建议。
示例回答：Redis提供RDB和AOF两种持久化。RDB定期生成全量快照，适合备份和快速重启；AOF记录写操作指令，数据更安全但文件大。建议同时开启AOF（everysec刷盘）并配置混合持久化（Redis 4.0+），兼顾性能和可靠性。
可能追问：RDB的子进程如何保证数据一致性？AOF重写策略（达到上次大小的100%且>64MB）？混合持久化加载顺序（先AOF后RDB）？
面试问题 3：Redis 的内存淘汰策略有哪些？如何配置？
考察点：淘汰策略适用场景、近似LRU/LFU实现、与过期策略的区别。
回答框架：列举8种策略 → 重点对比allkeys-lru和allkeys-lfu → 说明Redis的近似LRU算法（采样5个key淘汰LRU）→ 给出推荐配置。
示例回答：Redis提供noeviction、allkeys-lru、volatile-lru、allkeys-lfu等。常用allkeys-lru淘汰最近最少使用key；热点业务建议allkeys-lfu，避免偶发性访问导致误淘汰。Redis采用近似LRU，通过maxmemory-samples采样（默认5），性能优于精确LRU。
可能追问：LFU的衰减机制（counter随时间减半）？如何手动触发淘汰？淘汰键是否包含过期键？
项目案例：电商秒杀活动缓存架构
| 维度 | 内容 |
|---|---|
| 项目名称 | 双11秒杀活动缓存降级与一致性方案 |
| 业务背景 | 秒杀期间商品库存、用户限购等数据面临极高并发读写，需保证最终一致性且避免缓存雪崩。 |
| 规模指标 | 日活2000万，秒杀QPS峰值50万+，Redis Cluster集群100节点，单节点内存16GB。 |
| 技术栈 | Redis Cluster + Codis-Proxy + Lua脚本 + RDB+AOF混合持久化 + 本地缓存（Caffeine） |
| 核心难点 | ①热点Key导致单分片打满；②库存扣减原子性与缓存一致性；③秒杀瞬间大量缓存穿透。 |
| 面试高频追问 | 如何发现热点Key？（Redis-cli –hotkeys / RFM分析）大Key拆分策略？（Hash分段 / 本地缓存）缓存与DB一致性保证？（先更新DB再删缓存 + 延迟双删） |
| 可迁移回答话术 | “我们采用本地缓存+Redis Cluster二级架构：热点Key通过监控自动上浮到本地缓存，减少Redis压力；库存扣减使用Lua脚本保证原子性；同时开启AOF每秒刷盘，配合主从切换保证数据不丢。” 其他场景（如Feed流、排行榜）可复用该话术，仅替换“库存”为“用户关系/分数”。 |