Redis缓存大师

Redis 缓存大师（Redis Cache Master）

不是命令清单，而是生产避坑指南。 直击五大高频 Redis 生产事故：无 TTL 内存泄漏、淘汰策略错配、集群跨槽报错、原子性陷阱、大 Key 拖垮 eviction。提供决策树与模式库，让每次选型都有依据。

痛点与对策速查

TTL 纪律（核心规则）

每个缓存键必须设 TTL。 无 TTL 的键会永远存活，最终导致内存泄漏。

TTL 陷阱

TTL 分级建议

淘汰策略决策树（差异化核心）

数据是纯缓存吗？
├─ 是 → allkeys-lru（推荐）或 allkeys-lfu
│        所有键均可淘汰，LRU 最近最少使用
└─ 否（混合持久+缓存）
   ├─ 持久数据设了 TTL 吗？
   │  ├─ 是 → volatile-lru（只淘汰有 TTL 的）
   │  └─ 否 → noeviction（写入失败而非淘汰）
   └─ 数据可丢失吗？
      ├─ 是 → allkeys-lru
      └─ 否 → noeviction + 扩容

集群哈希标签模式（差异化核心）

Redis Cluster 用 16384 个哈希槽分布键。多键操作必须同槽。

哈希标签语法

{user:1}:profile   →  槽由 "user:1" 决定
{user:1}:sessions  →  同槽（都由 "user:1" 哈希）
{user:1}:cart      →  同槽

同槽操作模式

# 相关键用相同哈希标签
SET {user:1}:profile '{"name":"Alice"}'
SET {user:1}:sessions "active"
HSET {user:1}:prefs theme dark lang zh

# 多键操作（同槽才能执行）
MGET {user:1}:profile {user:1}:sessions
MSET {user:1}:profile "updated" {user:1}:sessions "idle"

跨槽报错与解决

错误：CROSSSLOT Keys in request don't hash to the same slot
原因：多键操作涉及不同槽的键
解决：
  1. 相关键加相同哈希标签 {tag}:key
  2. 或拆分为多次单键操作
  3. 或用 hash tag 让相关键落同槽

哈希标签设计原则

原子操作选择指南（差异化核心）

需要原子性吗？
├─ 单命令能完成？
│  ├─ 是 → 用 INCR/SETNX/DECR 等原子命令
│  └─ 否 → 需要多步
│     ├─ 步骤间有条件依赖？
│     │  ├─ 是 → WATCH/MULTI/EXEC 乐观锁
│     │  └─ 否 → Pipeline 批量
│     └─ 逻辑复杂？
│        └─ 是 → Lua 脚本（EVAL）

分布式锁模式（安全版）

# 加锁（NX 保证互斥，token 防误删）
SET lock:resource {unique_token} NX EX 30

# 解锁（Lua 保证"检查+删除"原子）
EVAL "
if redis.call('get', KEYS[1]) == ARGV[1] then
  return redis.call('del', KEYS[1])
else
  return 0
end
" 1 lock:resource {unique_token}

关键：解锁必须验证 token，否则会误删别人的锁。

限流模式

固定窗口：
  INCR rate:{ip}:{minute}
  EXPIRE rate:{ip}:{minute} 60
  → 超过阈值则拒绝

滑动窗口（更精确）：
  ZADD rate:{ip} {timestamp_ms} {request_id}
  ZREMRANGEBYSCORE rate:{ip} 0 {now - 60000}
  ZCARD rate:{ip}
  → 超过阈值则拒绝

令牌桶（允许突发）：
  Lua 脚本实现：检查余量 → 消费 → 补充

可靠消息：Streams 替代 Pub/Sub（差异化核心）

Pub/Sub 的缺陷：消息不持久、订阅者离线丢消息、无 ACK 无重试。

Streams 可靠消息模式

# 生产者
XADD events:* data "事件内容"

# 消费者组（一次性创建）
XGROUP CREATE events:* group1 0

# 消费者处理
XREADGROUP GROUP group1 consumer1 COUNT 10 BLOCK 5000 STREAMS events:* >

# 处理完成后确认
XACK events:* group1 {message_id}

# 检查未确认消息（重试）
XPENDING events:* group1
XCLAIM events:* group1 consumer2 60000 {message_id}

持久化决策矩阵（差异化核心）

配置建议

# 纯缓存（数据可重建）
save ""              # 关闭 RDB
appendonly no        # 关闭 AOF

# 平衡（推荐大多数场景）
save 900 1           # RDB：15分钟内有1个变更则快照
save 300 10          # RDB：5分钟内有10个变更
appendonly yes
appendfsync everysec # AOF：每秒刷盘（最多丢1秒）

# 最高安全
save 60 10000        # 频繁 RDB
appendonly yes
appendfsync always   # 每条命令刷盘（性能低）

内存管理（关键）

大 Key 检测与拆分

# 扫描大 Key
redis-cli --bigkeys

# 检查单键
MEMORY USAGE mykey

# 查看键类型和大小
TYPE mykey
HLEN mykey   # hash 元素数
LLEN mykey   # list 长度
ZCARD mykey  # sorted set 数量
SCARD mykey  # set 数量

常用数据结构场景

连接管理

常见生产事故与预防

缓存模式

真实场景示例

场景 1：用户会话缓存

# 存储会话（30分钟过期）
HSET session:{token} user_id 123 last_active {ts} ip {ip}
EXPIRE session:{token} 1800

# 更新活跃时间（保留 TTL）
HSET session:{token} last_active {new_ts}
EXPIRE session:{token} 1800  # 重置 TTL

# 检查会话
HGETALL session:{token}

场景 2：分布式锁

# 加锁
SET lock:order:123 "uuid-abc" NX EX 30

# 业务处理...

# 解锁（Lua 验证 token）
EVAL "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end" 1 lock:order:123 "uuid-abc"

场景 3：滑动窗口限流

# 每分钟最多 100 请求
ZADD rate:{ip} {now_ms} {request_uuid}
ZREMRANGEBYSCORE rate:{ip} 0 {now_ms - 60000}
COUNT=$(ZCARD rate:{ip})
EXPIRE rate:{ip} 120

if [ $COUNT -gt 100 ]; then
  echo "限流触发"
fi

常见问题 FAQ

Q1：纯缓存该用哪种淘汰策略？ A：allkeys-lru。所有键都是缓存，LRU 淘汰最久未用的最合理。

Q2：maxmemory 设多少合适？ A：物理内存的 60-70%。留余量给操作系统和 RDB fork（BGSAVE 需要内存副本）。

Q3：RDB 和 AOF 能同时开吗？ A：能。数据安全要求高时都开。重启时优先用 AOF 恢复（更完整），RDB 作为备份。

Q4：集群最少几个节点？ A：最少 3 主 3 从（6 节点）。3 主保证哈希槽全覆盖，3 从保证高可用。

Q5：大 Key 怎么安全删除？ A：用 UNLINK（Redis 4+）异步删除，不阻塞主线程。旧版本用 DEL 会阻塞。

故障排查

依赖说明

运行环境

• Agent 平台：支持 SKILL.md 的任意 AI Agent（Claude Code / Cursor / Codex / Gemini CLI 等）
• 操作系统：Windows / macOS / Linux
• Redis：5.0+（推荐 7.0+，支持 Streams/UNLINK 等新特性）

第三方依赖

API Key 配置

• 本 Skill 无需 API Key
• Redis 连接通过 redis-cli 或客户端库配置 host/port/password
• 生产环境建议配置 requirepass 或 ACL

可用性分类

• 分类：MD+EXEC（Markdown 指令 + exec 命令行执行）
• 说明：基于 Markdown 的 AI Skill 驱动 Agent 执行 Redis 操作。设计与决策指南纯 Markdown 可理解；实际命令执行需 Redis 环境与 redis-cli。