| title | 高可用系统设计面试题总结：限流、熔断、重试、幂等、容灾与压测 | |||||||
|---|---|---|---|---|---|---|---|---|
| description | 高可用系统设计面试复习路线，串联 SLA、单点故障、限流降级熔断、超时重试、接口幂等、冗余容灾、性能压测和故障演练等 Java 后端高频考点。 | |||||||
| category | 高可用 | |||||||
| tag |
|
|||||||
| head |
|
高可用系统面试考的不是“系统永远不出问题”，而是你是否理解：故障一定会发生，关键是系统能不能限制故障范围、快速恢复，并避免把小故障放大成全站事故。
这篇文章把 JavaGuide 现有高可用相关文章串成一条面试复习路线，适合准备后端开发、系统设计和中高级岗位面试。
高可用设计可以从 5 个问题开始拆：
- 请求太多怎么办？ 限流、排队、削峰。
- 下游变慢怎么办？ 超时、重试、熔断、隔离。
- 核心服务挂了怎么办？ 降级、冗余、故障转移。
- 重复请求怎么办？ 幂等、防重、状态机。
- 上线前怎么证明系统扛得住？ 压测、监控、演练、容量评估。
只要围绕这 5 个问题展开，高可用系统设计题就不会答散。
先建立整体框架，再看具体手段。
重点文章：
高频面试问题：
- 什么是高可用？可用性 99.9%、99.99% 分别意味着什么？（99.9% 每月约 43 分钟不可用，99.99% 每月约 4 分钟不可用）
- 高可用和高性能有什么区别？
- 单点故障如何识别和消除？
- 冗余设计为什么不是简单多部署几台机器？
- 压测应该测什么？如何避免压测结果和线上表现差距过大？
这一阶段重点理解“系统会坏”这个前提。高可用设计的核心不是追求零故障，而是让故障可预期、可隔离、可恢复。
限流、降级、熔断经常一起被问，但它们解决的问题不一样。
重点文章：
高频面试问题：
- 固定窗口、滑动窗口、漏桶、令牌桶有什么区别？
- 为什么固定窗口限流可能出现临界突刺？比如每分钟限 100 次，在窗口末尾和下个窗口开头的 2 秒内可能放行 200 次。
- 令牌桶为什么更适合处理突发流量？
- 降级和熔断有什么区别？
- 熔断器通常有哪些状态？半开状态解决什么问题？
- 什么场景适合返回兜底数据？什么场景必须失败提示？
回答这类问题时，要说明触发条件和恢复机制。比如熔断不是“一失败就立刻切断”，而是需要错误率、慢调用比例、最小请求数、恢复探测等规则配合。不同实现（如 Sentinel、Resilience4j）的默认参数和窗口机制有差异，面试时最好能说出你用过的一种具体配置。
超时、重试、幂等是线上事故里非常常见的组合题。
重点文章：
高频面试问题：
- 为什么所有远程调用都应该设置超时？
- 重试为什么可能放大故障？
- 哪些错误可以重试？哪些错误不应该重试？
- 指数退避和随机抖动解决什么问题？
- 什么是幂等？查询天然幂等吗？
- 支付、下单、发券这类接口如何设计幂等？常见方案包括唯一请求 ID + 去重表、数据库唯一约束、状态机控制、乐观锁等。
这部分最重要的结论是：重试必须和超时、限流、幂等一起设计。没有幂等的重试可能造成重复下单、重复扣款；没有退避的重试可能把下游彻底打挂。读操作重试相对安全，写操作重试必须配合幂等，重试次数通常建议控制在 3 次以内。
很多同学准备高可用面试时只背方案，忽略验证视角。真实系统里，如果没有压测和监控，高可用设计就只是纸面设计。
重点文章：
高频面试问题：
- 压测指标应该关注哪些？QPS、RT、错误率和资源使用率各自的含义是什么？
- 如何做容量评估？
- 为什么要区分单接口压测和全链路压测？
- 线上监控应该覆盖哪些指标？
- 故障演练和混沌工程解决什么问题？
面试里可以这样收束答案：上线前通过压测确认容量边界，上线后通过监控发现异常，通过限流降级保护系统，通过预案和演练缩短恢复时间。
遇到“如何设计一个高可用系统”这类题，可以按下面的顺序回答：
- 明确业务场景和 SLA 目标：不同业务、不同可用性等级决定了完全不同的复杂度和成本。
- 识别核心链路：哪些功能不能挂，哪些功能可以降级。
- 消除单点故障：服务、数据库、缓存、消息队列都要考虑冗余。
- 控制入口流量：限流、排队、削峰，避免系统被瞬时流量打穿。
- 保护下游依赖：超时、重试、熔断、隔离，防止故障扩散。
- 保证请求安全：幂等、防重、状态机，避免重复执行。
- 建立观测和恢复能力：监控、告警、压测、演练、预案。
这样答的好处是不会堆概念，而是沿着故障传播路径一步步收敛风险。
临近面试可以按这个顺序复习：
高可用面试的核心不是把每个概念背得很长，而是能把它们串成一套故障治理体系：出问题前能预防，出问题时能止损，出问题后能恢复和复盘。