高可用面试题经常从一句“系统怎么保证不挂”开始,随后追问单点故障、限流熔断、超时重试、接口幂等和异地容灾。只罗列组件通常答不完整,还要说明故障如何被发现、影响怎样被控制、服务如何恢复,以及数据能否保持正确。
这篇文章是 JavaGuide 高可用专题的复习入口,按高可用基础、冗余与容灾、限流降级熔断、超时重试幂等、性能测试与故障治理五部分整理。答案和实现细节放在对应专题文章中。
高可用面试题经常从一句“系统怎么保证不挂”开始,随后追问单点故障、限流熔断、超时重试、接口幂等和异地容灾。只罗列组件通常答不完整,还要说明故障如何被发现、影响怎样被控制、服务如何恢复,以及数据能否保持正确。
这篇文章是 JavaGuide 高可用专题的复习入口,按高可用基础、冗余与容灾、限流降级熔断、超时重试幂等、性能测试与故障治理五部分整理。答案和实现细节放在对应专题文章中。
由于网络抖动、硬件故障、进程异常、依赖服务不可用等问题的不确定性,我们的系统或者服务永远不可能保证时刻都是可用的状态。
为了最大限度地减小系统或者服务出现故障之后带来的影响,我们需要用到 超时(Timeout) 和 重试(Retry) 机制。
超时和重试的核心思想确实不难理解,但在生产环境中正确使用它们却有不少门道。你平时接触到的绝大部分涉及远程调用的系统或者服务都会应用超时和重试机制。尤其是对于微服务系统来说,正确设置超时和重试非常重要。单体服务通常只涉及数据库、缓存、第三方 API、中间件等的网络调用,而微服务系统内部各个服务之间还存在着网络调用。
不管是平时刷的购物网站、用的在线支付,还是公司内部的核心业务系统,用户对"服务不可用"的容忍度越来越低。一次持续几分钟的故障,可能就会带来大量用户流失甚至直接的经济损失。
所以,如何让系统在各种异常情况下依然能提供稳定的服务,就成了后端开发和架构设计中绕不开的话题。这篇文章会把高可用系统设计的核心思路和常见方案梳理一遍,包括 SLA 指标、单点故障治理、限流熔断、服务降级、缓存高可用、异步削峰、冗余容灾、灰度发布和故障恢复等。
高可用(High Availability,简称 HA) 是指系统在绝大部分时间内能够持续提供正常服务的能力。高可用代表系统即使在发生硬件故障或者系统升级的时候,服务仍然是可用的。