一、基础核心

1. 数据类型与适用场景

String：缓存、计数器（INCR）、分布式锁（SETNX）
Hash：存储对象（用户信息、商品属性）
List：消息队列（LPUSH/BRPOP）、时间线
Set：标签系统、共同关注（SINTER）
Sorted Set：排行榜（ZRANGE）、延迟队列
Stream：日志型消息队列（类似 Kafka）
HyperLogLog：基数统计（UV 统计，误差 <1%）
Bitmap：签到系统（SETBIT）、布隆过滤器

1. 持久化机制

RDB：定时快照，恢复快但可能丢数据
AOF：日志追加，数据安全但文件大
混合模式（Redis 4.0+）：RDB + AOF，兼顾速度与安全

1. 过期策略与内存淘汰

过期策略：定期删除 + 惰性删除
淘汰策略：
1. volatile-lru/allkeys-lru（LRU 算法）
2. volatile-ttl（优先淘汰短过期）
3. volatile-random/allkeys-random
4. noeviction（不淘汰，写报错）

二、高可用与分布式

1. 主从复制

流程：全量同步（RDB） → 增量同步（缓冲区）
问题：脑裂（旧主写入导致数据不一致）
解决方案：min-slaves-to-write（最小从节点数）

1. 哨兵模式

功能：监控、自动故障转移、配置中心
选举流程：主观下线 → 客观下线 → Leader 选举 → 故障切换
缺陷：写能力受限、扩容复杂

1. 集群模式

数据分片：16384 个 Slot（CRC16(key) % 16384）
节点通信：Gossip 协议
故障转移：从节点选举（类似 Raft）
扩容/缩容：reshard 迁移 Slot

三、高级特性

1. 事务

命令：MULTI → 命令入队 → EXEC/DISCARD
注意点：不保证原子性（单命令原子，事务非回滚）

1. Lua 脚本

原子执行、减少网络开销
避免死循环（lua-time-limit 配置）

1. 管道

批量发送命令，减少 RTT
非原子性，需注意顺序执行

1. 发布订阅

实时消息系统
缺陷：消息不持久化，消费者离线丢失消息

四、性能优化与问题解决

1. 缓存问题

穿透：查询不存在的数据（布隆过滤器 + 缓存空值）
击穿：热点 key 过期（互斥锁 + 永不过期策略）
雪崩：大量 key 同时过期（随机过期时间 + 集群限流）

1. 大 Key 与热 Key

大 Key：内存 > 1MB 或元素数 > 1000（拆分/异步删除）
热 Key：高频访问（本地缓存/分片到多节点）

1. 慢查询优化

监控：slowlog get
避免 KEYS * ， 用 SCAN 替代
复杂操作移入 Lua 脚本

五、架构设计场景题

1. 分布式锁实现

SET lock_name random_value NX PX 30000
(NX 表示if not exist 就设置并返回True，否则不设置并返回False；PX 表示过期时间用毫秒级， 30000 表示这些毫秒时间后此key过期)
解锁 Lua 脚本保证原子性
Redlock 算法（多实例部署）

1. 延迟队列设计

方案1：Sorted Set
方案2：Redis Stream

1. 秒杀系统设计

Lua 脚本扣减库存（原子性）
库存预热 + 限流熔断
请求队列削峰

六、底层原理

1. 数据结构实现

SDS（动态字符串）：预分配 + 惰性删除
跳表（ZSet）：平均 O(log N) 查询
压缩列表（List/Hash）：小数据内存优化
QuickList（List 3.2+）：链表 + 压缩列表

1. 网络模型

单 Reactor 模式（6.0 前）
多线程网络 I/O（6.0+）：主线程处理命令，I/O 线程并行读/写

高频面试真题

1. Redis 如何保证高并发下的线程安全？
2. 集群扩容时 Slot 迁移如何保证数据一致性？
3. AOF 重写时新写入的数据如何处理？
4. Redis 为什么快？单线程是否影响性能？
5. 如何实现一个精准的排行榜（分数相同时按时间排序）？

学习建议：

• 实践：用 Docker 搭建集群，模拟故障转移/扩容
• 源码：阅读 dict（哈希表）、ziplist 等核心结构实现
• 工具：redis-cli --bigkeys、redis-benchmark、RedisInsight

附：版本特性差异

Redis 6.0：多线程 I/O、ACL 权限控制

Redis 7.0：Function（函数计算）、Multi-Part AOF

Redis Stack（7.2+）：集成搜索（Search）、时序（TimeSeries）等模块

掌握以上内容，可覆盖 90% 的 Redis 面试场景。理解设计思想（如 CAP 取舍、空间换时间）比死记命令更重要！