一、基础核心
- 数据类型与适用场景
String：缓存、计数器（INCR）、分布式锁（SETNX）
Hash：存储对象（用户信息、商品属性）
List：消息队列（LPUSH/BRPOP）、时间线
Set：标签系统、共同关注（SINTER）
Sorted Set：排行榜（ZRANGE）、延迟队列
Stream：日志型消息队列（类似 Kafka）
HyperLogLog：基数统计（UV 统计，误差 <1%）
Bitmap：签到系统（SETBIT）、布隆过滤器- 持久化机制
RDB：定时快照，恢复快但可能丢数据
AOF：日志追加，数据安全但文件大
混合模式（Redis 4.0+）：RDB + AOF，兼顾速度与安全- 过期策略与内存淘汰
过期策略：定期删除 + 惰性删除
淘汰策略：
1. volatile-lru/allkeys-lru（LRU 算法）
2. volatile-ttl（优先淘汰短过期）
3. volatile-random/allkeys-random
4. noeviction（不淘汰，写报错）二、高可用与分布式
- 主从复制
流程：全量同步（RDB） → 增量同步（缓冲区）
问题：脑裂（旧主写入导致数据不一致）
解决方案：min-slaves-to-write（最小从节点数）- 哨兵模式
功能：监控、自动故障转移、配置中心
选举流程：主观下线 → 客观下线 → Leader 选举 → 故障切换
缺陷：写能力受限、扩容复杂- 集群模式
数据分片：16384 个 Slot（CRC16(key) % 16384）
节点通信：Gossip 协议
故障转移：从节点选举（类似 Raft）
扩容/缩容：reshard 迁移 Slot三、高级特性
- 事务
命令：MULTI → 命令入队 → EXEC/DISCARD
注意点：不保证原子性（单命令原子，事务非回滚）- Lua 脚本
原子执行、减少网络开销
避免死循环（lua-time-limit 配置）- 管道
批量发送命令，减少 RTT
非原子性，需注意顺序执行- 发布订阅
实时消息系统
缺陷：消息不持久化，消费者离线丢失消息四、性能优化与问题解决
- 缓存问题
穿透：查询不存在的数据（布隆过滤器 + 缓存空值）
击穿：热点 key 过期（互斥锁 + 永不过期策略）
雪崩：大量 key 同时过期（随机过期时间 + 集群限流）- 大 Key 与热 Key
大 Key：内存 > 1MB 或元素数 > 1000（拆分/异步删除）
热 Key：高频访问（本地缓存/分片到多节点）- 慢查询优化
监控：slowlog get
避免 KEYS * ， 用 SCAN 替代
复杂操作移入 Lua 脚本五、架构设计场景题
- 分布式锁实现
SET lock_name random_value NX PX 30000
(NX 表示if not exist 就设置并返回True，否则不设置并返回False；PX 表示过期时间用毫秒级， 30000 表示这些毫秒时间后此key过期)
解锁 Lua 脚本保证原子性
Redlock 算法（多实例部署）- 延迟队列设计
方案1：Sorted Set
方案2：Redis Stream- 秒杀系统设计
Lua 脚本扣减库存（原子性）
库存预热 + 限流熔断
请求队列削峰六、底层原理
- 数据结构实现
SDS（动态字符串）：预分配 + 惰性删除
跳表（ZSet）：平均 O(log N) 查询
压缩列表（List/Hash）：小数据内存优化
QuickList（List 3.2+）：链表 + 压缩列表- 网络模型
单 Reactor 模式（6.0 前）
多线程网络 I/O（6.0+）：主线程处理命令，I/O 线程并行读/写高频面试真题
- Redis 如何保证高并发下的线程安全？
- 集群扩容时 Slot 迁移如何保证数据一致性？
- AOF 重写时新写入的数据如何处理？
- Redis 为什么快？单线程是否影响性能？
- 如何实现一个精准的排行榜（分数相同时按时间排序）？
学习建议：
- 实践：用 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 取舍、空间换时间）比死记命令更重要！