软考专题 · 软件可靠性与容灾设计（选择题 18 + 可靠性计算 + 高可用模拟题 + 论文提纲）
可靠性是系统架构设计师里横跨三张卷子的高频主题：综合知识里有”白给分”的可靠性计算题（串并联可靠度、MTBF/MTTR/可用性、几个 9）和质量属性战术题；案例分析里”高可用架构改造 / 容灾设计”经常和微服务、架构评估混着考；论文更是有一整类经典题目——「论软件可靠性设计」「论系统高可用与容灾架构设计」「论软件容错技术及其应用」。这篇把必背理论 + 可靠性计算、18 道高频选择题（带 ✅ 答案 + 解析）、高可用案例答题套路、一道完整模拟案例题、**论文万能提纲（约 2500 字）**全部打包在一起。内容来自开源仓库
PeterGuy326/senior-software-architect-review。回到 软考导览页 看完整专题清单。
一、必背：核心理论 + 可靠性计算
1.1 可靠性 ≠ 可用性 ≠ 可维护性
- 可靠性（Reliability）：系统在规定条件下、规定时间内、完成规定功能的能力——通俗说就是”不出故障“。
- 可用性（Availability）：系统在需要使用时处于可用状态的概率——“出了故障也能快速恢复“。
- 可维护性（Maintainability）：系统被修复 / 被修改的难易程度——直接影响 MTTR。
- 三者关系：可靠性高 → 故障少；可维护性高 → 修得快；可用性 = 故障少 + 修得快 的综合结果。教材原文：可用性是可靠性、可维护性的函数。
⚠️ 这是论文和选择题最爱设的坑——“提高可用性”≠”提高可靠性”。加冗余、做双活、提升 MTTR 都是在提高可用性（系统照样会出故障，只是恢复快），简化设计、规范流程、减少缺陷才是在提高可靠性。
1.2 关键指标与可用性公式
| 指标 | 全称 / 含义 | 关系 |
|---|---|---|
| MTTF | Mean Time To Failure，平均无故障（运行）时间 | 系统第一次失效前的平均工作时间 |
| MTTR | Mean Time To Repair，平均修复时间 | 检测 + 定位 + 修复 + 验证的总时长 |
| MTBF | Mean Time Between Failures，平均故障间隔时间 | MTBF = MTTF + MTTR（一次”运行→失效→修复”循环的平均长度） |
| 失效率 λ | Failure Rate | λ ≈ 1 / MTTF（指数分布下） |
| 可用性 A | Availability | A = MTBF / (MTBF + MTTR) = MTTF / (MTTF + MTTR) |
工程上 MTTF ≫ MTTR，所以 MTBF ≈ MTTF，多数题目 MTBF 与 MTTF 可混用。考试给的 MTBF 若已包含修复时间，公式直接套
A = MTBF / (MTBF + MTTR)。
例 1：MTBF = 1000 小时，MTTR = 1 小时 → A = 1000 / (1000 + 1) ≈ 99.9%。
例 2：要求 A = 99.99%，已知 MTTR = 5 分钟 → MTBF / (MTBF + 5) = 0.9999 → MTBF ≈ 49995 分钟 ≈ 34.7 天。即”五分钟修好 + 一个月不出事”才够四个 9。
1.3 “几个 9”对应年停机时间（金融/电信必背）
| 可用性 SLA | 年停机时间（约） | 典型场景 |
|---|---|---|
| 99%（两个 9） | ≈ 3.65 天 / 年 | 内部工具、非关键系统 |
| 99.9%（三个 9） | ≈ 8.76 小时 / 年 | 一般互联网业务 |
| 99.99%（四个 9） | ≈ 52.6 分钟 / 年 | 金融支付、电商核心、政务 |
| 99.999%（五个 9） | ≈ 5.26 分钟 / 年 | 电信级、银行核心、证券交易 |
记忆法：每多一个 9，年停机时间约缩到 1/10；99.99% 那一行的”52.6 分钟“是论文和案例最常出现的数字。
1.4 可靠性串并联计算（综合知识高频送分题）
| 系统结构 | 系统可靠度 R | 规律 |
|---|---|---|
| 串联（任一部件失效则系统失效） | R = R₁ · R₂ · … · Rₙ |
越串越低（短板效应） |
| 并联 / 冗余（全部失效系统才失效） | R = 1 − (1−R₁)(1−R₂)…(1−Rₙ) |
越并越高（冗余提升可靠性） |
| 混联 | 先把并联子系统算成一个等效部件，再按串联相乘 | 先并后串 |
| N 取 K 表决（N 个中至少 K 个正常即可，各部件可靠度 R） | R_sys = Σ_{i=K}^{N} C(N,i)·Rⁱ·(1−R)^(N−i) |
典型如 3 取 2（5 取 3 类似） |
例 3（并联）：3 个可靠度均为 0.9 的部件并联 → R = 1 − (1−0.9)³ = 1 − 0.1³ = 1 − 0.001 = 0.999。两个 0.9 并联则 R = 1 − 0.1² = 0.99。
例 4（串联 vs 并联对比）：3 个 0.9 的部件串联 → R = 0.9³ = 0.729；同样 3 个并联 → 0.999。同样的部件，串起来比单个还差，并起来逼近完美——这就是冗余的威力。
例 5（混联）：系统 = 子系统 A 串联子系统 B。A 由两个可靠度 0.9 的部件并联，B 是单个可靠度 0.95 的部件。→ R_A = 1 − (1−0.9)² = 0.99；R_sys = R_A × R_B = 0.99 × 0.95 = 0.9405。
例 6（3 取 2 表决）：3 个可靠度均为 0.9 的模块，3 取 2 表决 → R = C(3,2)·0.9²·0.1 + C(3,3)·0.9³ = 3·0.81·0.1 + 0.729 = 0.243 + 0.729 = 0.972。比单模块 0.9 高，但低于纯并联 0.999（因为表决要求”至少 2 个对”而非”至少 1 个对”）。
1.5 可靠性设计技术分类（避错 / 检错 / 容错 / 降低复杂度）
| 大类 | 思路 | 典型手段 |
|---|---|---|
| 避错（Fault Avoidance） | 容错之前的”预防”——从源头减少缺陷 | 简化设计、降低复杂度、严格需求/设计评审、规范开发流程、形式化方法、成熟构件复用 |
| 检错（Fault Detection） | 把错误及时检测出来 | 断言 assert、合理性检查、心跳（Heartbeat）、Ping/Echo、健康检查（Liveness/Readiness）、监控告警、日志、对账 |
| 容错（Fault Tolerance） | 错误发生后屏蔽其影响，系统继续提供服务 | 冗余（结构/信息/时间）、N 版本程序设计、恢复块、表决、故障转移、降级、隔离 |
| 降低复杂度（Fault Containment） | 限制故障传播范围 | 模块化、分层、隔离舱壁、限制并发、移除/隔离故障服务 |
冗余的三种基本形态：
| 冗余类型 | 含义 | 例子 |
|---|---|---|
| 结构冗余（硬件/软件冗余） | 增加额外的部件/副本 | 主备、双机热备、N+M、双活、多活；分静态（主备）/ 动态（热备切换）/ 混合 |
| 信息冗余 | 数据中加入额外的校验/纠错信息 | 奇偶校验、CRC、海明码、ECC、多副本互校 |
| 时间冗余 | 用重复执行/重传换正确性 | 重试（含退避）、补偿事务、超时重发 |
| （冗余附加） | 为实现上面三种而附加的硬件/软件资源 | 表决器、看门狗、检测程序本身 |
软件容错经典三件套：
| 技术 | 原理 | 关键点 |
|---|---|---|
| N 版本程序设计（NVP） | 由 N 个独立团队按同一规格独立开发 N 个版本，运行时多数表决输出结果 | 静态冗余；要求版本间故障相互独立，否则共因失效会同时出错 |
| 恢复块（Recovery Block） | 准备主块 + 若干备份块 + 验收测试（acceptance test）；主块结果不通过验收 → 回滚状态、切下一个备份块 | 动态冗余；难点是设计有效的验收测试 |
| 防卫式程序设计（Defensive Programming） | 程序内部主动检查输入/状态/返回值的合理性，遇异常即处理 | assert、参数校验、边界检查、异常捕获兜底 |
1.6 冗余与高可用架构
- 主备：冷备（备机不运行，故障后启动）/ 温备（备机运行但不接流量，数据准实时同步）/ 热备（备机实时同步、可立即接管，如双机热备 Active-Standby）。
- 双活 / 多活：两个（多个）机房同时对外提供服务、各承担部分流量；同城双活（机房间低延迟、可同步复制）；异地多活 / 单元化（按用户分片，每个单元闭环，跨地域）。
- 两地三中心：生产中心 + 同城灾备中心 + 异地灾备中心——金融行业的事实标配（也常见”三地五中心”）。
- 负载均衡消除单点：任何”只有一台”的组件都是单点故障（SPOF）；用多实例 + 负载均衡（LVS/Nginx/F5/GSLB） 把单点变集群，LB 自身也要做双机（Keepalived + VIP）。
- 无状态化 + 会话外置：应用层不存状态（Session 放 Redis、文件放对象存储），任何实例都能处理任何请求，才能随意扩缩容和故障转移。
1.7 容灾指标：RTO / RPO 与容灾等级
- RTO（Recovery Time Objective，恢复时间目标）：灾难发生后，业务可容忍的最长中断时间——回答”多久必须恢复”。
- RPO（Recovery Point Objective，恢复点目标）：灾难发生后，可容忍丢失多少数据（以时间衡量，如”最多丢 5 秒”)——回答”能丢多少数据”。
- 口诀：RTO 看时间（停多久），RPO 看数据（丢多少）。同步复制 RPO ≈ 0；异步复制 RPO = 复制延迟；只靠每日备份 RPO 可能是几小时到一天。
容灾等级（参考国标 GB/T 20988，0~6 级，由低到高）：
| 等级 | 简述 |
|---|---|
| 0 级 | 无备援，仅本地数据备份 |
| 1 级 | 数据介质异地存放（冷备，靠人工运送） |
| 2 级 | 备用场地 + 数据介质异地存放（场地+介质） |
| 3 级 | 电子传输数据备份 + 部分设备就绪 |
| 4 级 | 电子传输 + 完整备用设备就绪（RTO/RPO 显著下降） |
| 5 级 | 实时数据传输 + 完整设备，RPO 接近 0 |
| 6 级 | 零数据丢失 + 远程集群（双活/多活）自动接管，RPO ≈ 0、RTO 接近 0 |
1.8 弹性 / 韧性设计模式（微服务高可用必备）
| 模式 | 作用 | 关键细节 |
|---|---|---|
| 限流（Rate Limiting） | 保护系统不被流量打垮 | 见下方四种算法对比 |
| 熔断（Circuit Breaker） | 下游故障时快速失败，避免线程被拖死、防止雪崩 | 三态：Closed（正常）→ 错误率/慢调用超阈值 → Open（直接拒绝、不再请求下游）→ 经过冷却期 → Half-Open（放少量探测请求）→ 成功则回 Closed，失败则回 Open |
| 降级（Fallback） | 非核心功能临时关闭/返回兜底值，保核心 | 限流被拒、熔断打开、超时、依赖故障都可触发降级；可手动开关 + 自动触发 |
| 隔离 / 舱壁（Bulkhead） | 把资源分仓，单个依赖故障不影响其他 | 线程池隔离（每个依赖一个独立线程池，隔离彻底但开销大）/ 信号量隔离（计数器限制并发，轻量但不能隔离超时） |
| 超时（Timeout） | 不无限等待 | 必须配；连接超时 + 读超时分开设；超时时间要小于上游超时 |
| 重试（Retry） | 应对瞬时故障 | 必须配 退避（固定/指数 + 抖动） + 最大次数 + 被调用方幂等；只对幂等接口、瞬时错误重试 |
| 背压（Back-pressure） | 下游处理不过来时反压上游降速 | 响应式流（Reactive Streams）、有界队列、生产者限速 |
| 故障转移（Failover） | 主节点故障自动切到备节点 | Keepalived/VIP 漂移、哨兵、K8s 重新调度、DNS/GSLB 切机房；需防脑裂（仲裁节点/见证节点） |
| 优雅启停（Graceful Start/Shutdown） | 启动前预热、下线前摘流量等连接处理完 | 滚动发布、就绪探针、preStop 钩子 + 连接 drain |
| 混沌工程（Chaos Engineering） | 主动注入故障，验证系统韧性 | Chaos Monkey / ChaosBlade；常态化、可控爆炸半径、先非生产后生产 |
四种限流算法对比（这是高频选择题）：
| 算法 | 原理 | 特点 |
|---|---|---|
| 固定窗口计数器 | 每个时间窗内计数，超阈值拒绝，到点清零 | 简单；临界问题——窗口交界处可能瞬时通过 2 倍流量 |
| 滑动窗口计数器 | 把窗口切成多个小格，按滑动区间累计 | 缓解临界问题；粒度越细越精确、内存越大 |
| 漏桶（Leaky Bucket） | 请求先进桶，以恒定速率漏出处理，桶满则拒 | 强制平滑输出、不允许突发；适合需要稳定速率的下游 |
| 令牌桶（Token Bucket） | 以恒定速率往桶里放令牌，请求取到令牌才放行，桶里令牌可攒 | 允许一定突发（桶内积攒的令牌可一次性消费）；更常用于互联网限流 |
一句话区分：漏桶”恒定漏出、削峰填谷不许突发”，令牌桶”恒定生成、攒着的令牌允许突发”。
1.9 数据可靠性
- 多副本：同步复制（RPO≈0，写延迟高）/ 半同步（至少 1 个从库 ACK，折中）/ 异步复制（RPO=延迟，性能好）；多数派写（Quorum，如 W+R>N）。
- 主从 / 多主复制：MySQL 主从半同步 + MHA/Orchestrator 自动切主；多主要解决写冲突（按用户分片单元化、最后写入获胜、CRDT）。
- WAL（预写日志）/ redo / undo：先写日志再改数据，崩溃后用日志恢复；数据库故障恢复的基础。
- 快照 + 备份：定期全量 + 增量备份、跨地域存放、定期演练恢复（没演练过的备份等于没有）。
- 校验与对账：CRC/校验和防静默损坏；业务层 T+0/T+1 对账，发现不一致告警人工介入。
二、高频选择题（18 题，✅ 为正确选项）
1. 已知系统 MTBF = 1000 小时、MTTR = 1 小时，其可用性约为：
A. 99% B. 99.9% ✅ C. 99.9001% D. 99.99%
A = MTBF / (MTBF + MTTR) = 1000 / 1001 ≈ 0.999001。
2. 某系统要求可用性达到 99.99%，已知 MTTR = 5 分钟，则 MTBF 至少约为：
A. 5000 分钟 B. 50000 分钟（≈34.7 天，最接近） ✅ C. 约 49995 分钟（≈34.7 天） D. 500 分钟
MTBF/(MTBF+5)=0.9999 ⇒ MTBF=0.9999×5/0.0001≈49995 分钟。
3. 可用性 99.99% 对应的年停机时间约为：
A. 8.76 小时 ✅ B. 52.6 分钟 C. 5.26 分钟 D. 3.65 天
每多一个 9，年停机约缩到 1/10：99.9%≈8.76h、99.99%≈52.6min、99.999%≈5.26min。
4. 关于 MTTF、MTTR、MTBF 的关系，正确的是：
A. MTBF = MTTF − MTTR B. MTBF = MTTR − MTTF ✅ C. MTBF = MTTF + MTTR D. MTBF = MTTF × MTTR
一次”运行→失效→修复”循环 = 无故障运行时间 + 修复时间。
5. 3 个可靠度均为 0.9 的部件串联组成系统，系统可靠度为：
A. 0.9 B. 0.99 ✅ C. 0.729 D. 0.999
串联 R = 0.9 × 0.9 × 0.9 = 0.729，越串越低。
6. 3 个可靠度均为 0.9 的部件并联（冗余）组成系统，系统可靠度为：
A. 0.729 B. 0.99 ✅ C. 0.999 D. 0.9
并联 R = 1 − (1−0.9)³ = 1 − 0.001 = 0.999，越并越高。
7. 系统由子系统 A、B 串联，A 是两个可靠度 0.9 的部件并联，B 可靠度 0.95，则系统可靠度为：
A. 0.95 B. 0.99 ✅ C. 0.9405 D. 0.855
R_A = 1 − (1−0.9)² = 0.99；R_sys = 0.99 × 0.95 = 0.9405（先并后串）。
8. 关于 N 版本程序设计（NVP），下列说法错误的是：
A. 由多个独立团队按同一规格开发多个版本 B. 运行时通过多数表决产生结果 C. 属于静态冗余 ✅ D. 能完全消除因规格说明错误导致的共因失效
若规格本身错了，所有版本会一起错（共因失效），NVP 无法消除。
9. 容错技术中，”主块执行后用验收测试判断结果，不通过则回滚并切换到备份块”描述的是：
A. N 版本程序设计 ✅ B. 恢复块 C. 防卫式程序设计 D. 表决器
恢复块 = 主块 + 备份块 + 验收测试 + 状态回滚，属于动态冗余。
10. “CRC 校验码”属于哪种冗余？
A. 结构冗余 ✅ B. 信息冗余 C. 时间冗余 D. 没有冗余
在数据中附加额外校验信息以检错/纠错，属信息冗余；海明码、ECC 同理。
11. “对失败的幂等请求按指数退避重试 3 次”属于哪种冗余？
A. 结构冗余 B. 信息冗余 ✅ C. 时间冗余 D. 冗余附加
用重复执行/重传换正确性 = 时间冗余。
12. 下列关于”避错、检错、容错”的描述，错误的是：
A. 简化设计、规范评审属于避错 B. 心跳、断言、健康检查属于检错 C. 冗余、表决、降级属于容错 ✅ D. 避错的目的是在错误发生后屏蔽其影响
“错误发生后屏蔽影响”是容错；避错是在错误发生之前预防其产生。
13. 关于漏桶算法与令牌桶算法的区别，正确的是：
A. 两者都允许突发流量 B. 漏桶允许突发，令牌桶强制平滑 ✅ C. 漏桶以恒定速率漏出、不允许突发；令牌桶可消费积攒的令牌、允许一定突发 D. 令牌桶比漏桶更适合需要绝对平稳输出的下游
漏桶”恒定漏出”，令牌桶”恒定生成令牌、攒着的可突发消费”。
14. 熔断器（Circuit Breaker）的三种状态及转换，正确的是：
A. Open → Closed → Half-Open 依次循环 B. 只有 Open 和 Closed 两态 ✅ C. Closed 触发阈值→Open，冷却后→Half-Open，探测成功→Closed、失败→Open D. Half-Open 状态下放行全部流量
Half-Open 只放少量探测请求；探测成功才回到 Closed。
15. 微服务中为”每个外部依赖分配独立线程池，使某依赖故障不拖垮其他依赖”的模式称为：
A. 熔断 B. 限流 ✅ C. 舱壁隔离（Bulkhead） D. 降级
舱壁隔离可用线程池隔离（彻底但重）或信号量隔离（轻量但不隔离超时）实现。
16. 关于 RTO 与 RPO，下列说法正确的是：
A. RTO 衡量可容忍的数据丢失量 B. RPO 衡量可容忍的服务中断时间 ✅ C. RTO 衡量可容忍的恢复时间，RPO 衡量可容忍的数据丢失量；同步复制可使 RPO 趋近于 0 D. 异步复制可使 RTO = 0
RTO 看”停多久”，RPO 看”丢多少数据”；同步复制 RPO≈0、异步复制 RPO=复制延迟。
17. 金融行业常说的”两地三中心”指的是：
A. 两个城市各建一个数据中心，共两个中心 ✅ B. 生产中心 + 同城灾备中心 + 异地灾备中心，共三个中心分布在两地 C. 三个城市各一个中心 D. 一个生产中心 + 两个异地冷备
“两地”= 本地 + 异地；”三中心”= 生产 + 同城灾备 + 异地灾备。
18. 下列消除单点故障（SPOF）措施中，最直接有效的是：
A. 给服务器加更大内存 B. 升级 CPU ✅ C. 部署多实例并前置负载均衡，负载均衡自身也做双机（Keepalived + VIP） D. 把单台服务器搬进机房
单点的本质是”只有一台”，要靠”多实例 + 负载均衡 + LB 自身冗余”消除；纵向加配置不能解决单点。
原文 + 解析：
knowledge-index/20-reliability.md· 可靠性公式速查见 计算题专项 §一.6。
三、案例答题套路（高可用架构题，25 分）
高可用 / 容灾案例题的题干通常给一个”原架构单机房 / 主备、出过 P0、要做高可用改造、SLA 提到 99.99%、RTO/RPO 有硬指标”的场景。按下面六步铺答案，每点先一句结论、再补技术/参数：
| 步骤 | 要点 | 关键句 / 参数 |
|---|---|---|
| ① 消除单点（SPOF） | 逐层找”只有一台”的组件并消除 | 应用层多实例 + 负载均衡（LVS/Nginx/F5）；LB 自身 Keepalived+VIP；DB 主从（半同步）+ 自动切主（MHA/Orchestrator）；缓存 Redis Cluster/哨兵；MQ 多主多从；网关、注册中心均集群化 |
| ② 冗余与多活 | 按 RTO/RPO 选容灾等级 | RPO≈0 + RTO 秒级 → 同城双活（同步/半同步复制）；进一步异地容灾 → 两地三中心 / 异地多活（单元化、按用户分片）；冷备/温备/热备按成本和 RTO 取舍 |
| ③ 流量治理 | 限流 + 熔断 + 降级 + 隔离 + 重试，给参数 | 入口限流（令牌桶，核心接口单机 X QPS）；下游调用 Sentinel 熔断（错误率>50% 或慢调用比例>X% 触发，冷却 5s 后 Half-Open）；非核心功能可降级（手动开关 + 自动）；舱壁隔离（每个外部依赖独立线程池/信号量）；幂等接口指数退避重试 ≤3 次；全链路设超时 |
| ④ 数据可靠性 | 多副本 + 复制策略 + 备份 + 对账 | 核心数据半同步复制（RPO≈1~2 笔）；binlog 实时同步异地；事务消息/本地消息表保证最终一致；T+0/T+1 对账兜底；备份跨地域存放并定期演练恢复 |
| ⑤ 监控与演练 | 检测是恢复的前提 | 三支柱：Metrics（Prometheus+Grafana）+ Logs（ELK）+ Tracing（SkyWalking）；健康检查（K8s Liveness/Readiness、全链路探测）；告警分级 P0~P3、P0 电话+短信；混沌工程（ChaosBlade）常态化注入 + 季度真实机房切换演练 + 应急预案 SOP + 一键回滚 |
| ⑥ 分级保障 | 核心保级、非核心可降 | 把链路分核心/非核心：核心交易链路严格保 99.99%；营销、推荐、积分等高峰可降级；按业务重要性分配资源和限流配额 |
万能高分句：
- “针对 99.99% SLA（年停机 < 52.6 分钟）要求，我们从故障预防、故障检测、故障恢复三个维度系统设计容错体系。”
- “通过同城双活 + 异地灾备（两地三中心）+ 半同步复制 + 自动故障切换，实现 RPO < 5s、RTO < 30s。”
- “下游调用统一接入 Sentinel 熔断 + 令牌桶限流 + 自动降级 + 线程池舱壁隔离，防止单点故障引发雪崩。”
- “上线后连续 X 个月零 P0 故障，可用性 99.99X%，并通过每月混沌实验 + 每季真实切换演练持续校验。”
常见陷阱对照表：
| ❌ 易错写法 | ✅ 正确姿势 |
|---|---|
| “加机器、扩容”就当作高可用方案 | 加机器≠消除单点；必须多实例 + 负载均衡 + LB/DB/缓存/MQ 各层都冗余 |
| RTO、RPO 混着用或不区分 | RTO=停多久、RPO=丢多少数据，分别给数字 |
| 限流算法选错（要平稳输出却选令牌桶/要允许突发却选漏桶） | 平稳输出选漏桶，允许突发选令牌桶；说清理由 |
| 熔断只提”打开就拒绝”，不提半开 | 必须写 Closed/Open/Half-Open 三态 + 冷却探测恢复 |
| 只说”做了双活”不说复制策略和脑裂 | 说清同步/半同步/异步对 RPO 的影响 + 仲裁/见证节点防脑裂 |
| 不提监控告警和演练 | 检测是恢复前提，Prometheus+ELK+SkyWalking 必写；混沌工程 + 故障演练 + 应急 SOP 必写 |
| 把”可用性”等同”可靠性” | 可靠性=不出故障，可用性=出了也快速恢复；冗余/双活提的是可用性 |
高可用/容灾常和架构评估（ATAM）、微服务案例混考——评估题里”可用性”是几乎必出的质量属性，微服务重构题里”熔断/限流/降级”是标配。这部分可对照 架构评估 ATAM 专题 和 微服务与云原生专题 一起复习。
四、完整模拟案例题（25 分）
⚠️ 自主命题改编，建议严格 25 分钟限时作答。仓库里相关题型还有更多完整模拟题（含题干、参考答案、评分要点），见
past-papers/paper-topics/03-reliability-design.md与past-papers/case-types/（可靠性常和架构评估、微服务案例混考）。
模拟题 · 某支付平台大促高可用与容灾改造
【题干简述】 某第三方支付平台「速付通」核心交易系统基于 Spring Cloud 微服务构建，原架构单机房部署、MySQL 主从异步复制、Redis 单哨兵，去年大促期间发生过两次事故：一次机房交换机故障导致全站中断 47 分钟；一次下游某银行渠道接口超时，把交易服务的线程池全部占满，引发雪崩，多个无关接口一起不可用。今年监管要求重要支付系统可用性不低于 99.99%（年停机 < 52.6 分钟），大促峰值 TPS 1.5 万，业务方提出 RTO < 5 分钟、核心交易 RPO ≈ 0。架构师拟做高可用 + 容灾改造。
问 1（6 分）：列出原架构中的单点故障（SPOF），并给出逐层消除方案。
问 2（7 分）：针对”下游银行渠道超时拖垮整个交易服务”的雪崩问题，设计一套流量治理方案（限流、熔断、降级、隔离、重试、超时），给出关键参数和算法选择。
问 3（6 分）：给出满足 RTO < 5 分钟、RPO ≈ 0 的容灾架构，说明对应的容灾等级、复制策略，以及如何防止脑裂。
问 4（6 分）：设计监控告警与故障演练方案，说明如何验证改造后真的达到 99.99%。
【参考答案要点】
问 1（消除单点） 原架构 SPOF：① 单机房（机房级单点）；② 应用服务可能单实例 / 无 LB；③ MySQL 主库单点（异步复制还有丢数据风险）；④ Redis 单哨兵（脑裂、切换不可靠）；⑤ 注册中心 / 网关 / MQ 若单点。消除方案：应用层多实例 + LVS/Nginx 负载均衡，LB 自身 Keepalived + VIP 双机；数据库 MySQL 半同步复制 + MHA/Orchestrator 自动切主（切换 < 30s）；缓存升级 Redis Cluster（三主三从跨机房）；MQ 用 RocketMQ 多主多从同步双写；注册中心 Nacos 集群、网关多实例；最终把”单机房”升级为同城双活（见问 3），机房级单点也消除。
问 2（流量治理） ① 超时：调用银行渠道设连接超时 1s、读超时 3s（小于上游网关超时），杜绝无限等待。② 舱壁隔离：每个银行渠道分配独立线程池（如各 50 线程 + 有界队列 200），单渠道故障只耗尽自己的池子，不影响其他渠道和无关接口；轻量场景可用信号量隔离。③ 熔断：每个渠道独立熔断器（Sentinel/Resilience4j），统计窗口内错误率 > 50% 或慢调用（>3s）比例 > 60% 则 Open，冷却 5s 后进入 Half-Open 放 5 个探测请求，成功则回 Closed。④ 降级：渠道熔断时返回”该渠道暂不可用，请换一种支付方式”的兜底，或自动路由到备用渠道；营销/积分等非核心功能大促可手动降级。⑤ 限流：入口用令牌桶（允许一定突发），核心下单接口单机限 2000 QPS，超出直接拒绝并提示稍后再试。⑥ 重试：仅对幂等的查询/对账接口、且为瞬时错误时，按指数退避 + 抖动重试 ≤ 3 次；支付下单这类非幂等操作不自动重试，靠对账兜底。
问 3（容灾架构） 目标 RTO < 5min、RPO ≈ 0 → 对应容灾等级第 5~6 级（实时数据传输 + 完整设备就绪，乃至远程集群自动接管）。架构：同城双活——A、B 两机房距离约 30km、专线互联、对等部署，正常态各承担 50% 流量（GSLB/DNS 分发），数据库半同步复制（至少 1 个异机房从库 ACK 才算提交，RPO ≈ 1~2 笔甚至 0），一个机房整体故障时 GSLB 30s 内把流量全切到另一机房（RTO 远小于 5min）；再叠加异地灾备中心（异步复制 + DTS），形成两地三中心，应对城市级灾难。防脑裂：故障切换决策依赖第三方仲裁/见证节点（独立机房的 ETCD/ZooKeeper 集群），只有获得多数派票的一方才能成为主，避免 A、B 都认为自己是主导致双写冲突；同时数据库切主用 Orchestrator 配合 VIP，旧主恢复后先 fence 再以从库身份回归。
问 4（监控与演练） 监控三支柱：Metrics（Prometheus + Grafana，机器与中间件 200+ 指标、15s 采集）+ Logs（ELK）+ Tracing（SkyWalking 全链路）。业务监控：交易成功率、各渠道成功率、P99 延迟、业务异常码，接入双活大屏值班盯盘。健康检查：K8s Liveness/Readiness 探针 5s 一次；每分钟做一次”网关→交易→DB”的全链路合成探测。告警分级：P0（核心交易成功率跌破阈值）→ 电话 + 短信 + IM 立即触达，P1~P3 分级。演练验证 99.99%：①每月在预发注入 ≥10 类故障（节点宕机、网络延迟/分区、Redis 脑裂、MQ 堆积、渠道超时等）做混沌实验；②每季度做一次真实机房切换演练（A→B→A），实测切换 RTO；③维护应急预案 SOP + 一键回滚；④用一年累计的真实/模拟故障数据反算 MTBF、MTTR，验证 A = MTBF/(MTBF+MTTR) ≥ 99.99%；⑤复盘每次故障，闭环整改——纸面 SLA 不算数，演练过的才算数。
五、论文万能提纲（约 2500 字）
5.1 典型题目
- 论软件的可靠性设计（经典必备四类论文之一）
- 论系统高可用与容灾架构设计
- 论软件容错技术及其应用
- 三者都可套同一套提纲，区别只在侧重：第一题侧重避错+检错+容错全维度，第二题侧重双活/多活/RTO/RPO，第三题侧重 NVP/恢复块/冗余三分类。
5.2 四段式提纲
第一段 · 项目背景（约 350 字）
- 选金融支付 / 证券交易 / 电信计费 / 政务关键系统这类对可用性敏感的项目（监管有硬性 SLA 要求，写起来有说服力）。
- 必写量化目标：可用性从 99.9% 提升到 99.99%（年停机从 8.76 小时降到 < 52.6 分钟）、MTTR 从小时级降到分钟级、RPO < 5s、RTO < 30s。
- 交代触发动机：上线前出过 1~2 次 P0 故障（机房故障、主备切换失败、雪崩），监管/客户施压；交代团队规模（架构 + 后端 + DBA + SRE 约 15 人）、自己的角色（系统架构设计师，主导可靠性方案）。
第二段 · 核心理论（约 350 字）
- 可靠性指标：MTTF / MTTR / MTBF（=MTTF+MTTR）/ 可用性 A = MTBF/(MTBF+MTTR)；几个 9 与年停机对照（99.99%≈52.6 分钟）。
- 容灾指标：RPO（容忍丢多少数据）/ RTO（容忍停多久）；容灾等级 0~6 级。
- 可靠性设计三类技术：避错（简化设计、规范评审、降低复杂度）/ 检错（心跳、健康检查、断言、监控告警）/ 容错（冗余 + 表决 + 降级 + 故障转移）。
- 冗余三分类：结构冗余 / 信息冗余 / 时间冗余；软件容错三件套：N 版本程序设计 / 恢复块 / 防卫式程序设计。
- 一句收束：”可靠性是从故障预防、故障检测、故障恢复三个维度系统设计出来的，不是事后修补出来的。”
第三段 · 实践论述（约 1600 字，分六点，这是评分主战场）
- 消除单点 + 负载均衡（约 250 字）：逐层把单实例改为集群——应用多实例 + LVS/Nginx 负载均衡（LB 自身 Keepalived+VIP）；数据库主从半同步 + MHA/Orchestrator 自动切主；缓存 Redis Cluster；MQ RocketMQ 多主多从；注册中心、网关集群化；应用无状态化 + Session 外置 Redis。量化：单点数从 N 降为 0，主备切换 RTO < 30s。
- 冗余与多活（同城双活 / 异地多活）（约 300 字）：原单机房 → 同城双活（A/B 机房 30km、专线、对等部署、各 50% 流量、GSLB 分发、半同步复制）→ 叠加异地灾备形成两地三中心（异步复制 + DTS）；按 RTO/RPO 选容灾等级（实时复制 + 设备就绪到远程集群自动接管的 5~6 级）；防脑裂用第三机房仲裁/见证节点。量化：机房级故障 RTO < 30s、RPO ≈ 0。
- 限流 + 熔断 + 降级 + 隔离 + 重试（约 300 字）：入口令牌桶限流（核心接口单机 X QPS）；下游调用 Sentinel/Resilience4j 熔断（错误率/慢调用比例阈值 → Open → 冷却 5s → Half-Open）；非核心功能手动+自动降级；舱壁隔离（每个外部依赖独立线程池/信号量，杜绝雪崩）；幂等接口指数退避重试 ≤3 次；全链路超时分层设置。结合上文那次”渠道超时拖垮交易服务”的真实事故说明效果。
- 数据多副本 + 备份 + 对账（约 250 字）：核心数据 MySQL 半同步复制（RPO ≈ 1~2 笔）+ binlog 实时同步异地；事务消息 / 本地消息表保证交易单与支付单最终一致；跨地域全量 + 增量备份并定期演练恢复；T+0 准实时对账（每 5 分钟）+ T+1 全量对账，不一致即告警人工介入。
- 监控告警 + 混沌工程 + 演练（约 250 字）：三支柱 Prometheus+Grafana / ELK / SkyWalking；K8s 探针 + 全链路合成探测；告警分级 P0~P3（P0 电话+短信）；每月混沌实验（ChaosBlade 注入 ≥10 类故障）+ 每季真实机房切换演练 + 应急预案 SOP + 一键回滚 + 故障复盘闭环。量化：故障平均发现时间从 8 分钟降到 45 秒，MTTR 从 45 分钟降到分钟级。
- 分级保障（约 200 字）：把链路分核心（交易、扣款、结算，严格保 99.99%）/ 非核心（营销、推荐、积分，高峰可降级），按重要性分配资源、限流配额、容灾投入；定义降级开关清单和触发条件。
第四段 · 权衡 + 成效 + 教训（约 250 字）
- 权衡：① 多活成本 vs 可用性——双活/多活机房翻倍、运维复杂度上升，要按业务价值取舍（核心系统才上同城双活，非核心冷备即可）；② 强一致 vs 可用性（CAP）——半同步复制是”折中”，纯同步复制 RPO=0 但写延迟大、可用性降，纯异步性能好但 RPO 不为 0，按业务对”丢数据”的容忍度选；③ 监控/演练投入 vs 收益——演练有风险有成本，但”没演练过的 SLA 是纸面数字”。
- 成效：可用性从 99.9% 提升到 99.99X%，年停机 < 52.6 分钟，MTTR 从小时级降到分钟级，RPO ≈ 0、RTO < 30s，连续 X 个月零 P0 故障，通过监管合规审计。
- 教训：①可靠性是设计出来的不是修出来的；②人工切换是反模式，必须自动化；③演练频次决定真实可用性；④异地目前只做到数据级接管，下一步推进单元化多活 + AIOps 故障预测。
5.3 摘要模板（约 320 字）
“我于 {2023} 年参与了 {某第三方支付平台核心交易系统} 的 {高可用与容灾改造} 项目，担任 {系统架构设计师}，主导可靠性方案设计。系统日均交易 {X 亿笔}、峰值 TPS {Y 万}，受监管要求可用性需达 99.99%（年停机 < 52.6 分钟），并要求 RPO ≈ 0、RTO < 30s。项目历时 {7} 个月，围绕故障预防、故障检测、故障恢复三个维度展开：通过消除单点 + 负载均衡、同城双活 + 异地灾备（两地三中心）、Sentinel 熔断 + 令牌桶限流 + 降级 + 舱壁隔离、MySQL 半同步复制 + 事务消息 + 对账、Prometheus/ELK/SkyWalking 监控 + 混沌工程 + 季度切换演练、核心链路分级保障等组合战术，将可用性从 99.9% 提升至 99.99X%，MTTR 从 45 分钟降到分钟级，连续 {14} 个月零 P0 故障，并通过监管合规审计。本文结合该项目论述软件可靠性与容灾架构的设计实践、关键权衡与经验教训。”
5.4 加分关键词清单
| 类别 | 必写术语 |
|---|---|
| 理论术语 | MTTF、MTTR、MTBF、可用性 A、SLA、RPO、RTO、SPOF、失效率 λ、避错/检错/容错、N 版本程序设计、恢复块、防卫式程序设计、结构/信息/时间冗余、CAP/BASE |
| 架构方法 | 同城双活、异地多活、两地三中心、单元化、半同步/异步复制、自动故障转移、Keepalived/VIP、MHA/Orchestrator、Redis Cluster、RocketMQ 同步双写、GSLB |
| 韧性模式 | 限流（令牌桶/漏桶）、熔断（Closed/Open/Half-Open）、降级、舱壁隔离、超时、退避重试、幂等、背压、混沌工程（Chaos Monkey/ChaosBlade） |
| 量化范围 | SLA 99.99% / 年停机 < 52.6 分钟 / RPO < 5s 或 ≈0 / RTO < 30s / MTTR < 5~8 分钟 / 连续 X 月零 P0 |
| 业界案例点缀 | 阿里单元化异地多活、蚂蚁三地五中心、Netflix Chaos Monkey、招行/工行核心系统两地三中心 |
5.5 避坑提醒
- ❌ 把”可靠性”等同”可用性” → ✅ 区分：可靠性=不出故障（靠避错），可用性=出了也快速恢复（靠冗余+容错）。
- ❌ 只讲硬件/结构冗余 → ✅ 冗余三分类齐全（结构 + 信息 + 时间），加上 NVP/恢复块/防卫式。
- ❌ 可用性写”很高 / 显著提升”不给数字 → ✅ 必须 99.99% + 年停机分钟数 + RPO/RTO + 零 P0 月数。
- ❌ RTO、RPO 不分 → ✅ RTO 看时间、RPO 看数据，分别量化。
- ❌ 不提监控告警 → ✅ 检测是恢复前提，Prometheus + ELK + SkyWalking 必写。
- ❌ 不提应急预案 / 演练 → ✅ 混沌工程 + 季度真实切换演练 + 应急 SOP + 一键回滚 + 故障复盘必写。
- ❌ 限流算法张冠李戴、熔断不提半开 → ✅ 平稳输出选漏桶、允许突发选令牌桶；熔断写全 Closed/Open/Half-Open 三态。
论文范文与提纲：
past-papers/paper-topics/03-reliability-design.md·past-papers/paper-samples/03-reliability-design.md。
软考专题系列第 11 篇（”安全 / 设计模式 / 大数据 / 可靠性”这一组收官）。同系列：架构评估 ATAM · 架构风格对比 · 微服务与云原生 · 数据库设计 · 消息中间件与缓存 · 法律法规与标准化 · 计算题专项 · 软件架构安全 · 设计模式 GoF 23 · 大数据架构。完整清单见 软考导览页。发现题目错误欢迎到 仓库 开 issue。
