KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

07 · 生产落地：监控指标、故障手册与四类角色的形态选择 — keel 龙骨

最后一章把前六章收成能直接用的东西：该盯哪些指标、出问题先查什么、以及回到第 00 章那四类 Redis 角色（缓存 / 队列 / 锁 / 事件流），逐个说明它们该配哪种形态、代码上要注意什么。

最后一章把前六章收成能直接用的东西：该盯哪些指标、出问题先查什么、以及回到第 00 章那四类 Redis 角色（缓存 / 队列 / 锁 / 事件流），逐个说明它们该配哪种形态、代码上要注意什么。

一、现场：报警响了，但不知道该看哪

凌晨收到"接口 P99 变高"。打开监控：CPU 正常、内存平稳、连接数不高。没有方向。

这类工单的共性是：监控采的是"资源指标"，而出问题的是"拓扑状态"。复制延迟、槽覆盖、切换事件这些拓扑指标没采，就只能靠猜。

二、监控清单：按形态分组

通用（三套形态都要）

主从 / 哨兵

集群

三、故障手册：症状 → 根因 → 第一步动作

排障路径收敛成一张图：

flowchart TD
    A["Redis 相关报警"] --> B{"是连通性问题<br/>还是正确性问题？"}
    B -- 连通性 --> C{"集群还是主从？"}
    C -- 主从 --> C1["看 master_link_status<br/>与哨兵 flags"]
    C -- 集群 --> C2["看 cluster_state<br/>与 cluster_slots_fail"]
    C1 --> C3{"正在切换？"}
    C3 -- 是 --> C4["等重试生效<br/>（第 03 章）"]
    C3 -- 否 --> C5["查进程/网络/连接数"]
    C2 --> C6{"槽有缺失？"}
    C6 -- 是 --> C7["补副本或重新认领槽"]
    C6 -- 否 --> C8["查节点存活与总线端口"]
    B -- 正确性 --> D{"读到旧值<br/>还是读到缺失？"}
    D -- 旧值 --> D1["比 offset 差<br/>确认该读是否必须走主"]
    D -- 缺失 --> D2{"刚发生切换或迁移？"}
    D2 -- 是 --> D3["异步复制丢数据（04章）<br/>或迁移中断（06章）"]
    D2 -- 否 --> D4["查是否写到了别的节点<br/>（MOVED/CROSSSLOT 被吞）"]
    B -- 慢 --> E["查 SLOWLOG + 客户端侧 P99<br/>区分服务端慢与网络慢"]

四、四类角色怎么选形态（本课的应用落地）

回到第 00 章那张表。核心建议先说：按角色拆实例，不要让"要安全的数据"替"要吞吐的数据"做妥协。

缓存（article:{1001}:detail）

• 形态：主从 + 读写分离最合适（读多写少、丢了可重建）；量大了再考虑集群。
• 代码：可陈旧读走从库，写后读走主库（第 02 章的 allow_stale）。
• 集群下：批量 MGET 需要 hash tag，否则拆成 pipeline 单取。
• 兜底：缓存不可用时必须能穿透到源（数据库），否则从库挂一次整站就挂。

队列（ARQ）

• 形态：独立的一套主从实例。副本策略按"能不能丢"决定：能容忍少量丢失就配副本；不能容忍就宁可不轻易切换，改用持久化与对账。
• 集群下的现实问题：ARQ 一次操作会碰多个 key（任务 Hash、结果 key、队列 Stream、延迟 ZSet），而集群要求同一操作——尤其是 Lua 脚本——涉及的所有 key 落在同一个槽。社区版 ARQ 没有官方的集群支持。
• 两条可行做法：① 用 hash tag 把相关 key 绑到同槽（要改 key 生成逻辑，等于改库，成本高）；② 更现实的是让它跑在非集群实例上。这正是"按角色拆实例"的价值。
• 无论哪种形态：队列的正确性最终靠消费者 ACK + 可重放 + 对账，不靠复制（第 04 章）。

锁（lock:index:{1001}）

• 单 key，三种形态下都能用，没有跨槽问题。
• 真正的风险是第 04 章那条：切换会让锁失效，这在集群里同样成立（副本提升也是异步复制）。
• 形态建议：锁放在切换频率低的实例上（例如不与缓存共用），并把临界区做成幂等。

事件流（Stream + 消费者组）

• Stream 本身是单 key，天然同槽；跨多个 stream 的 XREAD 需要它们同槽（hash tag）。
• 断线重续依赖客户端保存的 last-id；切换后要能用 last-id 在新主上继续读，丢失的那一小段要有补偿（重放或兜底查询）。
• 与本站「实时推送与 SSE」课程第 04 章（断线重连与续播）互为补充。

五、客户端侧的落地清单

上任何形态之前，客户端这一层必须过关：

1. 读写分流有显式开关（allow_stale），而不是埋在配置里；
2. 写失败有重试，重试覆盖切换窗口（第 03 章 safe_write）；
3. 从库失败能回退主库，且回退有打点；
4. 连接池按角色分开（读池 / 写池），避免一个池打满影响另一路；
5. 超时设置合理：连接超时 < 命令超时 < 业务超时，否则重试会叠加成雪崩；
6. 多键与 Lua 已按 hash tag 改造（若上集群）；
7. 客户端库支持对应形态：哨兵客户端 / 集群客户端，并验证过切换与重定向行为。

六、上线检查清单

七、练习与验收

练习 1：按第 02 节的表，把你环境的实际取值填一遍，指出哪些指标目前没采集。

练习 2：从第 06 节的四类角色里挑一类，为它写一份"形态选择说明"：为什么选这个形态、代码上要改什么、出问题怎么降级。

练习 3：按第 03 节的故障手册，给自己系统里最近的一次 Redis 故障写一份复盘：症状属于哪一类、当时的第一步动作对不对。

验收点：不看资料，说出三套形态各自的关键监控项；对"读到旧值""写报 READONLY""切换后丢数据""CROSSSLOT"四种症状，立刻给出第一步排查动作；说明四类角色各自的形态选择与理由。

全课收口：回到第 00 章的决策图。现在你应该能不看资料画出它，并对每条分支说出"为什么"——瓶颈是什么、这套形态解决什么、代价是什么、应用代码要改什么。三句话总结全课：

1. 复制让数据多一份，但它是异步的，且不提供路由；
2. 哨兵解决主库单点，不解决容量，也不保证写入安全；
3. 集群解决容量，代价是跨槽能力受限——而真正的难点从来不是搭集群，是 key 设计。

进入 keel 阅读