高可用面试题经常从一句“系统怎么保证不挂”开始，随后追问单点故障、限流熔断、超时重试、接口幂等和异地容灾。只罗列组件通常答不完整，还要说明故障如何被发现、影响怎样被控制、服务如何恢复，以及数据能否保持正确。

这篇文章是 JavaGuide 高可用专题的复习入口，按高可用基础、冗余与容灾、限流降级熔断、超时重试幂等、性能测试与故障治理五部分整理。答案和实现细节放在对应专题文章中。

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

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

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

什么是冗余？

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

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

什么是幂等（idempotency）？

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

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

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

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

什么是降级？

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

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

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

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

常见限流算法有哪些？

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

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

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

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

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

不同角色看网站性能

用户

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

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

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

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

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

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

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

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