这份 高可用系统知识体系 面向后端学习、系统设计和面试复习，围绕“减少故障、隔离故障、快速恢复、降低重复请求和异常流量影响”整理本站高可用相关文章。

高可用系统面试考的不是“系统永远不出问题”，而是你是否理解：故障一定会发生，关键是系统能不能限制故障范围、快速恢复，并避免把小故障放大成全站事故。

这篇文章把 JavaGuide 现有高可用相关文章串成一条面试复习路线，适合准备后端开发、系统设计和中高级岗位面试。

高可用面试先建立故障视角

高可用设计可以从 5 个问题开始拆：

1. 请求太多怎么办？ 限流、排队、削峰。
2. 下游变慢怎么办？ 超时、重试、熔断、隔离。
3. 核心服务挂了怎么办？ 降级、冗余、故障转移。
4. 重复请求怎么办？ 幂等、防重、状态机。
5. 上线前怎么证明系统扛得住？ 压测、监控、演练、容量评估。

什么是高可用？可用性的判断标准是啥？

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

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

可用性等级	可用性百分比	年度停机时间	典型场景
1 个 9	90%	36.5 天	个人博客
2 个 9	99%	3.65 天	普通企业系统
3 个 9	99.9%	8.76 小时	在线服务
4 个 9	99.99%	52.6 分钟	金融交易系统
5 个 9	99.999%	5.26 分钟	电信级系统

这部分内容摘自 JavaGuide 下面几篇文章的重点：

高可用设计：

• 高可用系统设计指南
• 冗余设计详解
• 性能测试入门

由于网络抖动、硬件故障、进程异常、依赖服务不可用等问题的不确定性，我们的系统或者服务永远不可能保证时刻都是可用的状态。

为了最大限度的减小系统或者服务出现故障之后带来的影响，我们需要用到的 超时（Timeout） 和 重试（Retry） 机制。

超时和重试的核心思想确实不难理解，但在生产环境中正确使用它们却有不少门道。你平时接触到的绝大部分涉及远程调用的系统或者服务都会应用超时和重试机制。尤其是对于微服务系统来说，正确设置超时和重试非常重要。单体服务通常只涉及数据库、缓存、第三方 API、中间件等的网络调用，而微服务系统内部各个服务之间还存在着网络调用。