title: 高可用系统设计面试题总结：限流、熔断、重试、幂等、容灾与压测

description: 高可用系统设计面试复习路线，串联 SLA、单点故障、限流降级熔断、超时重试、接口幂等、冗余容灾、性能压测和故障演练等 Java 后端高频考点。

content: 高可用面试题,高可用系统设计,高可用复习路线,系统设计面试题,SLA,限流面试题,熔断面试题,超时重试面试题,接口幂等面试题,冗余容灾,性能压测,故障演练

- 什么是高可用？可用性 99.9%、99.99% 分别意味着什么？（99.9% 每月约 43 分钟不可用，99.99% 每月约 4 分钟不可用）

- 为什么固定窗口限流可能出现临界突刺？比如每分钟限 100 次，在窗口末尾和下个窗口开头的 2 秒内可能放行 200 次。

回答这类问题时，要说明触发条件和恢复机制。比如熔断不是“一失败就立刻切断”，而是需要错误率、慢调用比例、最小请求数、恢复探测等规则配合。不同实现（如 Sentinel、Resilience4j）的默认参数和窗口机制有差异，面试时最好能说出你用过的一种具体配置。

- 支付、下单、发券这类接口如何设计幂等？常见方案包括唯一请求 ID + 去重表、数据库唯一约束、状态机控制、乐观锁等。

这部分最重要的结论是：**重试必须和超时、限流、幂等一起设计**。没有幂等的重试可能造成重复下单、重复扣款；没有退避的重试可能把下游彻底打挂。读操作重试相对安全，写操作重试必须配合幂等，重试次数通常建议控制在 3 次以内。

很多同学准备高可用面试时只背方案，忽略验证视角。真实系统里，如果没有压测和监控，高可用设计就只是纸面设计。

- 压测指标应该关注哪些？QPS、RT、错误率和资源使用率各自的含义是什么？

1. **明确业务场景和 SLA 目标**：不同业务、不同可用性等级决定了完全不同的复杂度和成本。

2. **识别核心链路**：哪些功能不能挂，哪些功能可以降级。

3. **消除单点故障**：服务、数据库、缓存、消息队列都要考虑冗余。

4. **控制入口流量**：限流、排队、削峰，避免系统被瞬时流量打穿。

5. **保护下游依赖**：超时、重试、熔断、隔离，防止故障扩散。

6. **保证请求安全**：幂等、防重、状态机，避免重复执行。

7. **建立观测和恢复能力**：监控、告警、压测、演练、预案。

title: 高可用系统设计详解：SLA、限流熔断、降级容灾、缓存与灰度发布

description: 高可用系统设计指南，讲解 SLA 和多少个 9、单点故障治理、限流熔断、服务降级、缓存高可用、异步削峰、冗余容灾、灰度发布和故障恢复等核心方案。

tag:

- 高可用

- 系统设计

content: 高可用,高可用系统设计,高可用架构,SLA,多少个 9,单点故障,限流熔断,服务降级,缓存高可用,冗余容灾,灰度发布,故障恢复,系统稳定性

**高可用（High Availability，简称 HA）** 是指系统在绝大部分时间内能够持续提供正常服务的能力。高可用代表系统即使在发生硬件故障或者系统升级的时候，服务仍然是可用的。

一般情况下，我们使用 **多少个 9** 来评判一个系统的可用性，比如 99.9999% 就是代表该系统在所有的运行时间中只有 0.0001% 的时间是不可用的，这样的系统就是非常非常高可用的了！可用性较差的系统可能连 90%（1 个 9）都达不到。

另外，推荐几个对提高代码质量有实际效果的工具：

- [SonarQube](https://www.sonarqube.org/)：静态代码分析平台，可检测代码坏味道、安全漏洞和 Bug。

**单点故障（Single Point of Failure，SPOF）** 是高可用的大敌。以 Redis 缓存为例：使用集群模式避免单点故障，是保障其高可用的关键手段。

当我们使用一个 Redis 实例作为缓存的时候，该 Redis 实例宕机后，整个缓存服务就可能不可用。使用集群之后，即使一台 Redis 实例宕机，也可以通过故障转移让其他实例接管。切换时间取决于部署模式和参数配置，Redis Sentinel/Cluster 通常需要数秒到数十秒，不应简单理解为“不到一秒”。

- **Redis Cluster 模式**：Redis 3.0+ 官方支持的数据分片方案，每个分片有主从副本，兼顾高可用和水平扩展。

需要特别注意的是，重试的接口必须具备幂等性。对于创建订单、资金扣减这类非幂等写操作，应通过唯一请求 ID、业务唯一键、状态机等方式防止重复执行，而不是简单地把失败请求再发一遍。读操作可以相对积极地重试，写操作重试前最好先查询上一次请求是否已经生效。

超时和重试机制设置之外，**熔断机制** 也是很重要的。熔断机制说的是系统自动收集所依赖服务的资源使用情况和性能指标，当所依赖的服务恶化或者调用失败次数达到某个阈值时，熔断器进入 Open 状态，后续请求直接快速失败，不再调用下游服务，避免故障继续扩散。熔断通常会配合降级策略使用，比如返回兜底数据或调用备用服务。

历史上广泛使用的流量控制和熔断降级框架有 Netflix Hystrix（已进入维护模式）和 Alibaba Sentinel。新项目通常更推荐使用 Sentinel 或 Resilience4j。

异步调用是指调用方发起请求后不阻塞等待处理结果，而是立即返回，具体处理可以后续再做，秒杀场景用这个还是蛮多的。

在高并发场景下，如果所有请求都直接打到数据库，数据库很可能因压力过大而崩溃。使用缓存缓存热点数据，因为缓存存储在内存中，所以速度相当地快！

缓存本身也要考虑高可用下的典型故障模式：

- **缓存穿透**：查询不存在的数据，请求全部穿透到数据库。常见应对方式有参数校验、空值缓存、布隆过滤器。

- **缓存击穿**：热点 Key 过期瞬间，大量请求同时打到数据库。常见应对方式有互斥锁、逻辑过期、热点 Key 永不过期 + 异步刷新。

- **缓存雪崩**：大量 Key 同时过期或缓存集群不可用。常见应对方式有过期时间加随机偏移、多级缓存、缓存集群高可用。