海王三叉戟：让系统“全年无休”的高可用攻略
面向一线开发与准架构师，用轻松口吻把“高可用”讲透：先认清业务连续性的三叉戟，再看集群/分布式、本地备份、异地多活、流程演练、面试答题。
1. 高可用的使命：业务连续性三叉戟
- 本地高可用：任何单点硬件故障都不应影响服务，最好能自动切换、数据 0 丢失。
- 数据逻辑保护：防人祸/软件 bug；重点是备份、快照、回滚链路。
- 异地容灾 / 多活：面对机房级故障或自然灾害，能跨城市接管业务，兼顾 RTO/RPO。
三叉戟的杆子=业务连续性。架构师不仅写代码，更要保证生产系统 24×7 运行。
2. 第一叉：本地高可用（集群 vs 分布式）
2.1 集群型（CA）
- 应用/中间件/数据库/存储全部做双机或多机热备，满足强一致 + 高可用。
- 典型方案：PowerHA、Veritas VCS、Oracle RAC、DB2 PureScale、GPFS、阵列 RAID。
- 适合：核心交易库、强一致 OLTP。
2.2 分布式型（AP）
- 谈扩展性：服务拆分、消息队列、Redis、Kafka、Mongo、Hadoop、MySQL CDC。
- 难点：脑裂、幂等、最终一致；需要配套治理（选主、心跳、监控）。
- 真·高可用 = 架构 + 流程：全链路压测、混沌演练、监控告警、发布管控。
2.3 实例：系统集成商 POC
- 双机房、三节点、小型机 + 存储复制，演练断网/断链路/断电/存储故障。
- 结论：任何单点失败都能自动切换，用户无感。
3. 第二叉：数据逻辑保护
3.1 为什么“删库跑路”是最大威胁？
- Gartner：80% 中断来自计划内事件（可控），真正大额损失来自15%计划外事件，其中人工+流程+发布占 80%。
- 本地 HA 只能挡硬件故障，挡不住误操作。
3.2 三部曲
- 预防：备份/快照/CDP + 严格变更/灰度（N 和 N-1 并存）。
- 监控/审计：定义正常 vs 异常行为，自动检测。
- 恢复：回滚、快照、数据追补、应用回滚。
3.3 技术手段
- 传统备份 → 虚拟带库 → 对象存储（成本更低、生命周期管理、自带 11 个 9）。
- 快照 + CDP：分钟级回滚，配合数据库 Flashback。
- CQRS + Event Sourcing：命令事件化，读写分离，天生可追溯。
- 真实案例：运营商利用重删 + 远端复制，带宽节省 90%。
4. 第三叉：异地容灾 / 多活 / 单元化
4.1 同城双活 vs 异地多活
- 同城双活：城市内两个机房（机架/电力/运营商多元化）。
- 异地多活：跨百公里，需应对 1ms+ 延迟；数据库/存储/网络都有不同方案。
- 复制层次：
- 数据库层（DataGuard/HADR/CDC）：灵活、依赖 CPU/网络。
- SAN 虚拟化层（SVC/USP）：对 DB 透明，但自身是瓶颈。
- 存储控制器层（厂商自带复制）：性能最好，但同构、成本高。
4.2 两地三中心 / 四中心实践
- 案例：大型金融在上海/无锡做“两地四中心”，季度轮换主场。
- 核心集群两套（A/B）+ 远端只收数据备份，切换演练常态化。
4.3 DRP → BCP 流程
- 项目启动：角色划分（RACI）。
- 需求分析：风险分析、可恢复性分析、业务影响分析（BIA）。
- 架构设计：策略、技术选型、演进路线。
- 实施与演练：数据/应用/基础设施搭建 + 准生产 → 并行 → 全断联演练。
- 运维监控：SRE 接管，持续监控/演练。
- 知识转移 + 项目管理：贯穿全周期。
4.4 RTO / RPO 评估示例
- 银行核心系统：同城 15 分钟恢复、RPO 5 分钟；异地 2 小时、RPO 15 分钟。
- 税务演练：2 小时内完成切换，RPO≈0。
4.5 BCP（业务连续性计划）
- DRP 是子集，还要写清本地 HA、逻辑保护、升级/补丁、人员备份、沟通方式、损失评估。
5. 多活 / SET / 妥协策略
5.1 多活成本：双活 200%，三活 150%，N 活渐近 100%
- 多活本质是 SET（单元化）：请求路由 → 单元封闭 → 跨单元同步。
- 案例：导航企业按地理位置路由，使用 MySQL→AliSQL、Redis→URedis，多管道同步。
- 宇宙大行：操作系统/数据库/中间件/存储多层同步，达成双活。
5.2 妥协方案
- CAP 取舍：牺牲强一致，换取可用/分区容忍。
- 熔断：快速切断故障服务，保住主链路。
- 降级：释放 CPU/内存/带宽，让关键功能存活。
- 排队/限流：减少入口压力（与性能章节呼应）。
6. 高可用流程与文化
6.1 Google SRE
- 70% 自动化，30% 运维；关注四大黄金指标：延迟、流量、错误、饱和度。
- SLO/SLI：可量化目标；Error Budget 控制发布节奏，预算耗尽立即冻结变更。
6.2 Netflix Chaos Engineering
- 猴子→猩猩→大金刚：从单节点故障演练到 Region 级失效演练。
6.3 SAP ATP（Availability to Promise）
- 业务层面评估：影响交易比例 × 时间 × 重要性。
- 公式可套在携程/电商，量化“业务可用度”。
6.4 IBM HA 评估
- MTBF/MTTR 推导单设备可用度；串联 vs 并联计算整体可用度。
- 启示：串联=降可用，尽量并联或异步解耦。
6.5 美团点评 CAT 监控
- 三维度：Metric（时序）、Trace（链路）、Log（错误）。
- 扩展：交易特征、事件聚合、交易时间线 + 可视化报告。
7. 面试怎么答？
- 如何实现本地高可用？
- 先讲业务目标（几个 9 + RTO/RPO），再讲集群/分布式设计，别忘了流程（混沌、全链路、监控、发布管控）。
- 如何防“删库跑路”？
- 备份/快照/CDP + CQRS/Event Sourcing + 权限审计 + 恢复演练 + 成本 vs 保护级别。
- 异地多活 / 单元化怎么做？
- 容灾复制选型、DRP/BCP 流程、SET 经验（路由、封闭、同步）、数据一致性策略。
QQ 讨论题
- 给自己负责的子系统做一遍高可用自查，算算能撑几个 9（可参考 ATP 或 IBM 方法）。
- 分享一次高可用落地经验：方案/流程、踩坑与收益。
8. 小抄
- “海王三叉戟”是记忆口诀：本地 HA、逻辑保护、异地容灾。
- 高可用永远是“架构 + 流程 + 组织”三位一体。
- 多活/SET 不只省钱，还提升弹性；核心在路由、封闭、同步。
- 没有演练的 DRP 等于没有；Error Budget / Chaos / CAT 让高可用进入工程化。
- 面试要讲：业务目标 → 技术选型 → 流程保障 → 实战案例。
下一章进入安全性维度，把“可用”与“安全”拼成系统级韧性的闭环。敬请期待。
