Redis 从 0 到 1（三十七·收官）：36 篇浓缩成 1 张知识地图 + 50 项生产 Checklist

我不会起名字322 · 后端 / 算法 / 数据库

📘 技术栈｜ 🧩 力扣 Hot100 ｜ 🐹 Go 项目｜ 🟥 Redis ｜ 🐬 MySQL

文章目录

[Redis 从 0 到 1（三十七·收官）：36 篇浓缩成 1 张知识地图 + 50 项生产 Checklist](#Redis 从 0 到 1（三十七·收官）：36 篇浓缩成 1 张知识地图 + 50 项生产 Checklist)
- 一、知识地图：四个象限
- [二、50 项生产 Checklist（收藏点 1）](#二、50 项生产 Checklist（收藏点 1）)
- - [A. 部署与配置（1~10）](#A. 部署与配置（1~10）)
  - [B. 客户端（11~18）](#B. 客户端（11~18）)
  - [C. 数据结构与 key 设计（19~27）](#C. 数据结构与 key 设计（19~27）)
  - [D. 可靠性与一致性（28~36）](#D. 可靠性与一致性（28~36）)
  - [E. 监控与运维（37~44）](#E. 监控与运维（37~44）)
  - [F. 容量与应急（45~50）](#F. 容量与应急（45~50）)
- [三、系列代码仓库结构（收藏点 2）](#三、系列代码仓库结构（收藏点 2）)
- [四、系列复盘：37 篇里最值钱的 5 句话](#四、系列复盘：37 篇里最值钱的 5 句话)
- 五、写在最后

Redis 从 0 到 1（三十七·收官）：36 篇浓缩成 1 张知识地图 + 50 项生产 Checklist

上一篇《Redis 从 0 到 1（三十六）：不停机把 5000 万 key 搬到新集群------3 种方案与割接清单》我们完成了搬家，链接：https://blog.csdn.net/2501_92769340/article/details/167401021 。

本篇是整个系列的收官：不引入新知识，只做一件事------把这 36 篇拧成一张能查、能背、能照着做的地图。

一、知识地图：四个象限

复制代码

                    ┌──────────────────────────┬──────────────────────────┐
                    │  ① 机制（第 5~10 篇）      │  ② 实战（第 11~20 篇）      │
                    │  单线程/epoll → 过期淘汰    │  穿透击穿雪崩 → 一致性       │
                    │  → RDB/AOF → 主从 → 哨兵    │  → 分布式锁 → 限流 → 排行榜  │
                    │  → Cluster                │  → 计数去重 → 延迟队列        │
                    │                          │  → Stream → 登录态 → Bitmap  │
    为什么慢/为什么丢 ├──────────────────────────┼──────────────────────────┤
    怎么防/怎么用     │  ③ 优化（第 21~28 篇）      │  ④ 排查（第 29~34 篇）      │
                    │  慢查询 → bigkey → hotkey  │  CPU 100% → 内存碎片         │
                    │  → Pipeline → 连接池        │  → 脑裂丢数 → Cluster 故障   │
                    │  → 内存 → 序列化 → 韧性     │  → AOF 抢救 → 连接打满       │
                    └──────────────────────────┴──────────────────────────┘
        地基（第 1~4 篇）：安装 → 连接池封装 → 五大结构 → key 设计与 SCAN
        生产化（第 35~36 篇）：监控告警 → 不停机迁移

四条主线的内在逻辑（一句话串起来）：

机制回答"为什么"：单线程决定了"任何 O(N) 操作都是全局事故"，这是后面所有排查篇的根；
实战回答"怎么用"：所有实战问题最终都落在"并发下谁能写、写多少、写错了怎么办"；
优化回答"怎么快"：快命令 + 少 RTT + 配平连接 + 省内存，四件事各占一章；
排查回答"怎么救"：先分诊（命令 or 系统事件），再定位，最后治理------五个案件共用一条链路。

二、50 项生产 Checklist（收藏点 1）

A. 部署与配置（1~10）

B. 客户端（11~18）

11. 客户端进程级单例，禁 per-request 建连（第 34 篇）
12. PoolSize = QPS × RT × 1.3（第 25 篇）
13. 三超时齐备：Dial/Read/Write + PoolTimeout（第 28 篇）
14. MaxRetries ≤ 2 且带退避；写命令靠幂等不靠重试（第 28 篇）
15. 熔断 + 降级路径（配置读回本地默认值）（第 28 篇）
16. CLIENT SETNAME 连接命名规范（部署时就设）（第 34 篇）
17. 批量操作用 Pipeline（100~500/批）或 MGET（同槽）（第 24 篇）
18. 所有命令带 context 超时 + 错误处理（第 1 篇起贯穿全程）

C. 数据结构与 key 设计（19~27）

19. key 四段式命名 + 长度 ≤ 44 字节（第 4 篇）
20. 每个 key 必有 TTL 或明确的不淘汰理由（第 4、6 篇）
21. 集合类 key 设上限（LTRIM / MAXLEN / 定期归档）（第 22 篇）
22. 大对象不塞单 value，分页/分桶存（第 22 篇）
23. 跨 key 原子操作用 hash tag 归槽（第 10 篇）
24. 排行榜/延迟队列时间戳用毫秒（第 15、17 篇）
25. UV/去重用 HLL + Bloom，别用 Set 存明细（第 16 篇）
26. 高频布尔统计用 Bitmap（第 20 篇）
27. 大基数缓存选二进制序列化（Protobuf/MsgPack）+ 统一 Codec（第 27 篇）

D. 可靠性与一致性（28~36）

28. 缓存必带 TTL，删缓存失败要重试告警（第 12 篇）
29. 一致性方案选型：常规"先更新库再删缓存"，核心业务加延迟双删（第 12 篇）
30. 穿透：布隆过滤器 + 空值缓存（第 11 篇）
31. 击穿：singleflight / SetNX 互斥重建（第 11 篇）
32. 雪崩：TTL 随机抖动（第 11 篇）
33. 分布式锁：SET NX PX + token 校验 + 看门狗（第 13 篇）
34. 消息用 Stream 消费组 + XACK + pending 监控，不用 List/PubSub 承载业务（第 18 篇）
35. 延迟任务用 ZSet 队列，任务只存 id，业务幂等（第 17 篇）
36. 限流 key 带 TTL，拒绝时返回 429 + Retry-After（第 14 篇）

E. 监控与运维（37~44）

37. redis_exporter + Grafana 面板接入（第 35 篇）
38. 10 指标看板 + 5 条告警上线（第 35 篇）
39. slowlog 阈值 10ms + 采集器自动告警（第 21 篇）
40. --bigkeys 周巡检（第 22 篇）
41. hotkey 采样发现机制（大促前）（第 23 篇）
42. 碎片率趋势监控，>1.5 处理（第 30 篇）
43. 主从 offset 差监控 + 切换后自动对账（第 8、31 篇）
44. 备份策略：RDB 定时备份 + 异地存放 + 定期恢复演练（第 7、33 篇）

F. 容量与应急（45~50）

45. 容量公式：数据 × 结构系数 + key 开销 + 缓冲 + 碎片（第 26 篇）
46. 扩容路径预演：单实例 → 哨兵 → Cluster（第 9、10 篇）
47. 迁移 SOP + 割接 checklist 演练（写入源唯一）（第 36 篇）
48. 应急手册：CPU 100% / 内存飙升 / 拒连 / 数据损坏四类现场处置（第 29、30、33、34 篇）
49. 故障注入演练：kill 从库 / 断网 / 打满连接（第 9、28、34 篇）
50. 复盘机制：每次事故产出"现象 → 根因 → 整改 → 回归"四段报告（全系列方法）

三、系列代码仓库结构（收藏点 2）

这个系列所有 Go 代码汇总成一个可复用模块：

复制代码

redis-0to1/
├── redisx/          # 第 2 篇：连接封装（池配平/超时/重试/健康检查/PoolStats）
│   ├── redisx.go
│   └── lock.go      # 第 13 篇：分布式锁（SET NX PX + WATCH/MULTI + 看门狗）
├── cache/           # 第 11/12/23 篇：穿透防御、一致性封装、本地二级缓存
├── ratelimit/       # 第 14 篇：三种限流算法
├── delayq/          # 第 17 篇：ZSet 延迟队列
├── codec/           # 第 27 篇：统一序列化接口
├── resilience/      # 第 28 篇：熔断器
├── bloom/           # 第 11/16 篇：Bitmap 布隆过滤器
└── observability/   # 第 35 篇：PoolStats + 命中率 exporter

四、系列复盘：37 篇里最值钱的 5 句话

单线程是理解一切故障的钥匙------任何 O(N) 命令都是全局事件（第 5 篇）；
每个 key 都要有归宿------TTL、上限、或一份"为什么可以不删"的文档（第 4 篇）；
异步复制是原罪------主从一切丢数都能追到这句话（第 8、31 篇）；
先分诊再动手------CPU/内存/连接异常，先判断是"命令"还是"系统事件"（第 29、30 篇）；
切换时刻最危险------写入源唯一是铁律（第 31、36 篇）。

五、写在最后

这个系列从 docker compose up 开始，到脑裂、AOF 损坏、连接泄漏结束，一共 37 篇、约 13 万字、90 多个可运行 Go 示例。所有代码坚持一件事：不用 Lua、只用 Go 和 Redis 的基础命令------不是排斥脚本，而是想让每一步都看得见、能调试、可回滚。

如果这个系列帮你少熬一个夜，或者少丢一页订单，它就算写成了。

系列到此收官，无下一篇预告。 全部 37 篇已归档在「redis」专栏，建议按 ① 机制 → ② 实战 → ③ 优化 → ④ 排查的顺序读；应急时直接跳对应案件篇。欢迎在评论区留下你踩过的坑，后续如果收集到足够多的真实现场，我会做一辑《番外篇：来自评论区的 10 个 Redis 事故》。