Redis（远程字典服务）线上排障与综合题库

本分册把前七册的机制收束成可执行的现场 SOP（标准操作流程）。你要先保护业务不变量，再保留可复核证据，最后定位、修复、验证和复盘；不能把一次恢复当作根因已经消失。

1. 使用边界、分册导航与事故原则

本册假设你已掌握 00-知识图谱与复习路线、01-数据结构命令语义、02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。命令均先在只读副本、低峰演练环境或受限采样窗口验证；生产执行前必须确认版本、权限、拓扑和命令成本。

1.1 事故处置的六步闭环

1. 止血：限流、摘流、降级、暂停高风险写入或切换只读路径，优先保护库存、支付和任务状态机。
2. 取证：保存时间窗、节点、命令、配置、监控和业务请求标识；所有结论都应能回放。
3. 分层定位：按客户端、网络、事件循环、数据、持久化、复制与业务一致性逐层排除。
4. 修复：选择可逆且影响范围最小的动作，避免在故障期间执行全量扫描、危险删除或扩缩容。
5. 验证：同时验证技术指标、业务不变量和回归窗口，不能只看告警恢复。
6. 复盘：写清触发条件、放大链路、检测缺口、决策依据、长期改造与演练项。

flowchart LR
    A[告警或业务症状] --> B[止血：保护不变量]
    B --> C[取证：固定时间窗]
    C --> D[分层定位]
    D --> E[可逆修复]
    E --> F[技术与业务验证]
    F --> G[复盘与演练]
    G --> A

热门面试题

问题 01：线上 Redis（远程字典服务）事故为什么不能一上来查根因？

• 回答思路：先按业务损失排序，再在可控条件下取证。
• 详细答案：事故最初几分钟的目标是阻止错误继续扩大，而不是立刻证明某个技术猜测。库存超卖、资金重复推进和锁失效会破坏不可逆业务事实，应先限流、关闭高风险入口或回退到权威存储；轨迹查询变慢则可优先降级。止血之后再固化节点、时间窗、命令统计、慢日志和业务请求标识，才能避免临时动作覆盖根因。该顺序也防止值班人员在高压下执行 FLUSHALL（清空全部数据）或全库扫描等放大操作。
• 进阶追问：止血会不会影响取证？
• 进阶回答：会，因此止血动作也必须记录开始时间、范围和开关值，并先抓取短时间窗的核心指标；无法完全保留现场时，优先保留对业务不变量和故障节点最有解释力的证据。

2. 线上排障 SOP（标准操作流程）一：延迟升高

kb:knowledge-01：延迟升高的分层定位

+#### 热门面试题（六字段）

1. 问题：延迟升高发生时，怎样先判断端到端延迟？

• 考点：慢命令、事件循环和客户端重试。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：延迟升高发生时，怎样先判断端到端延迟？

• 考点：慢命令、事件循环和客户端重试。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：延迟升高发生时，怎样先判断端到端延迟？

• 考点：慢命令、事件循环和客户端重试。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

延迟应拆成客户端排队、网络往返、服务端事件循环排队、命令执行、持久化阻塞和复制等待。P99（99 分位响应时间）升高而平均值稳定，常见于少量大键、慢命令、fork（创建子进程）或磁盘抖动造成的队头阻塞；所有分位一起抬升，更像容量饱和、网络故障或连接池排队。

flowchart TD
    A[P99 升高] --> B{客户端排队升高？}
    B -- 是 --> C[连接池、线程池、重试检查]
    B -- 否 --> D{服务端慢日志或事件延迟？}
    D -- 是 --> E[慢命令、大键、Lua 脚本与 fork 检查]
    D -- 否 --> F{网络重传或 RTT 升高？}
    F -- 是 --> G[链路、DNS 与跨可用区检查]
    F -- 否 --> H[磁盘、复制或持久化等待检查]

止血：对非关键读启用短时本地缓存和请求合并；限制批量接口页大小；暂停大规模回填、全量预热与长 Lua（脚本语言）；将关键库存、支付写后读路由回主节点或权威库。不要通过无限增加客户端超时掩盖队列积压。

取证命令与风险：

redis-cli -h <host> -p <port> SLOWLOG GET 128
redis-cli -h <host> -p <port> LATENCY LATEST
redis-cli -h <host> -p <port> INFO commandstats
redis-cli -h <host> -p <port> INFO clients
redis-cli -h <host> -p <port> --latency-history

SLOWLOG（慢日志）只记录执行时间而非网络等待；--latency-history（延迟历史采样）会持续占用一个连接，排障结束要退出；MONITOR（实时命令监视）会放大输出和网络流量，生产默认禁止。

根因：某运营接口使用未受限范围的 ZRANGE（有序集合范围查询）导出全部预占记录，单线程命令执行期间其他请求无法被处理；客户端超时重试使同一分片排队加长。

修复验证：把导出改为离线分批任务，并增加范围上限和游标；观察连续 30 分钟 P50（50 分位响应时间）、P99（99 分位响应时间）、慢日志长度和重试率均回到基线，同时用订单幂等号核对未重复冻结库存。

复盘：为每类命令设定复杂度和结果集上限，压测中注入长命令，并在仪表盘同时展示命令耗时、事件循环延迟和客户端重试，避免只监控平均响应时间。

热门面试题

延迟升高的补充讨论

问题 02：Redis（远程字典服务）是单线程，为何延迟问题常常不是 CPU（中央处理器）问题？

• 回答思路：单线程指命令执行主路径；等待可发生在客户端、网络、磁盘与队列。
• 详细答案：Redis（远程字典服务）主线程串行执行命令，一个慢命令会造成队头阻塞，但用户感知延迟还包含连接池取连接、内核网络排队、协议解析、回复缓冲写回、fork（创建子进程）的页表复制和磁盘 fsync（同步写入）抖动。CPU（中央处理器）不高时，主线程仍可能在等待网络可写、持久化或者被大键操作占住；因此需要同时看慢日志、事件延迟、客户端缓冲和系统级网络指标，而不是只看 CPU（中央处理器）百分比。
• 进阶追问：P99（99 分位响应时间）突刺但慢日志为空怎么办？
• 进阶回答：优先排查客户端排队、网络重传、输出缓冲背压、fork（创建子进程）和磁盘停顿；慢日志只统计命令执行时间，不能证明请求端到端没有慢。

3. 线上排障 SOP（标准操作流程）二：CPU（中央处理器）高

kb:knowledge-02：CPU（中央处理器）高的命令与系统归因

+#### 热门面试题（六字段）

1. 问题：CPU（中央处理器）高发生时，怎样先判断CPU（中央处理器）归因？

• 考点：命令累计耗时、内核态和子进程。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：CPU（中央处理器）高发生时，怎样先判断CPU（中央处理器）归因？

• 考点：命令累计耗时、内核态和子进程。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：CPU（中央处理器）高发生时，怎样先判断CPU（中央处理器）归因？

• 考点：命令累计耗时、内核态和子进程。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

Redis（远程字典服务）CPU（中央处理器）高应先区分主进程用户态、内核态、子进程和同机干扰。用户态高通常是命令计算、编码解码、过期扫描或脚本；内核态高常见于网络软中断、复制流量或磁盘；子进程高则指向 RDB（快照持久化）或 AOF（追加日志）重写。

flowchart LR
    A[CPU 高] --> B{redis-server 主进程？}
    B -- 用户态 --> C[commandstats 与 slowlog]
    B -- 内核态 --> D[网络软中断与磁盘]
    B -- 否 --> E{子进程？}
    E -- 是 --> F[RDB/AOF 重写、COW 检查]
    E -- 否 --> G[同机容器与宿主机争抢]

止血：关闭或限频非必要 EVAL（执行脚本）、大范围聚合和低价值统计；限制热点接口并做请求合并；若子进程导致资源竞争，延后非紧急快照或重写，但必须记录持久化风险窗口，不能长期关闭。

取证命令与风险：

redis-cli INFO cpu
redis-cli INFO commandstats
redis-cli SLOWLOG GET 128
redis-cli --bigkeys
pidstat -u -p <redis_pid> 1 30
top -H -p <redis_pid>

--bigkeys（大键采样）会扫描键空间，低峰和限时执行；pidstat（进程统计）与 top（系统监控）仅取样，不应据一次快照断言根因。

根因：每条报警都执行一次跨设备集合聚合脚本，报警风暴将每秒脚本数放大近 47 倍；脚本虽未单次超时，却挤占主线程。

修复验证：改为按设备分片聚合、100 毫秒窗口批处理和异步告警摘要；压测 15 000 条/秒时 CPU（中央处理器）低于 70%，P99（99 分位响应时间）低于 50 毫秒，并确认严重报警不因聚合而丢失。

复盘：建立脚本 SHA（安全散列算法）白名单、调用速率和耗时分位监控；将突发流量演练纳入 IoT（物联网）报警规则发布流程。

热门面试题

CPU（中央处理器）高的补充讨论

问题 03：CPU（中央处理器）高时为什么不能直接扩容 Redis（远程字典服务）实例？

• 回答思路：先判定瓶颈是否可由分片分摊，避免把问题复制到更多节点。
• 详细答案：如果高 CPU（中央处理器）来自单个热键、长脚本或单槽大集合，增加节点不会自动分散该键，甚至迁槽会增加网络和复制负担。若来自全局 KEYS（列出所有键）或客户端重试，扩容也只是在更大容量上保留错误模式。只有确认键可均匀分片、客户端路由正确、热点已拆散且宿主机资源足够时，扩容才是有效手段。应先用命令统计和键分布确认工作量，再决定优化命令、拆键、隔离热点或扩容。
• 进阶追问：CPU（中央处理器）高而慢日志没有长命令意味着什么？
• 进阶回答：可能是大量中等耗时命令、过期清理、协议编解码、网络软中断或子进程竞争；需要看每秒命令数、命令累计耗时与系统态 CPU（中央处理器）。

4. 线上排障 SOP（标准操作流程）三：内存暴涨

kb:knowledge-03：内存暴涨、碎片与淘汰边界

+#### 热门面试题（六字段）

1. 问题：内存暴涨发生时，怎样先判断内存归因？

• 考点：数据集、缓冲区、碎片和 COW（写时复制）。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：内存暴涨发生时，怎样先判断内存归因？

• 考点：数据集、缓冲区、碎片和 COW（写时复制）。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：内存暴涨发生时，怎样先判断内存归因？

• 考点：数据集、缓冲区、碎片和 COW（写时复制）。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

内存增长必须区分业务数据、客户端输出缓冲、复制积压、AOF（追加日志）重写缓冲、写时复制 COW（写时复制）页、内存碎片和宿主机页缓存。used_memory（已用内存）增长不等于真正可用内存下降；应同时比对 used_memory_rss（常驻集大小）、碎片率和各缓冲区。

flowchart TD
    A[内存接近上限] --> B{used_memory 与 RSS 同涨？}
    B -- 是 --> C[业务键、缓冲、复制与 COW]
    B -- 否 --> D[碎片、分配器与宿主机检查]
    C --> E{淘汰已发生？}
    E -- 是 --> F[缓存策略与业务降级]
    E -- 否 --> G[maxmemory 与容量余量]

止血：立即停止大批量写入、回填和预热；对非关键键设置短期降级或按业务分片限流；必要时摘除慢客户端和暂停全量同步。不要随意 DEL（删除键）巨大键，释放过程本身可能阻塞；使用 UNLINK（异步删除键）也要评估后台释放队列。

取证命令与风险：

redis-cli INFO memory
redis-cli MEMORY STATS
redis-cli INFO clients
redis-cli INFO replication
redis-cli INFO persistence
redis-cli --memkeys

--memkeys（按内存采样键）是渐进扫描但仍会增加负载；MEMORY DOCTOR（内存诊断）给出启发式建议，不能替代业务键和缓冲区的归因。

根因：一台跨可用区从节点网络抖动，主节点持续积累复制输出缓冲；同时轨迹批量回填增加写入，内存逼近 maxmemory（最大内存）后开始淘汰查询缓存。

修复验证：摘除异常从节点、限速回填并在恢复后分批重建复制；确认输出缓冲持续下降、淘汰计数停止增长、轨迹查询命中率恢复，并对比权威轨迹事件确保没有把缓存淘汰误判为事件丢失。

复盘：为副本输出缓冲、偏移差和内存余量设置联动告警；跨可用区副本要有独立带宽预算和自动摘除阈值。

热门面试题

内存暴涨的补充讨论

问题 04：used_memory（已用内存）未满，为什么进程仍可能被 OOM（内存不足杀手）杀死？

• 回答思路：Redis（远程字典服务）内存上限不覆盖所有进程和容器内存。
• 详细答案：maxmemory（最大内存）主要约束可淘汰的数据集，复制缓冲、客户端输出缓冲、AOF（追加日志）重写缓冲、fork（创建子进程）后的 COW（写时复制）页、分配器碎片和页缓存都可能额外消耗内存。容器限制通常看 RSS（常驻集大小）或控制组总内存，所以 used_memory（已用内存）低于配置值并不能证明安全。正确容量规划要为上述峰值预留空间，并在快照、重写、全量同步和写入高峰叠加时演练。
• 进阶追问：调大 maxmemory（最大内存）是否能解决？
• 进阶回答：只有宿主机和容器确有余量、增长确属数据集且淘汰策略合理时才可能缓解；若根因是缓冲或 COW（写时复制），调大反而缩小安全余量。

5. 线上排障 SOP（标准操作流程）四：大键与热键

kb:knowledge-04：big key（大键）与 hot key（热键）的双维治理

+#### 热门面试题（六字段）

1. 问题：big key（大键）与 hot key（热键）发生时，怎样先判断大键和热键差异？

• 考点：数据规模、访问倾斜和拆分边界。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：big key（大键）与 hot key（热键）发生时，怎样先判断大键和热键差异？

• 考点：数据规模、访问倾斜和拆分边界。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：big key（大键）与 hot key（热键）发生时，怎样先判断大键和热键差异？

• 考点：数据规模、访问倾斜和拆分边界。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

big key（大键）是单个键的字节数或元素数过大，风险是命令阻塞、网络大包、迁槽和复制变慢；hot key（热键）是访问集中，风险是单分片 CPU（中央处理器）与网络饱和。两者可重合，但治理不同：大键优先拆结构和异步释放，热键优先分片、复制读、请求合并和本地缓存。

flowchart LR
    A[键异常] --> B{大小异常？}
    B -- 是 --> C[big key：拆分、分页、UNLINK]
    B -- 否 --> D{访问集中？}
    D -- 是 --> E[hot key：分片、合并、本地缓存]
    D -- 否 --> F[检查命令模式与连接缓冲]

止血：为热键加本地短 TTL（生存时间）缓存和单飞请求合并；将非强一致查询导向只读副本；暂停对大键的完整读取、删除和迁槽。不能用随机加后缀拆分需要原子读改写的库存键，拆分前要先定义聚合与一致性语义。

取证命令与风险：

redis-cli --bigkeys
redis-cli --memkeys
redis-cli INFO commandstats
redis-cli CLIENT LIST
redis-cli CLUSTER KEYSLOT <key>

CLIENT LIST（客户端列表）包含地址、名称和缓冲信息，属于敏感运行数据；输出应脱敏保存。--bigkeys（大键采样）不是全量审计，不能因为未命中就排除大键。

根因：直播入口将所有请求聚集到同一商品详情键，客户端无本地缓存、无请求合并，导致单槽成为瓶颈。

修复验证：详情读采用 200 至 500 毫秒随机 TTL（生存时间）本地缓存和单飞加载，静态字段拆到内容分发网络；在同等 5 倍流量下热点分片 CPU（中央处理器）低于 70%，库存价格版本变化能在业务允许窗口内收敛。

复盘：发布前做热键预测，监控前 N（数量）键的请求占比和槽位负载；对价格、库存等不同一致性等级分别设计缓存策略。

热门面试题

大键与热键的补充讨论

问题 05：如何安全拆分一个超大 ZSet（有序集合）？

• 回答思路：按可查询边界拆分、保留分页语义、迁移期间双读校验。
• 详细答案：先确认 ZSet（有序集合）承担的是时间线、排行还是延迟队列。按时间桶、租户、仓库或业务分区拆键，使一次范围查询只命中有限元素；查询层根据时间范围或游标扇出有限分片并归并结果。迁移阶段先双写新旧键，影子读比对数量、最小最大分数和分页边界，再切读并保留旧数据到回滚窗口结束。删除旧键使用 UNLINK（异步删除键）或分批删除，避免主线程长时间释放内存。
• 进阶追问：能否按随机哈希直接拆？
• 进阶回答：可以均衡写入，却会破坏按分数范围查询的局部性并放大归并；除非查询本身支持全分片聚合，否则应按访问边界拆。

6. 线上排障 SOP（标准操作流程）五：连接与缓冲

kb:knowledge-05：连接耗尽、慢客户端与背压

+#### 热门面试题（六字段）

1. 问题：连接与缓冲发生时，怎样先判断慢客户端？

• 考点：连接池、输出缓冲和背压。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：连接与缓冲发生时，怎样先判断慢客户端？

• 考点：连接池、输出缓冲和背压。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：连接与缓冲发生时，怎样先判断慢客户端？

• 考点：连接池、输出缓冲和背压。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

连接问题既可能是客户端连接池泄漏，也可能是服务端查询缓冲、回复缓冲或复制缓冲堆积。慢客户端并不一定是异常客户端：下游网络慢、消费端停止读取、大返回结果和 Pub/Sub（发布订阅）订阅者积压都能把服务端内存拖高。

flowchart TD
    A[连接数或缓冲告警] --> B{connected_clients 接近上限？}
    B -- 是 --> C[连接池泄漏、短连接风暴]
    B -- 否 --> D{输出缓冲增长？}
    D -- 是 --> E[慢客户端、大响应、订阅积压]
    D -- 否 --> F[查询缓冲与协议异常]

止血：对非关键接口限并发，摘除长期不消费的订阅客户端，降低单次返回大小；保护管理连接和关键业务连接配额。不要直接把 maxclients（最大客户端数）调大，文件描述符、内存和网络队列可能先耗尽。

取证命令与风险：

redis-cli INFO clients
redis-cli CLIENT LIST
redis-cli CLIENT INFO
redis-cli CONFIG GET client-output-buffer-limit
ss -antp | rg ':<port>'

CLIENT KILL（断开客户端）会中断正在执行的业务请求，只能按客户端名称、地址和业务影响精确处理；配置读取必须核对是否由运行时覆盖。

根因：任务执行器异常重连后未归还旧连接，连接池健康检查未识别半开连接，最终耗尽 maxclients（最大客户端数）。

修复验证：按应用名分批断开泄漏连接，修复连接池生命周期和空闲回收；灰度后连接数稳定、任务领取延迟恢复，且任务唯一标识验证没有因重连重复执行。

复盘：启用客户端名称、连接生命周期指标、每服务配额与连接风暴断路器；在 Runner（执行器）故障演练中加入网络半开场景。

热门面试题

连接与缓冲的补充讨论

问题 06：为什么回复缓冲爆满时，服务端 CPU（中央处理器）可能并不高？

• 回答思路：问题是写回受阻和内存堆积，不是命令计算。
• 详细答案：Redis（远程字典服务）执行完命令后需要把回复写入客户端套接字；客户端读取慢、网络拥塞或一次返回过大时，数据留在服务端输出缓冲。主线程可以继续执行较少命令，CPU（中央处理器）未必满，但内存持续增长，最终触发缓冲限制、断开连接或 OOM（内存不足杀手）。排障要看每个客户端的输出缓冲、订阅模式、最后交互时间和返回命令，而不是仅根据总连接数判断。
• 进阶追问：断开慢客户端会不会丢消息？
• 进阶回答：Pub/Sub（发布订阅）本身不保证离线可靠投递，断开会丢未消费通知；需要可靠消费时应采用 Stream（流）或 MQ（消息队列）并设计重试和幂等。

7. 线上排障 SOP（标准操作流程）六：持久化、fork（创建子进程）与 AOF（追加日志）

kb:knowledge-06：持久化峰值与写时复制 COW（写时复制）

+#### 热门面试题（六字段）

1. 问题：持久化发生时，怎样先判断fork（创建子进程）风险？

• 考点：快照、COW（写时复制）和磁盘竞争。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：持久化发生时，怎样先判断fork（创建子进程）风险？

• 考点：快照、COW（写时复制）和磁盘竞争。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：持久化发生时，怎样先判断fork（创建子进程）风险？

• 考点：快照、COW（写时复制）和磁盘竞争。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

RDB（快照持久化）和 AOF（追加日志）重写的关键风险不是“后台”二字，而是 fork（创建子进程）瞬间的页表处理、父进程后续写入触发的 COW（写时复制）内存放大，以及磁盘吞吐与延迟。持久化失败会扩大恢复点目标 RPO（恢复点目标），不能用静默关闭来换取短期稳定。

sequenceDiagram
    participant M as 主进程
    participant K as 内核
    participant C as 子进程
    participant D as 磁盘
    M->>K: fork（创建子进程）
    K-->>M: 共享页面
    K-->>C: 快照视图
    M->>M: 新写触发 COW（写时复制）
    C->>D: 写 RDB（快照持久化）或 AOF（追加日志）
    C-->>M: 完成或失败

止血：暂停非紧急重写、限速大批量写和回填；若磁盘延迟持续异常，切走非关键流量并评估是否进入只读保护。不得删除持久化文件“腾空间”或关闭 AOF（追加日志）后不记录风险窗口。

取证命令与风险：

redis-cli INFO persistence
redis-cli INFO memory
redis-cli LATENCY DOCTOR
redis-cli CONFIG GET appendfsync
iostat -x 1 30
ps -o pid,ppid,%cpu,%mem,cmd -C redis-server

BGSAVE（后台生成快照）和 BGREWRITEAOF（后台重写追加日志）是有副作用命令，排障阶段只读状态，不能为“验证”再次触发。

根因：快照时间与支付批量状态回填重叠，父进程持续修改大量页面，COW（写时复制）放大内存并与共享盘争用；实例虽未宕机，但业务尾延迟不可接受。

修复验证：错峰快照、降低回填并发、将持久化盘与高写入实例隔离；重复注入同等写流量，验证 RSS（常驻集大小）低于容器安全线、磁盘 P99（99 分位响应时间）与接口 P99（99 分位响应时间）符合预算，并通过订单版本核对无状态倒退。

复盘：容量模型必须包含数据集、写放大、COW（写时复制）、重写缓冲和磁盘服务时间；对持久化成功率、耗时和失败原因分别告警。

热门面试题

持久化的补充讨论

问题 07：为什么 RDB（快照持久化）成功仍可能造成线上事故？

• 回答思路：成功只说明文件生成，未说明过程满足在线资源预算。
• 详细答案：RDB（快照持久化）成功时，子进程可能已经占用很长时间写盘，父进程在期间发生大量写入并触发 COW（写时复制），造成内存高峰；共享磁盘还可能使 fsync（同步写入）或读取延迟上升。若实例接近内存或磁盘边界，快照最终成功也可能让在线请求超时、容器被杀或副本掉线。评价应同时看快照耗时、内存增量、磁盘队列、P99（99 分位响应时间）和复制差。
• 进阶追问：是否应完全关闭 RDB（快照持久化）？
• 进阶回答：不能一概而论。应按恢复目标选择 RDB（快照持久化）、AOF（追加日志）或混合持久化，并通过错峰、容量预留和隔离降低过程风险；关闭会扩大恢复成本和数据风险。

8. 线上排障 SOP（标准操作流程）七：复制延迟与全量重同步

kb:knowledge-07：复制链路的差距、追赶与读陈旧

+#### 热门面试题（六字段）

1. 问题：复制延迟发生时，怎样先判断副本陈旧读？

• 考点：偏移差、应用速率和读路由。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：复制延迟发生时，怎样先判断副本陈旧读？

• 考点：偏移差、应用速率和读路由。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：复制延迟发生时，怎样先判断副本陈旧读？

• 考点：偏移差、应用速率和读路由。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

复制延迟不是单一“秒数”。要看主从偏移差、差距增长率、从节点应用速率、复制积压缓冲覆盖时间和是否进入全量重同步。偏移差扩大说明从节点净追赶速度小于主节点写入速度；读从节点时，这直接表现为陈旧读，不可用于库存放行与支付状态推进。

flowchart LR
    A[主节点写入] --> B[复制输出缓冲]
    B --> C[网络链路]
    C --> D[从节点输入与应用]
    D --> E[从节点读]
    C -. 中断超过积压覆盖 .-> F[全量重同步]
    F --> G[快照传输与加载]
    G --> D

止血：将强一致读路由主节点或 MySQL（关系型数据库），摘除严重落后副本的读流量；暂停会放大写流的大回填；根据积压缓冲覆盖时间决定优先修链路还是有序重建。不要反复重启从节点，重启可能把可部分重同步的短抖动变成全量同步。

取证命令与风险：

redis-cli INFO replication
redis-cli ROLE
redis-cli INFO stats
redis-cli INFO memory
redis-cli CONFIG GET repl-backlog-size

ROLE（复制角色信息）和 INFO replication（复制信息）只反映采样瞬间，应连续记录偏移差和增长率；修改积压缓冲区会增加主节点内存，必须先做容量核算。

根因：从节点同机分析作业抢占 CPU（中央处理器）和磁盘，复制应用速度下降；继续将读流量压向它又使资源更差。

修复验证：摘除读流量、迁出分析任务、恢复后检查偏移差单调下降并在 15 分钟内归零；库存放行请求全程走主节点或权威库，验证没有使用旧余量放行。

复盘：副本不得承载无资源隔离的分析任务；复制监控应包括差距速率、覆盖时间、全量同步次数和副本读池摘除状态。

热门面试题

复制延迟的补充讨论

问题 08：复制偏移差为零，是否能保证下一次读从节点一定读到刚写的数据？

• 回答思路：不能，观测是瞬时的，默认异步复制也不提供会话一致性。
• 详细答案：偏移差为零只说明采样时从节点已追到主节点记录的位置；采样后主节点可马上有新写，客户端若改走从节点仍可能读旧值。连接池、负载均衡和网络重试也会改变读写所在节点。库存扣减、支付状态推进和写后立即读应由路由规则保证读主或读权威库，而不是依赖一条监控指标；允许陈旧的轨迹展示才适合副本读。
• 进阶追问：WAIT（等待副本确认）能解决会话读吗？
• 进阶回答：不能直接解决。它增强写传播的确认，但后续读路由、故障转移和副本选择仍需业务侧控制。

9. 线上排障 SOP（标准操作流程）八：Sentinel（哨兵）切换

kb:knowledge-08：哨兵故障转移与脑裂收敛

+#### 热门面试题（六字段）

1. 问题：Sentinel（哨兵）切换发生时，怎样先判断脑裂风险？

• 考点：故障检测、旧主隔离和客户端发现。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：Sentinel（哨兵）切换发生时，怎样先判断脑裂风险？

• 考点：故障检测、旧主隔离和客户端发现。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：Sentinel（哨兵）切换发生时，怎样先判断脑裂风险？

• 考点：故障检测、旧主隔离和客户端发现。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

Sentinel（哨兵）切换要分别验证：主观下线、客观下线、领导者选举、候选副本选择、提升新主、重配副本、旧主回归和客户端刷新。真正危险的是旧主在网络分区中仍接受写，或者客户端长期缓存旧地址；切换“成功”不代表业务不变量已经收敛。

sequenceDiagram
    participant S as Sentinel（哨兵）
    participant O as 旧主节点
    participant R as 候选副本
    participant C as 客户端
    S->>S: 判定客观下线
    S->>R: 提升为新主
    S->>C: 发布新地址
    C->>R: 重连与幂等重试
    O-->>S: 网络恢复
    S->>O: 降级为副本并同步

止血：暂停或隔离无法确认主从角色的写入口，强制客户端刷新发现结果，保护支付和库存的幂等状态机；对旧主网络隔离或确认其拒写。不要人工把两个节点同时提升为主，也不要删除 sentinel.conf（哨兵配置文件）试图“重置”。

取证命令与风险：

redis-cli -p <sentinel_port> SENTINEL masters
redis-cli -p <sentinel_port> SENTINEL sentinels <master_name>
redis-cli -p <sentinel_port> SENTINEL replicas <master_name>
redis-cli INFO replication
redis-cli ROLE

SENTINEL FAILOVER（哨兵强制故障转移）会改变拓扑，只能在演练或明确授权下使用；排障中先读取所有哨兵视角，避免单哨兵网络孤岛造成误判。

根因：一部分应用未使用 Sentinel（哨兵）发现，而是写死旧主地址；网络分区期间旧主未被隔离，仍接收缓存写。

修复验证：改为统一发现与短连接刷新策略，设置 min-replicas-to-write（最少副本写入数）等拒写防线；在演练中断开旧主，检查权威支付流水无重复、缓存按订单版本回放后无倒退。

复盘：客户端配置也属于故障转移链路，必须纳入演练；对旧主写入数、发现刷新失败和切换时长设置可观测指标。

热门面试题

Sentinel（哨兵）切换的补充讨论

问题 09：Sentinel（哨兵）故障转移为什么仍可能丢写？

• 回答思路：复制默认异步，旧主隔离与客户端刷新也有窗口。
• 详细答案：主节点向客户端返回成功后，写可能尚未进入候选副本；主节点故障时新主从未收到该写的副本中选出，数据自然回退。网络分区时旧主若未隔离还可能继续写，形成分叉；客户端若未刷新发现结果会把请求继续发给旧主。min-replicas-to-write（最少副本写入数）和 WAIT（等待副本确认）只能降低窗口，不提供共识提交。资金和库存事实应落在权威事务存储，Redis（远程字典服务）状态通过版本、幂等和对账收敛。
• 进阶追问：如何验证切换没有伤害支付？
• 进阶回答：按订单号、渠道事件号和版本比对权威流水；缓存只允许从权威记录重建，不能以旧主残留值反向覆盖订单状态。

10. 线上排障 SOP（标准操作流程）九：Cluster（集群）槽位与网络分区

kb:knowledge-09：槽位、重定向与分区下的可用性

+#### 热门面试题（六字段）

1. 问题：Cluster（集群）槽位发生时，怎样先判断重定向处理？

• 考点：槽位状态、迁移和网络分区。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：Cluster（集群）槽位发生时，怎样先判断重定向处理？

• 考点：槽位状态、迁移和网络分区。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：Cluster（集群）槽位发生时，怎样先判断重定向处理？

• 考点：槽位状态、迁移和网络分区。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

Cluster（集群）按 slot（槽）路由，迁槽会产生 MOVED（永久重定向）和 ASK（临时重定向）。网络分区时要区分少数侧失联、主副本不可达、槽未覆盖和客户端拓扑缓存过期。对跨槽业务，哈希标签只能让相关键同槽，不会自动提供跨资源事务。

flowchart TD
    A[客户端请求 key（键）] --> B[计算 slot（槽）]
    B --> C{槽归属稳定？}
    C -- 是 --> D[目标主节点执行]
    C -- 迁移中 --> E[ASK（临时重定向）]
    C -- 已迁移 --> F[MOVED（永久重定向）]
    D --> G{网络分区？}
    G -- 是 --> H[少数侧拒写或槽不可用]
    G -- 否 --> I[正常响应]

止血：摘除槽不完整或高丢包节点，客户端开启正确的集群重定向与指数退避；对跨槽批量操作拆为可幂等子操作；关键写在分区不确定时宁可拒绝或回退权威路径。不要为了恢复可用性随意执行 CLUSTER RESET（重置集群）或强制分配槽。

取证命令与风险：

redis-cli -c CLUSTER INFO
redis-cli -c CLUSTER NODES
redis-cli -c CLUSTER SLOTS
redis-cli -c CLUSTER COUNTKEYSINSLOT <slot>
redis-cli -c CLUSTER KEYSLOT <key>

CLUSTER NODES（集群节点信息）中的地址与节点标识属于拓扑敏感数据；CLUSTER SETSLOT（设置槽状态）会直接改变集群状态，事故期除非有迁槽方案和回滚点，否则禁止执行。

根因：跨可用区网络策略误封集群总线端口，部分节点无法传播故障和槽位状态；一批旧客户端没有刷新槽位缓存。

修复验证：修复网络策略、逐节点确认 cluster_state（集群状态）为 ok（正常）和槽覆盖完整，再灰度恢复客户端；检查重定向比例回落、订单写幂等率与数据库落库数一致。

复盘：监控集群总线连通性、槽覆盖、MOVED（永久重定向）和 ASK（临时重定向）比例；发布网络策略必须包含集群端口回归测试。

热门面试题

Cluster（集群）槽位的补充讨论

问题 10：MOVED（永久重定向）和 ASK（临时重定向）为什么不能简单当作重试错误？

• 回答思路：两者表达不同拓扑状态，客户端处理不同。
• 详细答案：MOVED（永久重定向）表示槽归属已经改变，客户端应更新本地槽位映射并重发；ASK（临时重定向）通常发生在迁槽中，客户端只对该次请求先发送 ASKING（确认临时路由）再执行，不应永久修改映射。把两者当普通网络重试会持续打错节点，导致错误风暴和迁槽失败。客户端库、连接池和代理必须支持集群协议，业务层再用幂等键吸收真实执行结果未知时的重试。
• 进阶追问：哈希标签能解决跨槽事务吗？
• 进阶回答：哈希标签只把带相同标签的键映射同槽，从而允许单槽原子脚本；它不能让不同业务资源自动具备分布式事务语义。

11. 线上排障 SOP（标准操作流程）十：缓存一致性

kb:knowledge-10：缓存陈旧、失效失败与回填竞争

+#### 热门面试题（六字段）

1. 问题：缓存一致性发生时，怎样先判断陈旧缓存？

• 考点：权威源、失效事件和版本回填。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：缓存一致性发生时，怎样先判断陈旧缓存？

• 考点：权威源、失效事件和版本回填。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：缓存一致性发生时，怎样先判断陈旧缓存？

• 考点：权威源、失效事件和版本回填。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

缓存一致性故障先确定权威数据源，再定位是写库失败、删缓存失败、事件丢失、旧值回填、读从陈旧还是本地缓存未失效。任何“先更新缓存”方案都要说明失败补偿；对支付和库存，缓存不可承担最终事实。

sequenceDiagram
    participant A as 应用
    participant D as MySQL（关系型数据库）
    participant C as Redis（远程字典服务）
    participant E as 事件补偿
    A->>D: 事务更新版本
    A->>C: 删除或标记失效
    alt 删除失败
        A->>E: 记录重试事件
        E->>C: 幂等失效
    end
    A->>C: 读取未命中后按版本回填

止血：关键路径直接读权威库或只读已验证版本的缓存；暂停会反复覆盖缓存的批处理；对错误版本键做精确失效和版本围栏。不要全库清空缓存，雪崩会把 MySQL（关系型数据库）推向更大故障。

取证命令与风险：

redis-cli GET <cache_key>
redis-cli TTL <cache_key>
redis-cli OBJECT IDLETIME <cache_key>
redis-cli INFO stats
redis-cli SLOWLOG GET 64

读取缓存值可能包含个人或订单信息，证据应脱敏；TTL（生存时间）为负值要区分键不存在与无过期，不要据此盲目删除。

根因：数据库更新后缓存删除失败，延迟双删任务又被旧查询回填的版本 16 覆盖；回填未校验版本。

修复验证：缓存值携带订单版本，回填 Lua（脚本语言）只接受不低于当前版本的数据；补偿事件成功率恢复，抽样对比权威库与缓存版本，支付状态机无倒退。

复盘：失效事件使用可重放存储并监控积压；对关键读模型建立版本单调性指标和缓存/权威库差异抽检。

热门面试题

缓存一致性的补充讨论

问题 11：为什么延迟双删不是缓存一致性的万能解？

• 回答思路：它只缩小部分并发窗口，无法保证第二次删除必达或阻止乱序回填。
• 详细答案：延迟双删通过在更新数据库后再次删除缓存，降低旧读在第一次删除后回填的概率，但延迟时间无法覆盖所有慢请求、网络抖动和异步任务失败。第二次删除本身也可能失败，多个写者还会出现版本乱序。因此关键方案应以权威库事务、可重试失效事件、缓存版本和回填比较为核心；延迟双删只能作为可观测、可补偿链路中的优化，不应替代幂等和对账。
• 进阶追问：什么时候可接受短暂旧值？
• 进阶回答：商品详情、轨迹展示等可定义陈旧窗口并展示更新时间；库存放行、支付结果和状态机迁移则必须路由权威或主节点并校验版本。

12. 线上排障 SOP（标准操作流程）十一：锁丢失与双持有者

kb:knowledge-11：租约过期、主从切换与 Fencing Token（栅栏令牌）

+#### 热门面试题（六字段）

1. 问题：分布式锁发生时，怎样先判断锁丢失？

• 考点：租约、暂停和 Fencing Token（栅栏令牌）。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：分布式锁发生时，怎样先判断锁丢失？

• 考点：租约、暂停和 Fencing Token（栅栏令牌）。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：分布式锁发生时，怎样先判断锁丢失？

• 考点：租约、暂停和 Fencing Token（栅栏令牌）。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

锁丢失不等于 DEL（删除键）失败。常见根因是业务执行超过租约、客户端长暂停、看门狗续期中断、主从异步复制导致切换后锁回退、或旧客户端恢复后继续写。锁只能减少并发进入，最终资源端仍要用 Fencing Token（栅栏令牌）、条件更新和幂等状态机拒绝过期持有者。

sequenceDiagram
    participant A as 客户端 A
    participant R as Redis（远程字典服务）
    participant B as 客户端 B
    participant D as 资源库
    A->>R: 获取锁与 token（令牌） 41
    Note over A: 暂停超过租约
    B->>R: 获取锁与 token（令牌） 42
    B->>D: 写入 fencing（栅栏）=42
    A->>D: 尝试写入 fencing（栅栏）=41
    D-->>A: 拒绝旧 token（令牌）

止血：停止高风险资源写入，改为数据库条件更新或人工审批；关闭会无限续期的异常任务，保留锁键和请求标识供取证。不要通过删除全部锁键“解锁”，这会让真实临界区并发执行。

取证命令与风险：

redis-cli GET <lock_key>
redis-cli PTTL <lock_key>
redis-cli INFO replication
redis-cli SLOWLOG GET 64
redis-cli CLIENT LIST

锁值中的 token（令牌）和业务标识可能敏感，日志须脱敏；手工 DEL（删除键）只能在确认持有者已停止、资源端有围栏且变更已审批时进行。

根因：订单服务发生长时间 GC（垃圾回收）暂停，持锁线程恢复后未确认租约，继续扣减库存；资源库没有比较栅栏令牌。

修复验证：锁只作为并发削峰，扣减使用 where version = ? and available >= ?（版本与库存条件更新），并写入单调 fencing（栅栏）值；注入 60 秒暂停后验证旧请求被拒绝、库存守恒和幂等重试结果一致。

复盘：监控锁等待、续期失败、持锁时长与应用暂停；库存、支付等不可逆资源把正确性下沉到权威库条件更新。

热门面试题

分布式锁的补充讨论

问题 12：分布式锁加了自动续期，为什么仍需要 Fencing Token（栅栏令牌）？

• 回答思路：续期是尽力保持租约，不能证明旧客户端已经停止。
• 详细答案：自动续期依赖客户端线程、网络和 Redis（远程字典服务）可用性。长暂停、网络分区或切换会使续期失败，而旧客户端恢复后可能不知道锁已经被新客户端获得；即使续期成功也不应让资源端盲信调用方。Fencing Token（栅栏令牌）为每次授权生成单调值，数据库、文件服务或下游接口只接受更大的值，因而能拒绝迟到的旧请求。这是把互斥正确性落到实际受保护资源的关键。
• 进阶追问：SET NX PX（不存在时设置并附带毫秒过期）是否足够？
• 进阶回答：它能原子获取带租约的锁，却不能解决租约过期后旧客户端继续执行、主从切换回退和资源端缺乏围栏的问题。

13. 线上排障 SOP（标准操作流程）十二：延迟队列积压

kb:knowledge-12：到期滞后、重复领取与下游保护

+#### 热门面试题（六字段）

1. 问题：延迟队列发生时，怎样先判断任务积压？

• 考点：到期滞后、下游限流和幂等补偿。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

2. 问题：延迟队列发生时，怎样先判断任务积压？

• 考点：到期滞后、下游限流和幂等补偿。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

3. 问题：延迟队列发生时，怎样先判断任务积压？

• 考点：到期滞后、下游限流和幂等补偿。
• 回答思路：先保护业务不变量，再用同一时间窗的指标交叉验证，最后做小范围可逆修复。
• 详细答案：我先固定节点、分片、调用方和事故时间窗，避免把不同节点的瞬时指标拼成错误因果。随后同时看服务端指标、客户端重试和业务结果；只有证据能解释同一条放大链路，才把动作扩大。库存与支付优先回退权威路径，轨迹与报表可降级，并把每个止血开关记录到事故时间线。
• 进阶追问：指标恢复后是否即可关闭事故？
• 进阶回答：不能。还要验证错误请求没有重放、状态没有倒退、差集已对账，并持续观察一个高峰周期；否则只能称为症状缓解。

以 ZSet（有序集合）实现延迟队列时，积压要区分“未到期数量”和“已到期待执行数量”。到期滞后由消费吞吐、领取原子性、下游限流、重试退避、工作线程容量和错误任务比例共同决定。Redis（远程字典服务）只保存调度索引，任务事实和状态机必须可由 MySQL（关系型数据库）或 MQ（消息队列）恢复。

flowchart LR
    A[任务表与 Outbox（发件箱）] --> B[ZSet（有序集合）到期索引]
    B --> C[Lua（脚本语言）原子领取]
    C --> D[工作线程]
    D --> E{下游结果}
    E -- 成功 --> F[状态确认]
    E -- 可重试 --> G[退避后重新入队]
    E -- 不可重试 --> H[DLQ（死信队列）与人工处理]

止血：先对下游做令牌桶限流和并发隔离，暂停新增低优先级任务，按业务优先级分片放流；将不可恢复错误转入 DLQ（死信队列）而非无限重试。不要清空到期集合，任务应从权威表对账后有序补偿。

取证命令与风险：

redis-cli ZCOUNT <delay_key> -inf <now_ms>
redis-cli ZCARD <delay_key>
redis-cli XRANGE <stream_key> - + COUNT 20
redis-cli INFO commandstats
redis-cli SLOWLOG GET 64

ZRANGE（有序集合范围查询）必须带 LIMIT（限制数量）或小窗口；以当前时间计算到期数量时要统一时钟来源，时钟漂移会造成误判和提前执行。

根因：承运商接口限额下调，消费者没有按渠道限流和退避，失败任务立即回队，挤占首次任务并形成重试风暴。

修复验证：按承运商隔离并采用指数退避与抖动，优先处理临近服务等级目标的任务；当下游恢复后以受控速率追赶，检查到期滞后下降、重复通知率为零、任务表和索引差集归零。

复盘：为任务定义优先级、最大尝试次数、错过策略和 DLQ（死信队列）处置人；将供应商限额变化接入动态配置与压测场景。

热门面试题

延迟队列的补充讨论

问题 13：延迟队列积压时为什么不能简单增加消费者？

• 回答思路：消费端可能不是瓶颈，盲目扩容会压垮下游并放大重复。
• 详细答案：若下游已返回 429（请求过多）或超时，增加消费者只会同时制造更多失败和重试；若领取逻辑不是原子性的，还会提高重复执行概率。先量化积压、到期滞后、实际成功吞吐、错误类型和下游容量，按渠道、任务类型和优先级做隔离。扩消费者只能在下游还有余量、任务幂等、领取与确认状态机正确时使用，并要配合全局限流。
• 进阶追问：Redis（远程字典服务）队列丢失如何恢复？
• 进阶回答：以任务表、Outbox（发件箱）或 MQ（消息队列）事件为权威来源，按状态和版本扫描补建到期索引；不能把 ZSet（有序集合）当作唯一事实。

14. 指标阈值、止血动作与验证口径

15.1 题库使用过渡：从 SOP（标准操作流程）到综合表达

前面的 kb:knowledge（知识条目）用于拆解单一故障；下面的 kb:question-bank（综合题库条目）要求你把分册机制、业务不变量和现场决策连成口述答案。答题时先报业务边界，再给止血与取证，随后解释根因、修复验证和复盘；不要只背命令或只报指标。

15. 跨章节综合题库：40 道长答案

kb:question-bank-01：下单 P99（99 分位响应时间）突刺与无边界 ZSet（有序集合）读取

1. 问题（综合题）：下单 P99（99 分位响应时间）突刺与无边界 ZSet（有序集合）读取。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“下单 P99（99 分位响应时间）突刺与无边界 ZSet（有序集合）读取”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-02：IoT（物联网）报警风暴造成 Lua（脚本语言）计算饱和

2. 问题（综合题）：IoT（物联网）报警风暴造成 Lua（脚本语言）计算饱和。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“IoT（物联网）报警风暴造成 Lua（脚本语言）计算饱和”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-03：跨可用区副本输出缓冲推高内存

3. 问题（综合题）：跨可用区副本输出缓冲推高内存。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“跨可用区副本输出缓冲推高内存”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-04：商品详情 hot key（热键）造成单槽过载

4. 问题（综合题）：商品详情 hot key（热键）造成单槽过载。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“商品详情 hot key（热键）造成单槽过载”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-05：Runner（执行器）连接泄漏耗尽最大客户端数

5. 问题（综合题）：Runner（执行器）连接泄漏耗尽最大客户端数。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Runner（执行器）连接泄漏耗尽最大客户端数”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-06：支付读模型快照期间的 COW（写时复制）峰值

6. 问题（综合题）：支付读模型快照期间的 COW（写时复制）峰值。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“支付读模型快照期间的 COW（写时复制）峰值”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-07：库存副本复制延迟导致陈旧读

7. 问题（综合题）：库存副本复制延迟导致陈旧读。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“库存副本复制延迟导致陈旧读”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-08：支付缓存 Sentinel（哨兵）切换后的旧主写入

8. 问题（综合题）：支付缓存 Sentinel（哨兵）切换后的旧主写入。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“支付缓存 Sentinel（哨兵）切换后的旧主写入”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-09：Cluster（集群）迁槽期间 MOVED（永久重定向）风暴

9. 问题（综合题）：Cluster（集群）迁槽期间 MOVED（永久重定向）风暴。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Cluster（集群）迁槽期间 MOVED（永久重定向）风暴”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-10：支付状态缓存被旧值回填

10. 问题（综合题）：支付状态缓存被旧值回填。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“支付状态缓存被旧值回填”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-11：库存锁租约过期后的双持有者

11. 问题（综合题）：库存锁租约过期后的双持有者。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“库存锁租约过期后的双持有者”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-12：承运商限流引发延迟队列重试风暴

12. 问题（综合题）：承运商限流引发延迟队列重试风暴。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“承运商限流引发延迟队列重试风暴”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-13：缓存雪崩把 MySQL（关系型数据库）压垮

13. 问题（综合题）：缓存雪崩把 MySQL（关系型数据库）压垮。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“缓存雪崩把 MySQL（关系型数据库）压垮”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-14：缓存穿透触发不存在键攻击

14. 问题（综合题）：缓存穿透触发不存在键攻击。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“缓存穿透触发不存在键攻击”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-15：大键删除造成事件循环阻塞

15. 问题（综合题）：大键删除造成事件循环阻塞。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“大键删除造成事件循环阻塞”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-16：AOF（追加日志）尾部损坏后的恢复决策

16. 问题（综合题）：AOF（追加日志）尾部损坏后的恢复决策。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“AOF（追加日志）尾部损坏后的恢复决策”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-17：多个副本全量重同步挤压主节点资源

17. 问题（综合题）：多个副本全量重同步挤压主节点资源。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“多个副本全量重同步挤压主节点资源”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-18：跨槽库存脚本失败

18. 问题（综合题）：跨槽库存脚本失败。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“跨槽库存脚本失败”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-19：Sentinel（哨兵）单点网络异常触发误判

19. 问题（综合题）：Sentinel（哨兵）单点网络异常触发误判。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Sentinel（哨兵）单点网络异常触发误判”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-20：看门狗续期失败导致任务重复

20. 问题（综合题）：看门狗续期失败导致任务重复。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“看门狗续期失败导致任务重复”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-21：排障时误执行高成本全量扫描

21. 问题（综合题）：排障时误执行高成本全量扫描。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“排障时误执行高成本全量扫描”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-22：Pub/Sub（发布订阅）慢订阅者拖垮输出缓冲

22. 问题（综合题）：Pub/Sub（发布订阅）慢订阅者拖垮输出缓冲。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Pub/Sub（发布订阅）慢订阅者拖垮输出缓冲”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-23：Stream（流）消费者组待确认列表积压

23. 问题（综合题）：Stream（流）消费者组待确认列表积压。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Stream（流）消费者组待确认列表积压”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-24：慢日志为空但端到端请求超时

24. 问题（综合题）：慢日志为空但端到端请求超时。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“慢日志为空但端到端请求超时”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-25：Cluster（集群）总线端口被网络策略阻断

25. 问题（综合题）：Cluster（集群）总线端口被网络策略阻断。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Cluster（集群）总线端口被网络策略阻断”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-26：数据库更新成功但缓存失效事件丢失

26. 问题（综合题）：数据库更新成功但缓存失效事件丢失。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“数据库更新成功但缓存失效事件丢失”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-27：支付回调超时后的结果未知

27. 问题（综合题）：支付回调超时后的结果未知。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“支付回调超时后的结果未知”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-28：WMS（仓储管理系统）库存预占与缓存淘汰冲突

28. 问题（综合题）：WMS（仓储管理系统）库存预占与缓存淘汰冲突。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“WMS（仓储管理系统）库存预占与缓存淘汰冲突”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-29：跨境物流乱序事件覆盖最新轨迹

29. 问题（综合题）：跨境物流乱序事件覆盖最新轨迹。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“跨境物流乱序事件覆盖最新轨迹”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-30：IoT（物联网）告警静默误吞高危告警

30. 问题（综合题）：IoT（物联网）告警静默误吞高危告警。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“IoT（物联网）告警静默误吞高危告警”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-31：Runner（执行器）宕机后错过周期任务

31. 问题（综合题）：Runner（执行器）宕机后错过周期任务。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Runner（执行器）宕机后错过周期任务”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-32：内存碎片导致容器逼近限制

32. 问题（综合题）：内存碎片导致容器逼近限制。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“内存碎片导致容器逼近限制”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-33：客户端输出缓冲触发断连

33. 问题（综合题）：客户端输出缓冲触发断连。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“客户端输出缓冲触发断连”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-34：Outbox（发件箱）积压影响缓存补偿

34. 问题（综合题）：Outbox（发件箱）积压影响缓存补偿。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Outbox（发件箱）积压影响缓存补偿”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-35：限流器时钟漂移导致误拒绝

35. 问题（综合题）：限流器时钟漂移导致误拒绝。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“限流器时钟漂移导致误拒绝”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-36：事故期间错误配置扩散

36. 问题（综合题）：事故期间错误配置扩散。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“事故期间错误配置扩散”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-37：容量评估遗漏复制与持久化峰值

37. 问题（综合题）：容量评估遗漏复制与持久化峰值。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“容量评估遗漏复制与持久化峰值”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-38：Redis（远程字典服务）全失后的灾难恢复

38. 问题（综合题）：Redis（远程字典服务）全失后的灾难恢复。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Redis（远程字典服务）全失后的灾难恢复”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-39：监控采集本身造成 Redis（远程字典服务）负担

39. 问题（综合题）：监控采集本身造成 Redis（远程字典服务）负担。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“监控采集本身造成 Redis（远程字典服务）负担”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

kb:question-bank-40：Redis（远程字典服务）事故复盘如何形成可执行改造

40. 问题（综合题）：Redis（远程字典服务）事故复盘如何形成可执行改造。请说明这个场景如何跨越客户端、Redis（远程字典服务）实例、复制拓扑与业务状态机完成处置。 关联分册：线上机制与网络模型。

• 考点：关联 02-事件循环与网络模型、03-持久化与复制、04-主从哨兵与集群、05-缓存一致性与缓存问题、06-分布式锁全景 和 07-延迟队列限流与项目案例。
• 口述答案：面对“Redis（远程字典服务）事故复盘如何形成可执行改造”，我先按业务不变量分级，而不是直接把症状归因给 Redis（远程字典服务）。第一分钟先止血：限制会放大故障的批量读写、回填和重试；库存放行与支付状态回退到带版本的 MySQL（关系型数据库）权威路径；外部调用结果未知时按幂等号查单，绝不凭超时再次执行。轨迹、详情和报表可按允许陈旧窗口降级。每个开关都记录时间、分片、调用方和预期副作用，保证事故时间线可复核。

随后在同一时间窗取证：关联命令耗时与调用量、事件循环延迟、客户端排队、连接及输出缓冲、内存分项、磁盘服务时间、主从偏移差、槽位状态和业务版本。P99（99 分位响应时间）变慢可能来自长命令、网络重传、COW（写时复制）、慢副本或连接池，内存也可能是数据集、复制缓冲、回复缓冲或碎片；因此我只接受能解释变化顺序的证据链，并同时检查发布、配置、网络和上游流量变更。证据不足时只做低风险采样，不在主节点执行全量扫描。

修复必须覆盖放大链路：无边界命令加分页与离线处理，热点使用分片和请求合并，副本先隔离读流再恢复追赶，缓存用可重放失效事件和版本回填，锁与任务把正确性下沉到条件更新、幂等键、栅栏令牌与状态机。参数先单分片灰度，流量按低风险读、可补偿写、关键路径顺序恢复。最后跨一个峰值窗口验证延迟、错误率、内存、复制差和积压不反弹，再用库存流水守恒、支付对账、任务差集和告警记录确认没有重复、遗漏或状态倒退；复盘把触发条件、检测缺口和演练任务落实到负责人。

• 追问树：
  • 追问一：为什么不直接重启实例？
    • 回答：重启会抹去进程级证据，还可能把短暂复制问题扩大为全量重同步；只有权威数据、回滚和影响范围已确认时才考虑。
  • 追问二：指标恢复后为何仍需对账？
    • 回答：指标只能证明服务表面恢复，不能证明异常窗口内的库存、资金、任务和轨迹没有重复、遗漏或倒退。
  • 追问三：怎样验证改造有效？
    • 回答：将触发条件转为同版本、同拓扑和峰值负载下的故障注入用例，同时验证指标、不变量与回滚路径。

16. 复习清单

• 你能在 60 秒内说明止血、取证、根因、修复、验证、复盘的顺序和理由。
• 你能把延迟、CPU（中央处理器）、内存、复制、切换、槽位、一致性、锁与延迟队列映射到正确命令和风险。
• 你能清楚说明 Redis（远程字典服务）不是库存和资金事实的唯一来源，并给出幂等、版本、条件更新和对账闭环。
• 你能针对 WMS（仓储管理系统）、跨境物流、支付、Runner（执行器）与 IoT（物联网）项目，完成一次事故口述与追问树。