{T}

高可用架构设计

概述

高可用架构(High Availability Architecture)的目标是确保系统在硬件故障、软件错误、人为失误乃至区域灾难等场景下仍能持续提供服务。本文从可用性度量(SLA)出发,系统讲解三大保障场景(本地高可用、业务逻辑保护、容灾多活)、CAP 理论权衡、集群与分布式架构对比,以及 MySQL/Redis/微服务的高可用实战方案。

前置知识

学习目标

  • 理解 SLA 等级与年停机时间的对应关系
  • 掌握高可用三大保障场景及典型技术方案
  • 理解 CAP 理论并能在 CP/AP 间做出权衡
  • 区分集群架构与分布式架构的适用场景
  • 了解 MySQL 主从、Redis Sentinel/Cluster、微服务熔断降级方案

一、可用性度量

1.1 SLA 等级

等级可用性年停机时间典型场景
1 个 990%36.5 天个人博客
2 个 999%3.65 天内部系统
3 个 999.9%8.76 小时Web 服务
4 个 999.99%52.6 分钟企业核心应用
5 个 999.999%5.26 分钟金融系统
6 个 999.9999%31.5 秒核心基础设施

计算公式可用性 = (总时间 - 停机时间) / 总时间 × 100%

1.2 三大保障场景

图表渲染中…

二、本地高可用

2.1 故障类型

层面典型故障
硬件服务器主板/CPU/内存故障、硬盘坏道
网络交换机/路由器故障、网线断裂
存储存储阵列故障、SAN/NAS 故障

特点:恢复快、实施简单、影响范围小。

2.2 典型技术方案

磁盘阵列(RAID)

RAID 级别最少磁盘容量利用率容错能力适用场景
RAID 02100%临时数据/缓存
RAID 1250%允许 1 盘故障系统盘/重要数据
RAID 53(n-1)/n允许 1 盘故障数据库/文件服务
RAID 10450%每组允许 1 盘故障高 I/O 应用

网络冗余:HSRP/VRRP 协议实现路由器主备切换 + LACP 链路聚合。

电源冗余:双电源模块 + UPS(不间断电源)+ 柴油发电机三级保障。

三、业务逻辑保护

3.1 故障类型

类别示例
人为失误误删数据、错误配置、发布错误版本
软件错误OS/数据库/应用/第三方库 Bug
安全事件数据泄露、恶意攻击

特点:需要数据恢复、决策干预、问题追溯。

3.2 典型技术方案

方案核心思想实现要点
数据快照操作前创建还原点定时全量/增量快照,支持一键回滚
审计日志记录所有关键操作操作人/时间/IP/变更内容,持久化存储
灰度发布新版本先小流量验证按用户哈希分流,错误率超阈值自动回滚

3.3 灰度发布核心逻辑

javascript
class CanaryDeployment {
  constructor() {
    this.stable = { version: 'v1.0.0', weight: 90 };
    this.canary = { version: 'v2.0.0', weight: 10 };
  }

  route(userId) {
    const hash = this.hashCode(userId) % 100;
    return hash < this.canary.weight ? this.canary.version : this.stable.version;
  }

  monitor() {
    const errorRate = this.getErrorRate('canary');
    if (errorRate > 0.05) this.rollback(); // 错误率 > 5% 自动回滚
  }

  rollback() {
    this.canary.weight = 0;
    this.stable.weight = 100;
  }
}

四、容灾多活

4.1 容灾等级

等级方案恢复时间数据丢失
Tier 0无异地备份数天~数周全部
Tier 1本地备份异地存储数天1 天
Tier 2异地热备数小时数分钟
Tier 3异地双活数分钟秒级
Tier 4异地多活秒级0

4.2 架构方案对比

方案拓扑恢复时间成本适用
主备主中心 + 备中心(异步复制)数小时中小企业
双活两地同时服务 + 数据同步分钟级大型企业
多活多地同时服务 + GSLB秒级金融/互联网巨头
图表渲染中…

4.3 故障转移核心逻辑

javascript
class MultiDataCenter {
  constructor() {
    this.dcs = {
      beijing:  { status: 'active', weight: 30 },
      shanghai: { status: 'active', weight: 30 },
      guangzhou:{ status: 'active', weight: 40 }
    };
  }

  failover(failedDC) {
    const failedWeight = this.dcs[failedDC].weight;
    this.dcs[failedDC].status = 'failed';
    this.dcs[failedDC].weight = 0;

    const active = Object.keys(this.dcs).filter(k => this.dcs[k].status === 'active');
    const extra = failedWeight / active.length;
    active.forEach(dc => { this.dcs[dc].weight += extra; });
  }
}

五、CAP 理论

5.1 三要素

要素含义
C(Consistency)所有节点同一时间看到的数据一致
A(Availability)每个请求都能在合理时间内得到响应
P(Partition Tolerance)网络分区发生时系统仍能运行

核心结论:分布式系统中 P 不可避免,因此只能在 CP 与 AP 之间选择。

5.2 组合选择

组合特点代表系统
CA强一致 + 高可用,不支持分区MySQL 主从、Oracle RAC
CP强一致 + 分区容错,分区时不可用MongoDB、HBase、ZooKeeper
AP高可用 + 分区容错,数据最终一致Cassandra、DynamoDB、CouchDB

5.3 权衡实践

  • CP 写入:获取分布式锁 → 写入所有节点 → 全部成功才提交 → 任一失败则回滚
  • AP 写入:尝试写入所有节点 → 至少一个成功即返回 → 异步同步到失败节点(最终一致性)

六、集群 vs 分布式

维度集群架构分布式架构
CAPCACP 或 AP
部署多节点部署相同应用多节点部署不同服务
数据一致性强一致最终一致
扩展方式垂直扩展为主水平扩展为主
复杂度相对简单较高
故障影响单节点故障影响小服务间故障可能传播

6.1 技术栈对比

层面集群分布式
负载均衡Nginx / HAProxy / F5Kong / APISIX / Istio
消息队列RabbitMQ / ActiveMQKafka / RocketMQ / Pulsar
缓存Redis 主从 / MemcachedRedis Cluster / Codis
数据库MySQL 主从 / Oracle RACTiDB / OceanBase / CockroachDB
协调服务ZooKeeper / etcd / Consul

七、高可用实战方案

7.1 MySQL 主从复制

图表渲染中…

关键配置:主库开启 log-bin,从库配置 relay-log + read-only=1,监控复制延迟。

7.2 Redis 高可用

方案特点适用场景
Sentinel 哨兵监控 + 自动故障转移数据量适中、高可用需求
Cluster 集群数据分片 + 自动故障转移 + 水平扩展大数据量、高吞吐

Sentinel 核心配置:sentinel monitor mymaster <ip> 6379 2(quorum=2 表示 2 个哨兵同意才执行故障转移)。

7.3 微服务熔断降级

javascript
class CircuitBreaker {
  constructor(threshold = 5, timeout = 60000) {
    this.states = new Map();
    this.threshold = threshold;
    this.timeout = timeout;
  }

  isOpen(service) {
    const s = this.states.get(service);
    if (!s || s.status !== 'open') return false;
    if (Date.now() - s.lastFailure > this.timeout) {
      s.status = 'half-open'; // 半开:允许试探性请求
      return false;
    }
    return true;
  }

  recordFailure(service) {
    const s = this.states.get(service) || { status: 'closed', count: 0 };
    s.count++;
    s.lastFailure = Date.now();
    if (s.count >= this.threshold) s.status = 'open';
    this.states.set(service, s);
  }

  recordSuccess(service) {
    this.states.set(service, { status: 'closed', count: 0 });
  }
}

降级策略

  • 推荐服务 → 返回热门商品兜底
  • 评论服务 → 返回缓存数据
  • 支付服务 → 不可降级,返回"稍后重试"

八、监控与告警

8.1 监控指标分层

层级关键指标
系统层CPU / 内存 / 磁盘 / 网络流量
应用层QPS / 响应时间 / 错误率 / 可用性
数据层连接数 / 查询时间 / 复制延迟 / 磁盘 I/O
中间件层MQ 延迟 / 缓存命中率 / 服务健康状态

8.2 告警策略

指标WarningCritical
CPU> 70% 持续 5min> 90% 持续 1min
错误率> 1% 持续 3min> 5% 持续 1min
可用性< 99.95%< 99.9%

常见问题

问题根因解决方案
单点故障关键组件无冗余集群部署 + 主备切换
数据不一致异步复制延迟同步复制 / 最终一致性补偿
故障转移慢手动干预自动健康检查 + 自动转移
雪崩效应服务级联失败熔断 + 降级 + 限流
数据丢失缺乏异地容灾异地备份 + 实时同步
恢复时间长缺乏预案定期演练 + 自动化恢复

最佳实践

  1. 消除单点:所有关键组件至少双节点部署
  2. 分层防护:硬件冗余 → 数据保护 → 应用多实例 → 容灾多活
  3. 自动化故障转移:Sentinel / K8s 健康检查,减少人工介入
  4. 灰度发布:新版本先 10% 流量验证,异常自动回滚
  5. 定期演练:每季度进行故障注入演练,验证预案有效性
  6. 监控全覆盖:系统/应用/数据/中间件四层指标 + 分级告警

延伸阅读


上一篇: 高性能架构设计 下一篇: 异地容灾与多活架构 — 容灾分层、技术方案、切换流程、演练