Redis面试高频考点深度剖析（附场景题）

最新推荐文章于 2025-07-04 20:57:22 发布

xiaolukanshijie

最新推荐文章于 2025-07-04 20:57:22 发布

阅读量622

点赞数 12

CC 4.0 BY-SA版权

文章标签： redis 面试数据库其他

本文链接：https://blog.youkuaiyun.com/xiaolukanshijie/article/details/147405614

文章目录

📌 必知必会五大数据类型（附新特性）

1. String类型（最基础但别小看）

典型场景：缓存用户信息（序列化JSON）、计数器（阅读量统计）
骚操作：INCR做分布式锁（注意！不是银弹）、SETNX实现简单限流
冷知识：value最大512MB！（存小文件？可以但没必要）

2. Hash类型（对象存储神器）

HMSET user:1001 name "老王" age 28 score 95
HGETALL user:1001

优势：字段级操作，比String更省内存（重要！！）
坑点：超过500个字段时，编码方式会变（性能影响！）

3. List类型（不只是队列）

应用场景：
- 消息队列（LPUSH+BRPOP）
- 最新评论展示（LTRIM保持N条）
隐藏技巧：BLPOP 实现阻塞队列（比轮询高效十倍！）

4. Set类型（去重王者）

典型应用：
- 共同好友（SINTER）
- 抽奖黑名单（SISMEMBER）
性能警告：SMEMBERS操作大集合会炸！（用SSCAN代替）

5. ZSet类型（排行榜必备）

ZADD hotNews 1000000 "中美贸易战" 950000 "AI突破"
ZREVRANGE hotNews 0 4 WITHSCORES

底层结构：跳跃表+字典（查询O(logN)）
实战技巧：ZRANGEBYSCORE 做延时队列（比RocketMQ轻量）

🆕 新特性Stream类型（面试加分项！）

类Kafka的消费组模式
消息持久化 + ACK机制
适合做消息追溯场景

💣 持久化机制灵魂拷问（必考题！！）

RDB vs AOF 世纪对决

	RDB	AOF
持久化方式	内存快照	操作日志追加
数据安全	可能丢失分钟级数据	最多丢失1秒数据（配置决定）
恢复速度	快（直接加载二进制）	慢（重放所有命令）
文件大小	小（压缩二进制）	大（文本日志日积月累）

混合持久化（Redis4.0+）

触发条件：aof-use-rdb-preamble yes
运作机制：AOF文件 = RDB头 + AOF增量
优势：兼顾启动速度与数据安全（这个设计绝了！）

🚨 缓存三大经典问题（送命题！！）

缓存穿透（查不到）

场景：查询不存在的数据（比如id=-1）
解决方案：
1. 布隆过滤器拦截（前置过滤）
2. 缓存空值（注意过期时间！）
3. 接口鉴权（防恶意攻击）

缓存雪崩（集体失效）

致命场景：大量key同一时间过期
保命方案：
- 随机过期时间（基础版）
- 热点数据永不过期（进阶版）
- 熔断降级（Hystrix走起）

缓存击穿（热点key失效）

public Object getData(String key) {
    Object value = redis.get(key);
    if (value == null) {
        if (redis.setnx(key_mutex, 1)) { // 分布式锁
            value = db.get(key); 
            redis.set(key, value);
            redis.del(key_mutex);
        } else {
            Thread.sleep(50);
            return getData(key); // 重试
        }
    }
    return value;
}

核心思路：互斥锁重建缓存（注意锁超时！）

🌐 集群方案对比（架构设计必问）

1. 主从复制（读写分离基础）

同步原理：全量同步 + 增量同步
致命缺陷：主节点挂了要手动切换（生产环境慎用！）

2. 哨兵模式（高可用方案）

监控机制：每秒ping检查节点状态
故障转移：
1. 主观下线（单个哨兵判断）
2. 客观下线（多数哨兵确认）
3. 选举新主（Raft算法）

3. Cluster模式（官方分布式方案）

数据分片：16384个slot（每个节点负责部分）
重定向机制：MOVED/ASK响应指引客户端
优势：自动故障转移 + 水平扩展（生产首选！）

💡 高频进阶问题（P7以上必看）

1. 管道化 vs 事务

管道（Pipeline）：批量发送命令（减少网络开销）
事务（Multi）：命令打包原子执行（但非回滚！）
冷知识：事务中的命令会排队，不保证其他客户端的可见性

2. 内存淘汰策略

volatile-lru：从过期key中淘汰最近最少使用的
allkeys-random：全体key随机淘汰
自定义策略：配合LFU算法（Redis4.0+）

3. 热key处理方案

本地缓存：Guava Cache二级缓存
分片存储：对key做hash打散
监控预警：redis-cli --hotkeys 找出热点

🛠️ 实战设计题（检验真功夫）

场景：设计微博点赞系统

存储设计：
- 使用Hash存储每个帖子的点赞用户（field=用户ID，value=点赞时间）
- ZSet存储热门帖子排行榜（score=点赞数）
性能优化：
- 本地计数+定时同步（缓解写压力）
- 读写分离（从节点处理统计查询）
异常处理：
- 点赞去重（HINCRBY原子操作）
- 数据补偿（定时扫描日志对账）

// 伪代码示例
public void likePost(long userId, long postId) {
    String key = "post_likes:" + postId;
    if (redisCommand.hsetnx(key, String.valueOf(userId), System.currentTimeMillis())) {
        redisCommand.zincrby("hot_posts", 1, String.valueOf(postId));
    }
}