系统出现故障怎么办？有什么容错机制
1️⃣ 考察意图
面试官想看的不是“背出熔断、限流、降级三个词”，而是你能否从故障类型出发，设计一套可落地的容错完整流程。考察类型是工程取舍+系统设计。刁钻点在于：多数候选人只讲“怎么做”，不讲“为什么这么做”和“不做什么”。答好了能展示：你具备从故障预防（防御性编码）、检测（健康检查+指标监控）、恢复（自动转移+数据修复）到复盘（根因分析+策略迭代）的整条链路工程思维，并且能根据业务SLA做有损降级决策。
2️⃣ 标准答
第一步：故障分类与SLA定义
- 故障分三类：服务不可用（如向量库挂掉）、响应慢（如LLM API超时>5s）、结果错误（如检索召回0条或幻觉）。
- 每类故障定义SLA：例如“P99延迟<2s，可用性>99.9%”，并明确降级触发阈值（如错误率>5%持续30秒即熔断）。
第二步：容错机制设计（核心）
- 熔断（Circuit Breaker）：用Hystrix或Resilience4j实现。关键取舍：半开状态（Half-Open）的探测请求数设为1，避免雪崩。坑：熔断后立即恢复会引发“惊群效应”，解法是指数退避探测（初始间隔1s，最大30s）。
- 降级（Degradation）：按业务优先级分三级：
- 一级降级：返回缓存结果（如Redis缓存最近1小时热门问答）。
- 二级降级：简化模型（如LLM超时时，用BM25+规则模板生成摘要，而非完整生成）。
- 三级降级：返回友好提示（如“服务繁忙，请稍后重试”）。
- 限流（Rate Limiting）：用令牌桶（Token Bucket）应对突发流量，漏桶（Leaky Bucket）平滑请求。取舍：令牌桶允许短时突发，适合RAG场景（用户可能连续提问）；漏桶更严格，适合写操作。
- 重试与退避（Retry + Backoff）：仅对幂等操作（如只读查询）重试，写操作需加幂等键。退避策略用指数退避+抖动（Exponential Backoff with Jitter），避免所有客户端同时重试。
第三步：故障检测与告警
- 健康检查：用gRPC健康检查协议或HTTP /health端点，每5秒探测一次。坑：健康检查不能只测进程存活，要测业务逻辑（如向量库能否正常查询）。
- 指标监控：用Prometheus采集错误率、P99延迟、熔断器状态。告警分三级：P0（服务不可用，短信+电话）、P1（延迟飙升，邮件+钉钉）、P2（错误率波动，日志告警）。
- 异常检测：用滑动窗口（如过去5分钟错误率>3σ）触发自动降级，避免人工响应延迟。
第四步：故障恢复
- 自动故障转移：多副本部署（至少2个可用区），用K8s的Readiness Probe自动摘除异常Pod。坑：转移后需预热缓存（如预加载热点数据），否则新实例冷启动导致延迟飙升。
- 数据修复：向量库故障时，从备份索引（每小时全量+增量快照）恢复。取舍：全量恢复慢（10GB索引需5分钟），增量恢复快但需保证一致性（用WAL日志回放）。
- 回滚：代码发布故障时，用蓝绿部署或金丝雀发布，回滚时间控制在1分钟内。
第五步：事后复盘
- 根因分析：用故障树分析（FTA） 或5 Whys，例如“LLM API超时”的根因可能是“上游模型升级导致推理延迟增加”。
- 策略迭代：将故障注入（Chaos Engineering）加入CI/CD，例如用Chaos Mesh随机杀死Pod，验证容错机制是否生效。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从故障分类、容错设计、检测恢复三个层面回答。首先，将故障分为服务不可用、响应慢、结果错误三类，并定义SLA。其次，核心容错机制包括熔断（Hystrix半开状态）、降级（三级策略）、限流（令牌桶）和重试退避（指数退避+抖动）。最后，通过健康检查+指标监控检测故障，用自动转移+数据备份恢复，并引入混沌工程验证。总结一句：容错不是堆砌组件，而是根据业务SLA做有损降级决策，并形成完整流程迭代。”
4️⃣ 高频追问 & 应对
追问 1：你提到降级分三级，具体怎么决定用哪一级？有没有可能降级后用户体验反而更差？
决策依据是业务优先级+成本。例如RAG场景：一级降级（缓存）成本最低，但只对高频问题有效；二级降级（BM25）召回率下降但延迟可控；三级降级（提示）保证可用性但用户流失。取舍点：降级不能无限降，需设定“最小可用质量”（如召回率>60%）。坑：降级后可能引发“降级风暴”（所有请求都走降级路径），解法是降级比例控制（如只降级50%流量，其余返回503）。
追问 2：熔断器半开状态时，探测请求怎么选？如果探测请求恰好命中慢查询怎么办？
探测请求应随机选择，但排除已知慢路径（如复杂聚合查询）。解法：在探测请求中注入超时控制（如设置1s超时），若超时则视为失败，不重置熔断器。坑：探测请求可能被限流误杀，需绕过限流（如加特殊Header）。更优方案：用自适应熔断（Google SRE的“请求成功率”算法），根据实时错误率动态调整半开窗口。
追问 3：你提到用Chaos Engineering验证，具体怎么设计实验？有没有失败案例？
实验设计遵循爆炸半径最小化原则：先在预发环境注入故障（如杀死一个Pod），观察熔断器是否触发、降级是否生效。失败案例：某次注入网络延迟后，发现降级策略未生效——原因是降级代码中依赖了同一个故障服务（如降级时仍调用向量库检查状态）。解法：降级路径必须独立，不依赖故障服务，例如降级用本地BM25索引，而非远程向量库。
5️⃣ 避坑 · 常见错误答法
- ❌ 只讲“用Hystrix做熔断”，不讲熔断参数（如滑动窗口大小、错误率阈值）和半开状态设计 → ✅ 必须给出具体参数：例如“滑动窗口10秒，错误率阈值50%，半开探测请求数1，失败后等待30秒再试”。
- ❌ 把“降级”等同于“返回错误提示”，忽略业务分级 → ✅ 降级应分三级：缓存结果、简化模型、友好提示，并说明每级的触发条件和恢复策略。
- ❌ 认为“重试越多越好”，忽略幂等性和退避策略 → ✅ 重试仅对幂等操作，且必须用指数退避+抖动，避免雪崩。
6️⃣ 简历呼应
- 如果你有RAG项目：从“向量库故障时降级为BM25检索”切入，展示你如何设计降级策略（如缓存热点问题、本地索引备份），并提到用Chaos Mesh验证了可用性从99.9%降到99.5%但未完全宕机。
- 如果你只做过传统NLP：用“模型推理服务容错”类比，例如“当BERT模型OOM时，降级为规则匹配”，并强调你如何用健康检查（gRPC）和限流（令牌桶）保障服务稳定。
- 如果你是校招无项目：聚焦论文复现，例如“在论文《Resilient Distributed Datasets》中，Spark通过血统（Lineage）实现容错，我复现了类似机制用于RAG缓存恢复”，并提到你了解Hystrix和Resilience4j的源码。
- 《Site Reliability Engineering》by Google（第20章：熔断与降级）
- Hystrix Wiki: Circuit Breaker Pattern（Netflix开源）
- Chaos Mesh 官方文档：故障注入实验设计
- 《Building Resilient Streaming Systems》by Jay Kreps（Kafka容错设计）
- 论文《Exponential Backoff with Jitter》by Google（重试策略优化）