3. 高可用架构设计原则
高可用架构设计不是把设备堆得越多越好，而是围绕“业务能容忍多长的中断、能容忍丢多少数据”这两个量化目标，逐层消除故障路径上的薄弱环节。RTO（Recovery Time Objective，恢复时间目标）回答的是“系统从故障发生到恢复服务，最多允许多久”；RPO（Recovery Point Objective，恢复点目标）回答的是“故障发生时，最多允许丢失多长时间窗口内的数据”。这两个指标是全部冗余、隔离与容量设计的起点，也是验收高可用方案是否达标的最终标尺。
一、RTO与RPO：把业务诉求翻译成技术指标
RTO与RPO必须由业务方确认，而不是由DBA凭经验拍定。以Oracle Cloud上的一套核心交易库为例，若业务方要求“故障后5分钟内恢复访问、最多丢失1分钟数据”，则技术目标为 RTO ≤ 5 min、RPO ≤ 1 min。这两个数字直接决定技术选型：
- RPO 决定数据保护方式：RPO=0 通常需要 Data Guard 的 SYNC 同步传输或最大保护模式；RPO 在秒级到分钟级，可用 SYNC 或 FASTSYNC；RPO 允许数分钟以上，则 ASYNC 异步传输即可，且对主库性能影响更小。
- RTO 决定切换方式：RTO 在分钟级，需要 Data Guard Fast-Start Failover（FSFO）配合 Observer 自动切换；RTO 在小时级，可接受人工决策的 Switchover/Failover；RTO 要求秒级，则需应用层配合连接池快速重连与只读降级。
需要特别说明的是，RTO 的计时起点是“业务感知到不可用”的时刻，终点是“业务重新可正常读写”的时刻，中间包含故障检测、决策、切换、实例启动、应用重连全过程。很多方案只计算了切换动作本身，忽略了检测与重连，导致实际 RTO 远超设计值。因此设计时应把 RTO 拆成“检测时间 + 决策时间 + 切换时间 + 应用恢复时间”四段，分别设定预算。
二、单点故障消除：沿调用链逐段排查
单点故障（SPOF）是指任一组件失效即导致整体不可用的环节。消除单点不是只看数据库，而要沿“客户端 → 网络 → 负载均衡 → 应用 → 数据库 → 存储”整条链路排查。常见单点及消除手段包括：
- 数据库实例单点：通过 Data Guard 备库、RAC 多实例或 Autonomous Database 的托管高可用消除。
- 网络路径单点：使用多可用区（Availability Domain / Fault Domain）部署，避免所有节点共用同一交换机或同一子网。
- 存储单点：使用云块存储的多副本能力，或 ASM 冗余组（NORMAL/HIGH）跨故障域镜像。
- 监听与连接入口单点：使用 SCAN VIP、负载均衡器或 DNS 轮询，避免应用硬编码单一主机 IP。
- 运维与备份通道单点：备份、监控、跳板机同样需要冗余，否则故障时无法执行恢复操作。
三、冗余设计与故障域隔离
冗余解决“有备份可用”，故障域隔离解决“备份不会和主库一起挂”。二者必须同时成立才有意义。Oracle Cloud 中常见的故障域层级为：可用区（AD）→ 故障域（FD）→ 主机 → 机架。设计原则是：主库与备库、RAC 各实例、ASM 镜像副本应分布在不同故障域，关键系统跨可用区部署。
以 Data Guard 为例，主库在 AD-1，备库放在 AD-2，则单个可用区级故障不会同时摧毁主备；若主备同处一个 AD 但不同 FD，只能防主机级故障，防不了 AD 级故障。冗余级别应与业务连续性等级匹配，而不是一律追求最高配置，否则成本会迅速失控。
四、容量与性能冗余规划
冗余不只是“多一份”，还要保证接管后性能不塌陷。若主库日常 CPU 使用率已达 70%，故障切换到备库后全部负载压到备库，很可能直接过载，RTO 名义达标而实际不可用。因此容量规划要按“故障后单节点承载全部负载”来核算。
以一套 4 节点 RAC 为例，假设业务峰值 TPS 为 8000，日常每节点承担 2000 TPS、CPU 使用率约 55%。若发生单节点故障，剩余 3 节点需各承担约 2667 TPS，CPU 预计升至 73%，仍在安全水位内，可接受；若故障域级故障导致 2 节点同时失效，剩余 2 节点需各承担 4000 TPS，CPU 将超过 100%，此时必须依赖限流或降级。据此可得出设计结论：N+1 冗余可应对单节点故障，但应对故障域级故障需要 N+2 或跨 AD 部署。
性能冗余还应覆盖以下维度：
- 连接数冗余：备库或剩余实例的 processes/sessions 参数需能容纳切换后全部连接，否则应用会因 ORA-00020 无法接入。
- UNDO 与临时表空间冗余：切换后大批量事务集中到备库，UNDO 表空间不足会引发 ORA-30036。
- I/O 带宽冗余：Data Guard 传输日志、备份任务与业务 I/O 共享带宽，需预留 30% 以上余量。
- 存储容量冗余：归档日志在备库积压、闪回区增长都会占用空间，建议保留不少于 20% 空闲容量。
五、设计校核清单
方案成型后，建议用下表逐项校核，避免纸面高可用、实际仍存在断点。表中数值为示例，实际应替换为本项目确认值。
| 校核项 | 设计目标（示例） | 验证方式 | 判定标准 |
|---|---|---|---|
| RPO 达成 | ≤ 1 min | 查询 V$DATAGUARD_STATS 的 apply lag | apply lag 持续小于 1 min |
| RTO 达成 | ≤ 5 min | 执行 FSFO 演练并计时 | 检测+切换+应用重连合计 ≤ 5 min |
| 单点消除 | 无未受控 SPOF | 逐组件失效推演 | 任一组件失效业务仍可读写 |
| 故障域隔离 | 主备跨 AD | 核对部署拓扑 | 主备不在同一 AD/FD |
| 容量冗余 | 故障后 CPU ≤ 80% | 按剩余节点重算负载 | 峰值负载下无过载 |
综上，RTO 与 RPO 是设计输入，单点消除与故障域隔离是结构保障，容量与性能冗余是接管后的可用性保障。四者环环相扣，缺一不可。设计时应先量化目标，再逐段排查单点、按故障域布置冗余、按最坏情况核算容量，最后用演练数据回验指标，形成可闭环、可验收的高可用架构。