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

在微服务架构里，一个请求往往要经过好几个服务的调用链。如果链路上某个服务出了问题——比如响应变慢、超时甚至直接挂掉——很容易把上游的资源也拖垮，最后演变成整条链路雪崩。服务降级和熔断就是应对这类问题的两道防线：降级负责在系统压力大的时候主动"丢车保帅"，熔断负责在下游持续异常的时候及时"断路"止损。

这篇文章会把降级和熔断的核心原理讲清楚，包括 Fallback 兜底、降级开关、熔断器状态机、隔离策略，以及 Sentinel、Hystrix、Resilience4j 的选型对比。

什么是降级？

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

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

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

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

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

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

不管是平时刷的购物网站、用的在线支付，还是公司内部的核心业务系统，用户对"服务不可用"的容忍度越来越低。一次持续几分钟的故障，可能就会带来大量用户流失甚至直接的经济损失。

所以，如何让系统在各种异常情况下依然能提供稳定的服务，就成了后端开发和架构设计中绕不开的话题。这篇文章会把高可用系统设计的核心思路和常见方案梳理一遍，包括 SLA 指标、单点故障治理、限流熔断、服务降级、缓存高可用、异步削峰、冗余容灾、灰度发布和故障恢复等。

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

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

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

高可用设计：

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

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

什么是幂等（idempotency）？

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

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

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

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

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

常见限流算法有哪些？

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

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

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

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

平时大家说“压测”，很多时候其实是在泛指性能测试相关工作：用工具模拟用户请求，观察系统在不同压力下的吞吐量、响应时间、错误率和资源使用情况。实际做压测时，先说清楚这次要验证什么。

不同角色看网站性能

用户

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

不管是硬件故障、机房断电，还是某个服务突然挂掉，单点永远是系统里最脆弱的环节。想让系统在各种意外情况下还能扛得住，最基本也最有效的办法就是 冗余——关键资源多备几份，坏了一份还有其他的顶上。

这篇文章会把冗余设计的核心概念和常见方案梳理一遍：从 RTO/RPO 这两个容灾指标，到高可用集群、同城灾备、异地多活，再到 Redis Sentinel、Keepalived 这些具体的故障转移方案。

什么是冗余？

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

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

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

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