Redis-101

Redis 不是“万能缓存”，而是高性能内存数据结构服务。核心是“场景匹配 + 持久化 + 内存治理”。

1. Redis 适合什么，不适合什么

适合：

• 缓存热点数据（低延迟读）
• 计数器、排行榜、会话、分布式锁
• 流式消息（Stream）

不适合：

• 超大规模冷数据长期存储
• 需要复杂多表关联查询的场景

2. 五种常用数据结构与复杂度直觉

• String：缓存对象、计数器（INCR）
• Hash：对象字段存储（比 JSON 字符串更易局部更新）
• List：简单队列（注意积压）
• Set：去重、交并差
• ZSet：排行榜（按 score 排序）

实践建议：

• 优先设计 key 结构，再选数据结构。
• key 命名统一：业务:实体:ID，便于治理与扫描。

3. 持久化必须清楚（RDB vs AOF）

• RDB：快照，恢复快，可能丢失最近一段数据。
• AOF：追加日志，数据更完整，文件更大，恢复较慢。
• 生产常用：RDB + AOF 组合，兼顾恢复速度与数据安全。

4. 内存与淘汰策略

关键配置：

• maxmemory：内存上限
• maxmemory-policy：淘汰策略（如 allkeys-lru）

常见误区：

• 不设置过期时间，缓存会退化成“内存黑洞”。
• 大 key（超大 value / 超长 list）会导致阻塞和抖动。

5. 缓存三大问题与应对

• 缓存穿透：查询不存在数据
  • 方案：布隆过滤器 + 空值短 TTL
• 缓存击穿：热点 key 过期瞬间并发打 DB
  • 方案：互斥锁 + 逻辑过期
• 缓存雪崩：大量 key 同时过期
  • 方案：过期时间加随机抖动 + 多级缓存

6. 最小可用命令集

redis-cli
PING
SET user:1:name "alice" EX 60
GET user:1:name
HSET user:1 age 20 city shanghai
HGETALL user:1
ZADD rank 100 userA 120 userB
ZRANGE rank 0 -1 WITHSCORES

7. 线上治理清单

1. 所有缓存 key 必须有 TTL（除极少数白名单）。
2. 监控命中率、内存、慢查询、连接数。
3. 禁止 KEYS *，排查用 SCAN。
4. 大 key 定期巡检并拆分。
5. 变更前先在压测环境验证淘汰策略与 QPS 峰值。