架构与高可用
部署模式对比
| 模式 | 架构 | 高可用 | 适用场景 |
|---|
| 单机 | 1 个实例 | 无 | 开发测试、缓存量小 |
| 主从 | 1 主 N 从 | 需外部切换 | 读写分离、对高可用要求不高 |
| 哨兵 (Sentinel) | 1 主 N 从 + 3 个 Sentinels | 自动故障切换 | 中小规模、需要自动 HA |
| Redis Cluster | 多分片 (shard) | 分片级自动切换 | 大规模数据、需横向扩展 |
| Redis Enterprise / 云托管 | 托管集群 | 平台保证 | 企业生产、免运维 |
Sentinel 架构要点
# redis-sentinel 配置文件关键项
sentinel monitor mymaster 127.0.0.1 6379 2 # 2 个 Sentinel 同意才切
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
# 部署要求
# - Sentinel 至少 3 个节点（奇数）
# - Sentinel 与 Redis 不混部
# - 客户端通过 Sentinel 获取主节点地址（Sentinel 感知切换）
Redis Cluster 架构要点
# 创建集群（6 个节点：3 master + 3 replica）
redis-cli --cluster create 192.168.1.1:6379 192.168.1.2:6379 ... \
--cluster-replicas 1
# 槽位分布：0-16383，每个 master 管理一段槽位
# 跨槽位操作需使用 Hash Tag 确保 key 在同一槽位
持久化策略
| 策略 | 机制 | 优点 | 缺点 |
|---|
| RDB | 定期全量快照 | 恢复快、文件紧凑 | 可能丢数据（最后一次快照后） |
| AOF | 追加写操作日志 | 数据更安全（可配置 fsync） | 文件大、恢复慢 |
| RDB + AOF | 两者同时开启 | 兼顾安全与恢复速度（推荐） | 磁盘占用双倍 |
| 不持久化 | 纯内存 | 性能最佳 | 重启丢全部数据 |
# redis.conf 关键配置
save 900 1 # 15min 内至少 1 个 key 变更 → RDB
save 300 10 # 5min 内至少 10 个 key 变更
save 60 10000 # 1min 内至少 10000 个 key 变更
appendonly yes
appendfsync everysec # 每秒 fsync（性能与安全平衡）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 生产建议：开启 AOF + 定时 RDB，关闭 RDB 自动 save（用 crontab 定时 BGSAVE）
内存管理与淘汰策略
淘汰策略 (maxmemory-policy)
| 策略 | 行为 | 适用场景 |
|---|
| noeviction | 内存满后写入直接报错 | 不允许丢数据的场景 |
| allkeys-lru | 淘汰最久未使用的 key | 通用推荐 |
| volatile-lru | 淘汰设置了 TTL 的 key 中最近最少使用的 | 缓存 + 持久 key 混用 |
| allkeys-lfu | 淘汰使用频率最低的 key | 访问模式差异大的场景 |
| volatile-ttl | 淘汰过期时间最近的 key | 特殊场景 |
| allkeys-random | 随机淘汰 | 极低概率需求 |
# 生产建议：maxmemory-policy allkeys-lru
# 设置 maxmemory（给操作系统留 20-30% 内存用于 RDB fork 和缓冲区）
maxmemory 8gb # 如果是 12G 物理机
内存诊断
# 查看内存使用
INFO memory
# used_memory：实际数据占用
# used_memory_rss：进程 RSS
# mem_fragmentation_ratio：碎片率（>1.5 表示碎片严重）
# 查看 key 分布
redis-cli --bigkeys # 找出大 key
redis-cli --memkeys # 分析内存占用分布
# 查看 key 的 TTL
redis-cli --scan --pattern '*' | head -1000 | while read key; do
echo "$key: $(redis-cli ttl "$key")"
done
大 Key 与热 Key 治理
大 Key
- 定义：单个 key 的 value > 10KB 或元素数 > 10000（string、list、set、hash、zset）
- 危害：阻塞 Redis（操作 O(N)）、内存不均、慢查询、数据迁移慢
- 排查：
redis-cli --bigkeys、MEMORY USAGE key
- 治理：
- 拆分大 hash：用 hash 分片（key:{id%1000}）
- 拆分大 list/set：按时间/ID 分段
- 拆分大 string：压缩后存储，或拆成多个 key
热 Key
- 定义：某个 key 被极高频率访问
- 危害：单节点 CPU 打满、Redis Cluster 下单个分片成为瓶颈
- 排查：
redis-cli --hotkeys、MONITOR（慎用，生产会有性能影响）
- 治理：
- 本地缓存（应用层缓存热 key）
- 读写分离（架构层）
- key 加随机后缀分散访问（客户端兼容）
缓存雪崩 / 击穿 / 穿透
| 问题 | 现象 | 原因 | 解决 |
|---|
| 雪崩 | 大量请求直接打到 DB | 大量 key 同时过期 / Redis 宕机 | 过期时间加随机偏差、多级缓存、限流降级 |
| 击穿 | 单 key 被打爆 | 热点 key 过期瞬间高并发 | 互斥锁更新、永不过期 + 异步刷新 |
| 穿透 | DB 压力大，无缓存命中 | 查询不存在的数据 | 布隆过滤器、空值缓存（短 TTL） |
常规运维命令
# 慢查询日志
SLOWLOG LEN
SLOWLOG GET 10
SLOWLOG RESET
# 配置文件：slowlog-log-slower-than 10000（微秒）
# slowlog-max-len 128
# 连接检查
CLIENT LIST
INFO clients
# 操作延迟
redis-cli --latency -h <host>
redis-cli --latency-history -h <host> -i 1 # 每秒采样
# 复制检查
INFO replication
# role:master / role:slave
# master_link_status:up
# slave_repl_offset
面试回答框架
- 先明确场景：缓存、会话存储、计数器、排行榜、分布式锁还是消息队列
- 再选架构：单机 / 哨兵 / Cluster，为什么这么选
- 再讲持久化和淘汰策略：AOF + RDB、allkeys-lru
- 再讲治理经验：大 key 拆分、热 key 本地缓存、雪崩/击穿/穿透应对
- 最后讲排障：慢查询、内存碎片、复制延迟、bigkeys 分析