高可用面试通常从一句”系统怎么保证不挂”开始，顺着单点、限流熔断、超时重试、幂等、容灾一路追下去。只背组件名单撑不过两轮追问——面试官想听的是：故障怎么被发现、影响怎么被关住、服务怎么恢复、数据会不会错。

考察地图

  • 高可用基础：可用性度量与单点故障。考察能否把”不挂”翻译成数字和失效模式清单。
  • 冗余与容灾：RTO/RPO 与脑裂。考察对”备用资源接管”背后检测、切换、数据风险的理解。
  • 限流、降级与熔断：三种流量治理手段的分工。考察能否在一条调用链上摆对位置。
  • 超时、重试与幂等：远程调用失败后的处理闭环。追问密度最高的区域。
  • 综合设计：”设计一个高可用系统”开放题。考察体系化表达能力。
  • 建议自行查阅：限流四种算法细节、RateLimiter 两种模式、Hystrix/Sentinel/Resilience4j 选型、Sentinel 的 quorum 参数、平均 RT 与 P99 的解读误区——偏记忆或归属压测专题，多作铺垫而非考点。

高可用基础

什么是高可用？几个 9 分别意味着什么？

结论：高可用指系统在绝大部分时间持续提供正常服务的能力，用”几个 9”度量。99.9% 约等于全年停机 8.8 小时，99.99% 约 52.6 分钟，99.999% 只剩 5.3 分钟。

原理：每多一个 9，停机预算缩一个数量级，手段也要升档：3 个 9 靠冗余加人工运维尚可，4 个 9 要求检测切换全自动化，5 个 9 基本只有多活加常态化演练。报数字前先讲口径：按年还是按月、计划内维护是否计入、按时间还是按失败请求占比——后者对”部分用户受损”更敏感。

延伸：SLA 是对外合同承诺，超了要赔付，所以会定得比内部目标（SLO）松一档。设计上不必全站一个标准：核心交易追 4 个 9，后台管理 2 个 9 就够，按业务影响分级投入。

追问：从 99.9% 提到 99.99%，系统具体要补哪些能力？提示：从故障检测、自动切换、变更管控三个方向算停机时间的账。

什么是单点故障？部署了多个实例为什么还可能有单点？

结论：单点故障（SPOF）指某个组件一旦失效就导致全系统不可用。多部署实例只消除了应用层的单点，共享依赖和公共路径上的单点往往还在。

原理：逐层排查就能发现残留单点：应用实例后面可能共用数据库主库、Redis、MQ；入口可能只有一条线路、一个负载均衡器；更隐蔽的是逻辑单点——所有实例共用同一配置中心和发布流水线，一次错误发布就能让全部实例同时挂掉。判断方法：对每个依赖问一句——它挂了，系统还能服务吗？

延伸：消单点不等于无脑加副本，副本之间必须故障独立：同城双机房的实例若共用同一供电或网络出口，一次断电照样双杀。副本要落在不同的供电、网络、地域故障域里才有意义。

追问：配置中心挂了会影响正在运行的服务吗？提示：取决于客户端是否有本地缓存快照——这本身也是一个单点设计问题。

冗余与容灾

RTO 和 RPO 分别约束什么？RPO=0 的代价是什么？

结论：RTO（恢复时间目标）约束”故障后多久恢复服务”，RPO（恢复点目标）约束”最多丢多少数据”。RPO=0 意味着一笔数据都不许丢。

原理：压 RTO 靠自动化：健康检查、自动切换、预热的备用资源，把恢复从小时级压到秒级。压 RPO 靠数据复制：异步复制在切换瞬间可能丢掉未同步的写入；要 RPO=0 就得同步复制——写入在多个故障域都确认后才返回，写延迟被最远的副本拖住；网络分区时还要在”继续服务可能丢数据”和”拒绝写保证一致”之间二选一，这正是 CAP 的具体化。

延伸：RTO/RPO 是业务目标而非配置结果。备份能不能恢复、流量能不能切走、切完数据全不全，只有定期演练能证明。不同链路应分级：订单库 RPO=0，行为日志丢几分钟无所谓。

追问：RTO=0 真实存在吗？提示：工程上只有”用户无感知”——检测、切换、客户端重连都要花时间，所谓 0 是把这些耗时压到可感知阈值之下。

什么是脑裂？多数派、租约和 fencing 怎么防住双主？

结论：脑裂指网络分区让主备互相失联，双方都认为对方死了，备升主后出现两个主同时写，数据冲突。防御核心是”任何时刻最多一方能写”。

原理：三道防线叠加。多数派（Quorum）：节点须获集群多数认可才能升主，少数派一侧自动失去资格——3 节点分区成 1+2 时，1 的那侧永远凑不够 2 票。租约（Lease）：主节点持有带过期时间的租约，分区后旧主租约到期失效新主才能接管，重叠窗口内旧主应主动停写。fencing（隔离）：切换时强制阻断旧主访问共享资源，如 fencing token（存储只接受令牌更大的写）、撤销权限甚至断电。只靠”检测对方死了就切换”，是脑裂的经典成因。

延伸：脑裂不止发生在数据库。Redis Sentinel 因复制异步，切换可能丢数据，与此同源；客户端也要配合——旧主还没断气时，连旧主的客户端必须写不进去才算防住。

追问：投票节点为什么通常部署奇数个？提示：3 节点容忍 1 个失效，4 节点也只能容忍 1 个——偶数节点白付成本。

限流、降级与熔断

限流、降级、熔断分别解决什么问题？能放在一条调用链上讲吗？

结论：限流控制”进多少”——入口流量超容量就拒绝多余部分；降级控制”干多少”——压力大了主动砍非核心功能；熔断控制”还调不调”——下游持续异常就停止调用、快速失败。三者是不同位置的阀门。

原理：放进一条链路看：洪峰到达入口，限流先挡住超出容量的部分；调用下游变慢先靠超时切断等待，持续失败达阈值后熔断器打开（Closed→Open），后续请求走降级逻辑返回兜底；冷却后进入半开放少量请求试探，成功则闭合，失败继续打开。线程池/信号量舱壁贯穿始终，保证单个下游故障不占满全部资源。

延伸：三者触发方不同：限流由自己的容量触发，降级由人或预案触发，熔断由下游健康触发。降级要有明确开关和预案，降级结果要打标可观测——否则”降级成常态”都无人察觉。

追问：被限流的请求应该拒绝、排队还是降级返回？提示：看接口实时性——实时接口快速失败，可延迟任务排队削峰，非核心读返回缓存兜底。

超时、重试与幂等

远程调用的超时时间应该怎么设置？

结论：参考下游分位延迟（TP99 起步）而不是平均值，结合上游剩余预算和业务容忍度收敛，最后压测校准。

原理：平均值被大量快请求拉低，而超时恰恰为长尾准备，用平均值定超时必然误杀正常慢请求。可操作的方法：先定可接受的误超时率（如 0.1%），取下游 P99.9 延迟作起点。链路上遵守”下游超时小于上游剩余预算”：入口请求带总 Deadline，每层扣掉本地耗时后把剩余预算传给下游。超时也不是越短越好——太短则下游轻微抖动就大批误超时，叠加重试反而加重故障。

延伸：超时不止连接和读取，还有连接池借连接、TLS 握手、写请求体、整体 Deadline 等维度，不同客户端覆盖口径不同，配置要对照文档。生产上超时值应放配置中心动态调整，灰度时盯 P99、超时率和线程池队列。

追问：为什么不能所有接口统一设 3 秒？提示：接口延迟分布差异巨大，统一值对快接口太长、对慢接口太短，还破坏了预算传递。

重试为什么可能放大故障？怎么安全地重试？

结论：重试的放大是乘法——链路每层各重试 N 次，下游流量指数级膨胀；下游故障期被各层重试流量集中冲击就是重试风暴。安全重试靠四件套：限次数、挑错误、退避加抖动、重试预算。

原理：A→B→C 三层各重试 3 次，C 最坏收到 9 倍流量。各客户端超时时刻几乎同步，若按固定节奏重试，会在相同时刻撞向刚恢复的下游——这是抖动（Jitter）要解决的：在指数退避上限内随机取值，打散重试时刻。重试预算（Retry Budget）从总量设闸：重试占比超阈值（如 10%）就不再重试，快速失败。

延伸：只重试可重试错误：连接超时、读超时、临时 5xx、带 Retry-After 的 429；参数错误、鉴权失败、业务规则失败重试无意义。监控上盯首次成功率：它持续下降而最终成功率不变，说明系统在用重试硬扛下游故障。

追问：读超时 1.5s、重试 3 次、退避 1/2/4s，最坏尾延迟多少？提示：约 13s，大概率超过入口预算——重试次数要和超时预算一起算。

什么是幂等？常见实现方案有哪些？

结论：幂等指同一操作执行一次和执行多次产生的业务效果相同。它是重试、消息重投、支付回调重复通知等一切”请求可能到达多次”场景的安全前提。

原理：先理解为什么会重复：服务端已执行成功但响应丢失，客户端超时重试——超时永远不能证明服务端没执行。实现按场景选：请求携带唯一 ID 服务端记录去重；创建类操作用数据库唯一索引硬约束；更新类操作用版本号乐观锁；订单、支付这类有生命周期的业务用状态机，已终态的重复请求直接拒绝。注意区分去重与幂等：去重是不让重复请求执行，幂等是允许到达但保证结果一致。

延伸：HTTP 语义上 GET/PUT/DELETE 幂等，POST 不幂等，但协议语义不等于实现安全——POST 创建订单必须靠业务侧幂等键。支付场景的标准动作：入口生成唯一业务单号，落库唯一约束兜底，回调按状态机推进。

追问：先查再插（select 判断存在再 insert）能保证幂等吗？提示：不能——并发下两个请求都查到”不存在”就会重复插入，必须靠唯一约束在数据库层兜底。

综合设计

如何设计一个高可用系统？

结论：按”量化目标 → 消除单点 → 调用链设防 → 数据兜底 → 验证闭环”五步展开，比罗列组件更能体现体系化思考。

原理：第一步定目标：核心链路承诺几个 9、RTO/RPO 多少，按业务分级投入。第二步消单点：应用多实例、数据库主备、缓存集群、入口多线，副本落在不同故障域。第三步沿调用链设防：入口限流，调用设超时和带预算的重试，持续异常触发熔断，非核心可降级，线程池做舱壁隔离。第四步数据兜底：备份定期恢复演练，切换防脑裂，写接口幂等。第五步验证：压测验证容量，故障演练验证容错生效，告警先于用户投诉。

延伸：主动给权衡会加分：多活成本高只在核心业务用；同步复制压 RPO 但拖慢写入；降级要保证体验可预期。能把真实项目的一次故障——怎么发现、怎么止血、怎么根治——嵌进对应环节，这道题就从背书变成设计评审。

追问：预算只够做三件事，你选哪三件？提示：监控告警（看得见）、超时与限流（扛得住）、备份恢复演练（回得来），是投入产出比最高的底座。