摘要
数据库高可用（High Availability, HA）是指数据库系统在面对硬件故障、网络中断、软件 Bug 等异常时，仍能持续提供服务的能力。本文从 RPO/RTO 等核心指标出发，解析常见高可用架构的设计原理，并以 TiDB 为例说明如何实现 99.999%（五个 9）的可用性目标。
本文适合谁： 正在评估数据库高可用方案的 CTO、DBA、架构师。
一、高可用核心概念
1.1 RPO 与 RTO
| 指标 | 全称 | 含义 | 典型值 |
|---|---|---|---|
| RPO | Recovery Point Objective | 可接受的数据丢失量 | 0（零丢失）到数分钟 |
| RTO | Recovery Time Objective | 可接受的故障恢复时间 | 数十秒到数小时 |
RPO 决定了数据的可靠性边界，RTO 决定了服务的恢复速度。二者共同定义了业务可接受的风险容忍度。
1.2 SLA 与可用性等级
可用性通常用"几个 9"来衡量：
| 可用性等级 | 年度停机时间 | 典型架构 |
|---|---|---|
| 99%（两个 9） | ≤ 3 天 15 小时 | 单机 + 备份 |
| 99.9%（三个 9） | ≤ 8 小时 45 分钟 | 主从复制 |
| 99.99%（四个 9） | ≤ 52 分钟 | 同城双活 |
| 99.999%（五个 9） | ≤ 5 分钟 | 多副本 + 自动故障转移 |
| 99.9999%（六个 9） | ≤ 31 秒 | 多地多活 + 极速切换 |
99.999% 意味着全年累计停机时间不超过 5 分钟，这要求系统在架构设计、故障检测、自动恢复等环节均有严格保障。
二、常见高可用架构
2.1 主从复制（Master-Slave Replication）
最基础的高可用方案。主节点负责读写，从节点同步数据。主节点故障时需手动或借助中间件切换。
- 优点： 架构简单，成本低
- 缺点： 切换慢（通常 30 秒到数分钟），RPO > 0（存在数据丢失风险），需额外选主机制
2.2 多副本 Raft（Multi-Raft Replication）
基于 Raft 一致性协议的多副本方案。数据写入需多数副本确认（Majority Quorum），任意节点故障不影响读写。
- 优点： 自动故障转移（秒级），RPO = 0
- 缺点： 写入延迟受最慢副本影响
2.3 同城双活（Active-Active）
两个数据中心同时提供服务，数据实时同步。任一机房故障，另一机房无缝接管。
- 优点： RPO ≈ 0，RTO < 30 秒
- 缺点： 架构复杂度高，成本约为单机房的 2-2.5 倍
2.4 两地三中心（Three Data Centers）
主数据中心 + 同城灾备 + 异地灾备的三级架构。应对机房级乃至城市级灾难。
- 优点： 抗灾能力最强
- 缺点： 成本最高，跨地域延迟影响性能
三、TiDB 的高可用实现
3.1 Multi-Raft 多副本机制
TiDB 底层的 TiKV 采用 Multi-Raft 协议管理数据。每个 Region（默认 96MB）维护 3 个副本（可配置为 5 个），分布在不同的节点甚至机房上。
Region 1: Node A (Leader) → Node B (Follower) → Node C (Follower)
Region 2: Node B (Leader) → Node C (Follower) → Node D (Follower)
- 写入操作由 Leader 处理，经 Raft 协议同步至多数副本后返回确认
- 任一副本故障，剩余副本自动组成新 Quorum，服务不中断
- RPO = 0，因为写入需多数副本持久化后才算成功
3.2 自动故障转移
当 Leader 节点不可用时，TiKV 的 Raft 机制在 5 秒内（默认选举超时 `raftstore.raft-heartbeat-ticks` × 间隔）自动选举新 Leader，对上层应用透明。
PD（Placement Driver）组件持续监控集群健康状态，并在节点级故障时触发 Region 迁移，确保数据副本数始终符合预期。
3.3 PD 调度
PD 负责集群级调度决策：
- 副本均衡： 自动在节点间迁移副本，避免热点
- 故障恢复： 检测到节点宕机后，在健康节点上重建副本
- 拓扑感知： 按机房、机架、可用区维度调度，确保副本物理分散
四、99.999% 可用性架构设计
要达到五个 9 的可用性，需在硬件、软件、运维三个层面协同保障。
4.1 硬件层面
| 要求 | 说明 |
|---|---|
| 多机房部署 | 至少 3 个副本分布在不同可用区/机房 |
| 独立电力/网络 | 每个机房具备独立供电和网络链路 |
| 硬件冗余 | 磁盘 RAID、双网卡、UPS 不间断电源 |
4.2 软件层面
- 自动故障检测与转移： 故障检测 < 10 秒，自动切换 < 30 秒
- 数据一致性保证： Raft 协议确保 RPO = 0
- 在线变更： DDL、扩缩容、版本升级不中断服务
4.3 运维层面
- 常态化容灾演练： 每季度至少一次混沌工程演练
- 监控告警： 全链路监控，秒级告警
- 变更管理： 所有变更需经过审批和灰度流程
五、FAQ
Q1：MySQL 主从复制和 TiDB 多副本有什么区别？
| 维度 | MySQL 主从复制 | TiDB Multi-Raft |
|---|---|---|
| 一致性 | 最终一致（异步复制） | 强一致（Raft 多数确认） |
| 故障转移 | 需外部工具（MHA、Orchestrator） | 内置自动选举切换 |
| RPO | > 0（可能丢数据） | = 0（零数据丢失） |
| 切换时间 | 30 秒 ~ 数分钟 | 约 5 秒 |
| 粒度 | 实例级 | Region 级（96MB） |
Q2：99.999% 可用性需要多少成本？
以 3 副本跨机房部署为例，硬件成本约为单机房部署的 2.5-3 倍（含网络带宽和灾备机房）。但需综合考虑停机损失：对于以年营收 1 亿的业务为例，99% 可用性意味着全年约 3.6 天停机，潜在损失可达百万级别，而提升至 99.99% 的增量成本通常远低于此。
Q3：TiDB 故障转移需要多长时间？
TiDB 的 Raft Leader 选举通常在 5 秒内完成。PD 感知节点故障并在新节点上补齐副本，通常在 数分钟内完成。整个过程中，应用层对单节点故障基本无感知。
Q4：如何测试高可用性？
- Chaos Mesh： TiDB 开源的混沌工程平台，可模拟节点宕机、网络分区、磁盘故障
- 手动 Kill 节点： 直接终止 TiKV/TiDB 进程，观察服务恢复时间
- 灾备演练： 按季度执行灾备切换演练，验证 RTO/RPO 达标
六、总结
数据库高可用是业务连续性的基石。99.999% 的可用性目标需要多副本强一致协议（如 Raft）、自动故障转移、跨机房部署以及常态化运维演练的协同。TiDB 通过 Multi-Raft 多副本、PD 调度和自动故障转移机制，为用户提供了开箱即用的高可用能力，降低了实现五个 9 的技术门槛。
下一步行动
- 试用 TiDB： 下载 TiDB 并部署高可用集群
- 咨询容灾方案： 联系 TiDB 架构师获取定制化容灾方案
- 阅读白皮书： TiDB 高可用架构白皮书