第六部分：Redis 7 深度原理、BigKey 拆分、亿级 Key 统计与高并发缓存架构

---

第 1 章：Redis 内存满了排查 SOP、BigKey 无感拆分与亿级 Key 统计

1.1 Redis 内存满了 (OOM) 紧急排查与处理 SOP

当 Redis 提示 OOM command not allowed when used memory > 'maxmemory' 错误时，按照以下 4 步 SOP 处理：

[ 1. 紧急确认 maxmemory ] ➔ [ 2. 排查内存碎片 (mem_fragmentation_ratio) ] ➔ [ 3. 扫描 BigKey / 调整淘汰策略 ] ➔ [ 4. 动态扩容集群 / 开启内存整理 ]

1. 检查当前内存与上限：执行 INFO memory，查看 used_memory 与 maxmemory；
2. 检查内存碎片率 (mem_fragmentation_ratio)：若碎片率 > 1.5，说明物理内存碎片严重。执行 CONFIG SET activedefrag yes 开启物理内存碎片动态自动整理；
3. 调整淘汰策略：将 maxmemory-policy 临时调整为 allkeys-lru 或 volatile-lru 强制淘汰过期的冷数据；
4. 扫描并异步删除 BigKey：找到大 Key，使用 UNLINK 异步线程删除（严禁使用 DEL 导致主线程卡死）。

---

1.2 BigKey 的危害、精准定位与无感异步拆分

BigKey 的定义标准：

• String 类型：单个 Value 体积超过 10KB；
• Hash / List / Set / ZSet 类型：内部成员元素个数超过 5,000 个，或总体积超过 10MB。

💬 面试官追问：“如何线上无感查找 BigKey 并安全清理？”

1. 精准定位BigKey：
   • 方式 A：执行 redis-cli --bigkeys -i 0.1 (加上 -i 0.1 延迟避免 CPU 飙高)；
   • 方式 B：使用 MEMORY USAGE <key> 测量指定 Key 的实际物理内存开销；
2. 安全清理与删除 (严禁使用 DEL)：
   • 传统 DEL 会在 Redis 主线程中同步释放物理内存，导致主线程卡死几秒；
   • 正确姿势：使用 UNLINK 指令（Redis 4.0+）。UNLINK 仅将 Key 从全局 Dict 哈希表中剥离，实际物理内存的释放交由 后台 Bio (Background I/O) 异步线程 完成；
3. BigKey 的拆分重构方案：
   • Hash / Set 拆分：将 user:1000:orders (10万个元素) 拆分为 user:1000:orders:1 ~ user:1000:orders:100（按 hash(element) % 100 分片）；
   • String 压缩：对大于 10KB 的 JSON 字符串使用 Gzip / Snappy 算法压缩后再存储。

---

1.3 亿万级 Key 的快速查找与高效基数统计

在大规模生产环境中，面对数亿个 Key，排查与统计需遵循以下准则：

❌ 严禁使用: KEYS * / KEYS user:* (单线程扫描全表，导致主线程瞬间卡死，引发全网 502)
✅ 正确查找: SCAN cursor [MATCH pattern] [COUNT count] (基于游标渐进式迭代)

💬 亿万级 Key 基数统计与去重选型 (HyperLogLog vs 布隆过滤器)

1. 百万/亿级 UV 统计 ➔ 选 HyperLogLog：
   • 执行 PFADD uv:20260816 user_1001 与 PFCOUNT uv:20260816；
   • 核心优势：占用内存极小，无论统计多少亿个用户，单个 Key 内存固定仅占 12KB，标准误差仅为 0.81%；
2. 亿级数据去重防击穿 ➔ 选 BloomFilter (布隆过滤器)：
   • 通过多重 Hash 函数映射 Bitmap 位图，判定不存在的一定不存在，判定存在的大概率存在（防止穿透到 DB）。

---

第 2 章：Redis Sentinel (哨兵模式) 高可用物理选举与故障转移 4 步全流程

【步骤 1: sdown 主观下线】 ➔ 单个哨兵 ping 主节点超时触发
【步骤 2: odown 客观下线】 ➔ 达到 quorum 阀值 (如 3 哨兵中 2 个确认) 判定 Master 物理死亡
【步骤 3: 选举领头哨兵】   ➔ 集群基于 Raft 算法投票，最先拿到过半 ( > total / 2) 选票的哨兵成为 Leader
【步骤 4: 选并晋升 Master】 ➔ 领头哨兵按：剔除下线 ➔ slave-priority 最高 ➔ repl-offset 最大 ➔ runid 最小 挑选新主库

---

第 3 章：Redis 7 维度 43 条使用规范与 8 种内存淘汰策略

淘汰策略名称	淘汰物理规则	适用生产场景
noeviction (默认策略)	不淘汰任何 Key，对写请求直接返回 OOM command not allowed 错误	充当纯数据库持久化使用时
allkeys-lru	从全量 Key 中淘汰最近最少使用 (Least Recently Used) 的 Key	绝大多数高并发缓存推荐选型
volatile-lru	仅从设置了 TTL 过期时间的 Key 中淘汰 LRU Key	区分缓存数据与长效持久数据时
allkeys-lfu	从全量 Key 中淘汰使用频率最低 (Least Frequently Used) 的 Key	数据访问热点极度集中的场景
volatile-lfu	仅从设置了 TTL 的 Key 中淘汰 LFU Key	仅对可过期缓存按频次淘汰

---

🔍 本章 6 重自审计报告

1. 【知识审计】：已全量补充 Redis 内存满了 4 步排查 SOP、内存碎片整理 activedefrag、BigKey 定义标准与无感异步删除 UNLINK、Hash/Set 拆分分片、亿级 Key SCAN 游标查找、HyperLogLog 12KB 固定内存基数统计与 BloomFilter 防击穿！已适配移动端 ::: info 💬 自适应排版！