🏠后端系统容灾与高可用设计指南
type
status
date
slug
summary
tags
category
icon
password
Status
 
1. 引言
在现代互联网服务中，后端系统的稳定性和连续性至关重要。任何核心组件的故障都可能导致服务中断、用户体验下降甚至数据丢失。本指南旨在系统性地阐述针对常见后端依赖（如 Redis 缓存、数据库）以及基础设施（如数据中心）故障场景下的高可用（High Availability, HA）与容灾（Disaster Recovery, DR）设计策略。
  • 高可用 (HA): 旨在通过冗余和自动故障转移，最大限度地减少单个组件故障导致的服务中断时间，确保系统在绝大部分时间内可用。通常关注单个数据中心内的快速恢复。
  • 容灾 (DR): 旨在应对更大范围的灾难性事件（如机房断电、自然灾害），确保在主要数据中心不可用时，业务能够在备用地点恢复，并控制数据丢失量。关注的是跨地域的恢复能力。
2. Redis 故障应对策略 (缓存/会话等场景)
Redis 通常用作高性能缓存、分布式会话存储、分布式锁、消息队列等。其故障主要影响性能和部分依赖功能。
2.1 故障影响
  • 缓存失效： 缓存命中率骤降，大量请求穿透到后端数据库，DB 压力增大，系统响应变慢。
  • 功能受限： 依赖 Redis 的会话管理、分布式锁、排行榜、消息队列等功能可能暂时不可用。
2.2 高可用策略 (HA)
核心思想是提供 Redis 服务的冗余实例和自动切换能力。
  • 2.2.1 Redis 主从复制 (Master-Replica):
    • 机制: 数据从 Master 节点异步或半同步复制到一个或多个 Replica 节点。
    • 优点: 结构简单，实现读写分离（读请求可发往 Replica）。
    • 缺点: Master 故障后，需要手动或依赖外部工具将 Replica 提升为新 Master，存在切换时间窗口和潜在的数据丢失（异步复制）。
  • 2.2.2 Redis 哨兵模式 (Sentinel):
    • 机制: 在主从复制基础上引入独立的 Sentinel 进程集群，负责监控 Redis 节点状态。
    • 功能:
      • 监控 (Monitoring): 持续检查 Master 和 Replica 是否正常工作。
      • 通知 (Notification): 当节点出现问题时通知管理员或其他程序。
      • 自动故障转移 (Automatic Failover): 当 Master 故障时，Sentinel 集群会自动选举一个 Replica 提升为新的 Master，并通知其他 Replica 和客户端。
    • 优点: 实现自动化的故障发现和转移，提高了可用性。
    • 缺点: 配置相对复杂，Sentinel 集群自身也需要保证高可用。
  • 2.2.3 Redis 集群模式 (Cluster):
    • 机制: Redis 官方提供的分布式解决方案。数据通过哈希槽 (hash slot) 自动分片存储在多个 Master 节点上，每个 Master 可以有自己的 Replica。
    • 优点: 去中心化架构，天然支持水平扩展和高可用。部分 Master 节点故障，仅影响其负责的数据分片，集群仍可对外服务。节点间通过 Gossip 协议交换状态信息。
    • 缺点: 对客户端协议有要求（需要支持 Cluster 模式），运维相对更复杂。
2.3 应用层容错策略
即使 Redis 集群本身高可用，应用层面也应具备容错能力。
  • 2.3.1 客户端连接管理:
    • 使用健壮的 Redis 客户端库，支持连接池、连接超时、自动重试（针对网络抖动）。
    • 客户端需能感知 Sentinel 或 Cluster 的拓扑变化，自动连接到正确的 Master 或节点。
  • 2.3.2 优雅降级 (Graceful Degradation):
    • 当应用检测到无法连接 Redis 或访问超时时，应能跳过缓存逻辑，直接访问数据库或其他后备数据源。
    • 目的: 保证核心功能的可用性，即使性能暂时下降。例如，读请求直接查库，写请求在更新库后尝试删除缓存（失败也可接受）。
  • 2.3.3 断路器模式 (Circuit Breaker):
    • 如果 Redis 持续不可用，客户端可以触发断路器，在一段时间内（冷却期）直接执行降级逻辑，避免不断尝试连接失败的 Redis 实例，减少资源浪费和请求延迟。
2.4 监控与告警
  • 实时监控 Redis 实例/集群的存活状态、内存使用率、连接数、命令延迟、主从同步延迟、缓存命中率等关键指标。
  • 配置告警规则，在指标异常或节点故障时及时通知运维人员。
3. 数据库 (DB) 故障应对策略
数据库是系统状态的核心载体，其故障通常导致核心业务中断。
3.1 故障影响
  • 读写失败： 应用无法读取或写入关键业务数据。
  • 核心业务中断： 用户登录、交易、内容发布等依赖数据库的操作完全失败。
  • 数据丢失风险： 若主库故障且数据未及时同步到备库或备份。
3.2 高可用策略 (HA)
核心思想是提供数据库服务的冗余副本和快速、可靠的故障切换机制。
  • 3.2.1 数据库主从/主备复制 (Master-Replica/Standby):
    • 机制: 最常见的高可用方案。写操作在主库，更改通过 Binlog (MySQL)、WAL (PostgreSQL) 等机制复制到一个或多个从库/备库。
    • 读写分离: 可将读流量分发到从库，提升读性能和扩展性。
    • 故障转移 (Failover):
      • 手动切换: DBA 手动将从库提升为新主库。
      • 自动切换: 使用 MHA (MySQL)、Keepalived+VIP、Patroni/Repmgr (PostgreSQL) 或云服务商提供的 RDS HA 功能（如 AWS RDS Multi-AZ）实现自动检测主库故障并切换。切换过程需处理好数据一致性（如确保新主库应用了所有已提交的事务）。
    • 复制模式:
      • 异步复制: 性能最好，但主库宕机可能丢失最近未同步的事务 (RPO > 0)。
      • 同步复制: 保证数据不丢失 (RPO = 0)，但主库写入需等待至少一个从库确认，性能较低。
      • 半同步复制: 折衷方案，主库等待至少一个从库确认后才返回成功，可在性能和数据一致性间取得平衡。
  • 3.2.2 共享存储集群 (如 Oracle RAC):
    • 多个数据库实例共享同一份存储，实例间通过高速网络同步状态。单个实例故障不影响服务。适用于特定数据库和场景，成本较高。
  • 3.2.3 分布式数据库 (如 TiDB, CockroachDB, YugabyteDB):
    • 架构设计层面就内置了多副本、数据自动分片、一致性协议 (Raft/Paxos) 和自动故障转移能力。单个节点甚至部分副本故障，集群通常仍能正常服务，提供更高的可用性和扩展性。
3.3 应用层容错策略
  • 3.3.1 数据库连接池: 健康检查、坏连接驱逐、自动重试逻辑。
  • 3.3.2 读写分离中间件/代理: 透明地路由读写请求，感知后端主从切换。
  • 3.3.3 优雅降级/只读模式: 当写库不可用但读库可用时，应用可降级为只读状态，保留部分查询功能。
  • 3.3.4 请求缓冲与重试: 对于写入操作，在遇到数据库暂时不可用时，可将请求暂存（如内存、本地文件、消息队列），稍后重试。需注意重试的幂等性设计。
  • 3.3.5 异步处理: 对于非核心或可延迟的写操作，通过消息队列异步写入数据库，提高系统韧性。
3.4 数据备份与恢复 (DR 基础)
虽然不是实时 HA，但备份是数据安全的最后防线。
  • 定期备份: 制定合理的备份策略（全量、增量、差异）。
  • 备份验证: 确保备份文件的可用性和完整性。
  • 异地/跨区域存储备份: 防范机房级灾难。
  • 恢复计划与演练: 制定详细的恢复流程，并定期进行恢复演练，验证 RTO (Recovery Time Objective) 和 RPO。
3.5 监控与告警
  • 监控数据库实例状态、主从同步延迟、连接数、慢查询、磁盘 IO/空间、CPU/内存使用率等。
  • 配置关键指标告警。
4. 机房/区域级灾难应对策略 (DR)
指单个数据中心或整个云服务区域因自然灾害、大面积断电/断网等原因完全不可用。
4.1 故障影响
  • 部署在该区域内的所有服务（应用、数据库、缓存、消息队列等）全部中断。
  • 若无异地容灾，业务完全瘫痪，可能面临长时间中断和大量数据丢失。
4.2 容灾策略 (DR)
核心思想是在地理位置分散的地方建立备用系统，并在主站点灾难时将业务切换过去。
  • 4.2.1 多可用区部署 (Multi-AZ Deployment):
    • 概念: 在同一个云区域 (Region) 内，将系统部署到多个物理隔离的可用区 (Availability Zone, AZ)。AZ 之间有低延迟、高带宽的网络连接，但拥有独立的电力、冷却和网络。
    • 实现:
      • 数据库使用 Multi-AZ 配置（如 RDS Multi-AZ），自动同步备库到另一 AZ。
      • 应用服务器实例分布在多个 AZ，通过区域负载均衡器分发流量。
      • 缓存、消息队列等中间件也进行跨 AZ 部署。
    • 优点: 能抵御单个 AZ 级别的故障（如机房断电、网络设备故障），自动切换通常较快 (RTO 低)，成本相对可控，网络延迟低。
    • 缺点: 无法抵御影响整个区域的灾难。
  • 4.2.2 多区域部署 (Multi-Region Deployment):
    • 概念: 将系统的完整副本或关键业务能力部署到地理位置分散的不同区域 (Region)。这是最高级别的容灾。
    • 实现:
      • 数据跨区域复制: 配置数据库、对象存储等的跨区域异步复制。
      • 全局流量管理 (GSLB / DNS Failover): 使用 AWS Route 53, Cloudflare 等服务，基于健康检查进行 DNS 记录的自动或手动切换，将用户流量引导到健康的区域。
      • 应用与基础设施部署: 在备用区域部署完整的应用栈，最好使用 IaC (Infrastructure as Code) 实现自动化和一致性。
      • 配置同步: 确保两地配置的一致性。
    • 模式:
      • 冷备 (Cold Standby): 备用区域资源平时不运行或只运行最小资源，灾难时手动启动和恢复数据。RTO 长。
      • 温备 (Warm Standby): 备用区域运行核心服务和数据同步，但不承载实时流量，灾难时启动其余服务并切换流量。RTO 中等。
      • 热备/双活/多活 (Hot Standby / Active-Active / Multi-Site Active): 两个或多个区域同时运行并处理实时流量（可能按地理位置或负载分配）。切换最快 (RTO 低)，但架构最复杂，成本最高，需解决跨区域数据一致性难题。
    • 优点: 能抵御区域级灾难。
    • 缺点: 成本高昂，架构复杂，跨区域数据同步存在延迟 (RPO 可能较大)，切换流程复杂。
  • 4.2.3 备份与恢复 (作为 DR 的基础): 即使没有实时备用站点，也必须有异地备份，能够在灾难后重建系统，尽管 RTO 会很长。
4.3 关键支撑技术
  • 数据同步技术: 数据库复制、存储复制、消息队列跨地域同步方案。
  • 流量调度技术: GSLB、智能 DNS、Anycast IP。
  • 自动化部署与配置管理: IaC (Terraform, CloudFormation), 配置管理 (Ansible, Chef, Puppet), CI/CD 管道。
4.4 容灾预案与演练 (DR Plan & Drills)
  • 制定详细的 DR Plan: 包括故障场景、触发条件、切换流程、回切流程、各团队职责、联系人、预期 RTO/RPO。
  • 定期进行容灾演练: 从桌面推演到模拟切换，甚至真实流量切换，验证预案的可行性、时效性，发现问题并持续改进。没有演练的容灾预案几乎等于没有预案。
5. 跨领域的设计原则
  • 冗余是基础: 关键组件和数据必须有副本。
  • 自动化是关键: 尽可能自动化故障检测和切换，减少人为错误和响应时间。
  • 监控预警先行: 完善的监控体系能提前发现潜在风险。
  • 分层防御: 在基础设施、中间件、应用等多个层面都考虑容错。
  • 测试与演练验证: 定期进行故障模拟和容灾演练。
  • 成本与收益平衡: 根据业务价值和风险评估，选择合适的可用性/容灾级别。
广告事件聚合系统设计笔记Go 传参和返回值是通过 FP+offset 实现
Loading...