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

什么是降级？

服务降级，说白了就是：系统快扛不住的时候，先牺牲不重要的功能，把资源留给核心链路。

比如电商大促时，推荐模块、广告位、活动氛围图这些非核心功能可以先关掉，但下单、支付、库存扣减这些链路必须尽量保住。用户少看一个推荐还能接受，但下不了单就是真事故。

所以，降级是一套提前设计好的兜底方案，不是系统挂了以后随便返回个默认值。什么时候触发、关哪些功能、返回什么内容、怎么恢复，都应该提前想清楚。

降级一般在什么情况下触发？

很多人会把降级理解成“机器负载太高才降级”，其实不止这一种情况。

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

这篇文章把 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 下面几篇文章的重点：

高可用设计：

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

接口幂等性是面试中常见的问题，也是日常开发过程中经常需要解决的问题。

什么是幂等（idempotency）？

幂等（idempotency）本身是一个数学概念，常见于抽象代数中，表示一个操作执行一次和执行多次产生的效果相同。放到函数上，可以理解为 $f(f(x)) = f(x)$。例如，$f(x)=|x|$ 就是幂等的，因为对一个数取一次绝对值和取多次绝对值，结果都一样。

在接口语义里，幂等主要指多次相同请求对服务端资源产生的预期效果，和执行一次请求一致。至于响应内容是否完全相同，要看业务设计；资金类接口通常会额外要求返回稳定的业务结果。

针对软件系统来说，限流就是对请求的速率进行限制，避免瞬时的大量请求击垮软件系统。毕竟，软件系统的处理能力是有限的。如果请求量超过了系统的处理能力，软件系统可能直接就挂掉了。

限流可能会导致用户的请求无法被正确处理或者无法立即被处理，不过，这往往也是权衡了软件系统的稳定性之后得到的最优解。

现实生活中，处处都有限流的实际应用，就比如排队买票是为了避免大量用户涌入购票而导致售票员无法处理。

常见限流算法有哪些？

简单介绍 4 种非常好理解并且容易实现的限流算法！

图片来源于 InfoQ 的一篇文章《分布式服务限流实战，已经为你排好坑了》。

性能测试通常由专业的测试团队负责，那还需要我们开发学这个干嘛呢？了解性能测试的指标、分类以及工具等知识有助于我们更好地去写出性能更好的程序，另外作为开发这个角色，如果你会性能测试的话，相信也会为你的履历加分不少。

本文结合了笔者的实践经验以及向测试团队请教所得，除此之外，我还借鉴了一些优秀书籍，希望对你有帮助。

不同角色看网站性能

用户

当用户打开一个网站的时候，最关注的是什么？当然是 网站响应速度的快慢。比如我们点击了淘宝的主页，淘宝需要多久将首页的内容呈现在我的面前，我点击了提交订单按钮需要多久返回结果等等。

什么是冗余？

冗余（Redundancy） 是保证系统和数据高可用的最常用手段，其核心思想是 通过部署多份相同的资源，当某一份资源出现故障时，其他资源可以接管其工作，从而保证系统的持续可用。

冗余设计可以从以下几个维度来理解：

冗余类型	说明	典型实现
硬件冗余	关键硬件设备部署多份	双电源、双网卡、RAID 磁盘阵列
软件冗余	应用服务部署多个实例	集群部署、容器化多副本
数据冗余	数据存储多份副本	数据库主从复制、分布式存储多副本
网络冗余	网络链路和设备冗余	多运营商接入、双活负载均衡
地域冗余	在不同地理位置部署系统	同城灾备、异地灾备、同城多活、异地多活

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

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

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