1. Redis面试高频难题解析作为从业多年的技术面试官我发现Redis相关的技术考察几乎成为后端开发的必答题。但令人惊讶的是许多工作3-5年的候选人在面对以下三个问题时表现往往不尽如人意。今天我们就来深入剖析这些容易被忽视的技术细节。2. 问题一Redis持久化机制差异与选型2.1 RDB与AOF原理对比Redis提供两种持久化方案RDB快照和AOF日志。RDB通过fork子进程生成数据快照存储为二进制文件。它的优势在于恢复速度快文件体积小适合做灾难恢复。但缺点是可能丢失最后一次快照后的所有数据。AOF则记录每个写操作命令以追加方式写入文件。我曾在生产环境测试过AOF的默认配置everysec在保证性能的同时最多只会丢失1秒数据。但AOF文件会不断膨胀需要定期执行BGREWRITEAOF重写。2.2 混合持久化的实践选择Redis 4.0后推出的混合持久化RDBAOF是目前最推荐的方案。具体配置如下save 900 1 # 15分钟内有1个key变化就触发RDB appendonly yes # 开启AOF aof-use-rdb-preamble yes # 混合模式重要提示在内存超过6G的实例上要监控fork操作对主线程的影响。我曾遇到因RDB fork导致服务短暂卡顿的案例解决方案是适当调大repl-backlog-size。3. 问题二缓存雪崩/穿透/击穿场景应对3.1 三者的本质区别雪崩大量key同时过期请求直接打到DB穿透查询不存在的数据如恶意攻击击穿热点key过期瞬间的高并发请求3.2 分层防御方案针对雪崩问题我的经验是过期时间增加随机值如基础300秒±60秒随机采用多级缓存架构Redis本地缓存对于穿透问题推荐两种方案# 方案1布隆过滤器 import redis r redis.Redis() r.bf().create(user_filter, 0.01, 10000) # 方案2缓存空值设置较短TTL r.setex(nonexistent_key, 30, NULL)击穿防御最有效的是互斥锁-- 使用Lua脚本实现原子锁 local key KEYS[1] local lock_key key.._lock if redis.call(setnx, lock_key, 1) 1 then redis.call(expire, lock_key, 5) -- 查询数据库并回填缓存 return redis.call(setex, key, 300, ARGV[1]) else return redis.call(get, key) end4. 问题三Redis集群数据分片策略4.1 一致性哈希的局限原生的一致性哈希算法存在数据倾斜问题。在我的某次迁移案例中某个节点负载比其他节点高出40%。Redis Cluster采用的改进方案是哈希槽Hash Slot共16384个槽位每个节点负责部分槽范围支持槽位迁移再平衡4.2 生产环境调优经验避免大key单个value不要超过1MB否则迁移时会阻塞集群。可以用redis-cli --bigkeys定期扫描。热点key处理# 监控热点key redis-cli --hotkeys # 解决方案本地缓存或拆分为多个key跨机房部署时务必设置合理的cluster-announce-ip否则节点间通信可能失败。5. 高频追问问题锦囊5.1 内存优化技巧使用ziplist编码当元素较少时hash-max-ziplist-entries 512选择合适的数据类型比如存储标签用Set而非List启用内存淘汰策略maxmemory-policy volatile-lru5.2 性能监控指标这几个命令是我每天必查的# 查看延迟分布 redis-cli --latency-history # 统计命令耗时 redis-cli --stat # 监控慢查询 slowlog get 106. 真实故障案例分析去年处理过一个典型故障某电商大促期间Redis响应突然变慢。排查过程如下通过info commandstats发现HGETALL调用暴增检查代码发现某同事误用HGETALL获取大hash表紧急方案改用HMGET获取指定字段长期方案重构为多个小hash结构这个案例让我深刻体会到Redis的误用往往发生在看似简单的API调用上。建议团队定期做Code Review时特别关注Redis操作语句。