Module 04 TiDB 高可用技术
本章节从故障根源、底层 Raft 容错机制到同城 / 异地多中心部署方案完整讲解，核心目标是理解 TiDB 原生高可用底层逻辑、掌握不同业务等级对应的容灾架构、量化 RPO/RTO 指标。
一、模块整体定位
- 底层原理层：拆解 TiDB 依靠 Multi-Raft、etcd 实现组件自动故障转移、数据多副本容错，解决硬件 / 软件故障停机问题；
- 架构落地层：提供同城三中心、同城双中心、两地三中心、异步多集群复制 4 套主流生产容灾架构，对比延迟、成本、数据丢失风险；
二、Lesson14 TiDB 数据库高可用概述
1. 系统不可用两类场景
1.1. 计划外系统不可用（突发故障类）
属于非预期突发故障，会直接造成业务中断，细分 4 大类诱因：
| 故障类型 | 具体诱因 |
|---|---|
| 软件故障 | 操作系统、数据库内核、中间件、业务应用程序自身缺陷 BUG |
| 硬件故障 | CPU 故障、内存损坏、磁盘坏道、网络链路中断、机房供电异常 |
| 人为错误 | 业务侧用户误操作、运维 DBA 删库 / 改参数等高风险误操作 |
| 灾害事故 | 火灾、洪水、地震、大范围停电等机房级灾难性事件 |
1.2. 计划内系统不可用（可控运维类）
提前排期、可窗口管控的运维操作，可通过方案规避业务中断：
- 日常运维操作：数据备份、性能调优、账号权限与安全管控、大批量数据批处理任务；
- 定期维护动作：底层存储巡检维护、集群参数初始化配置、系统安全补丁升级、数据表 Schema 变更管理；
- 新部署与迭代升级：硬件设备换代、操作系统升级、TiDB 数据库版本升级、中间件 / 业务应用迭代上线。
2. TiDB 针对性高可用解决方案
2.1. 系统硬件 / 底层故障容灾方案
- 节点级自动容错：TiKV 依托 Multi-Raft 协议、PD 依托底层 etcd 集群机制，单节点 / 单磁盘故障自动完成 Leader 切换、副本补齐，故障节点不影响整体集群可用性；
- 数据故障兜底恢复：使用 BR 工具完成全量 + 增量备份，出现误删数据、磁盘损毁等数据故障时，快速基于备份集恢复数据，保障数据可找回。
2.2. 计划内系统变更保障方案
针对升级、改参数、Schema 变更等运维操作，TiDB 原生能力规避停机：
- 滚动升级：TiDB/PD/TiKV 组件分批滚动迭代，升级过程集群持续对外提供服务；
- 在线补丁：支持不停机在线推送漏洞补丁，无需整机重启；
- Online DDL：原生在线表结构变更，变更过程不锁表、不阻塞业务读写；
- 动态参数修改：绝大多数集群参数支持在线动态生效，无需重启组件；
- Failover 故障自动转移：节点异常自动切换副本 Leader，规避单节点故障引发局部业务不可用。
2.3. 数据同步与一致性保障方案
- TiCDC：实现 TiDB 集群间异地同步、下游异构数据库同步，用于异地灾备、数据分流；
- TiDB Binlog：兼容传统 Binlog 生态，同步增量变更数据，搭配备份链路实现多副本数据兜底，保障数据一致性与可追溯恢复能力。
3. 年度可用性等级与对应年故障时长对照表
| 可用性等级 | 年度允许故障时长 | 通俗定位 |
|---|---|---|
| 99% | 3 天 15 小时 36 分（87.6 小时） | 基础可用级别，中小业务常规标准 |
| 99.9% | 8 小时 46 分（8.77 小时） | 企业业务通用高可用标准 |
| 99.99% | 52 分 34 秒（52.57 分钟） | 核心业务、互联网业务主流标准 |
| 99.999% | 5 分 15 秒（5.25 分钟） | 金融核心、支付类严苛业务标准 |
| 99.9999% | 32 秒（0.53 分钟） | 顶级金融、央企核心系统极致标准 |
可用性基础规则
- 可用性统计口径：可对外正常提供服务时长 / 全年总时长；
- 不可用时长久定义：从故障发生时刻，到业务完全恢复正常服务的完整耗时。
4. 两大核心灾备指标：RTO 与 RPO
4.1. RTO（恢复时间目标）
- 全称：Recovery Time Objective
- 核心定义：业务可容忍的最长停机时长，代表故障后业务恢复服务的速度上限；
- 业务价值：RTO 数值越小，故障后业务恢复越快，业务中断营收、体验损失越小；
- TiDB 落地：依托 Multi-Raft 自动选主能力，单节点故障 RTO 可达秒级，同城三中心架构 RTO 可控制在分钟级。
4.2. RPO（恢复点目标）
- 全称：Recovery Point Objective
- 核心定义：业务可容忍的最大数据丢失时长，代表故障回溯能找回最近数据的时间点；
- 业务价值：RPO=0 代表故障无任何数据丢失，是金融核心业务硬性要求；异步复制架构天然存在 RPO>0 的数据丢失窗口；
- TiDB 落地：同城三中心、同城两中心同步复制模式可实现 RPO=0；TiCDC 异步跨城灾备 RPO 由同步延迟决定。
5. Raft 基础协议核心机制
5.1. Leader 选举规则
- 生效条件：节点获得集群半数以上投票即可成为 Leader；
- 故障处理：集群检测到节点宕机、网络分区后，自动触发新一轮选举，保障服务接管。
5.2. 日志复制机制
Leader 接收业务写入请求，将操作日志同步至集群半数以上节点后，日志正式提交生效，依靠多数节点落地实现基础数据可靠性。
5.3. Leader 合法性约束
仅持有集群最新完整日志的节点可参与竞选 Leader，防止老旧日志节点上位引发数据回滚、分布式一致性错乱。
6. Multi-Raft 分布式优化设计
TiDB 将全量数据拆分为海量独立 Region，每个 Region 独立组建一套 Raft Group：
- 隔离性：单个 Region 故障仅影响分片自身，不会全局波及集群；
- 性能优化：分散单 Raft Group 的 Leader 性能瓶颈，适配分布式海量存储横向扩展；
- 调度灵活：PD 可独立调度每个 Region 的 Leader 位置、副本分布，实现负载均衡与容灾调度。
7. TiDB 四大核心组件高可用特性
7. 1. TiKV 存储组件
- 核心能力：Region 副本采用三副本部署，只要集群内副本多数派节点存活，即可自动完成 Region Leader 切换与数据恢复；写入数据强制复制至大多数节点，天然保障分布式数据强一致性。
- 运维价值：单 TiKV 节点、单磁盘故障无需人工介入，PD 自动调度副本补齐、Leader 迁移，实现自愈。
7. 2. PD 调度组件
- 底层依托：内嵌 etcd 集群实现标准 Raft Leader 选举，保障 PD 集群自身高可用；
- 核心功能：全局分配严格单调递增的 TSO 事务时间戳，支撑 TiDB 分布式事务 MVCC 实现，PD Leader 故障后自动切换，全局时钟持续稳定输出。
7. 3. TiDB Server 计算接入组件
- 架构属性：无状态服务，支持横向随时扩容、缩容节点；组件自身不内置故障自动 Failover 能力；
- 配套方案：依靠前端负载均衡、业务接入网关实现故障节点流量自动摘除、请求转发，达成接入层高可用。
7. 4. TiDB 整体强一致策略
- 核心原则：优先保障数据强一致性，当集群无法满足强一致条件时直接拒绝写入请求，不妥协产出脏数据；
- 故障处理：故障排查解决前，集群伴随合理服务降级（限流、只读等），杜绝数据错乱风险。
三、Lesson15 TiDB 数据库常用高可用架构
1. 架构设计核心前置考量点
1.1. 网络延迟约束
-
Raft 基础规则：三副本架构写入必须同步复制至至少 2 个节点，跨区域部署会叠加跨机房网络耗时；
-
读写链路额外开销：
- 读请求需向 PD 获取 1 次 TSO 时间戳；
- 事务场景需要 2 次 TSO 申请，跨区域部署会放大延迟；
-
跨区 Leader 问题：若 Region Leader 与前端 TiDB Server 不在同一区域，每次读写都会产生跨区网络往返延迟。
1.2. Raft 协议部署硬性规范
- 副本数量优先选择奇数（标准 3 副本），避免选举平票导致选主阻塞；
- 副本物理分布必须和 TiKV 节点机房、机架部署匹配，打散副本规避机房级故障批量损坏副本。
2. 四大主流高可用架构对比
| 架构类型 | 核心特点 | 现存问题 | RPO/RTO 指标 |
|---|---|---|---|
| 同城三中心 | 3 个同城机房分布副本， 同城网络延迟低，天然多活架构 | 多副本跨机房同步， 整体写入、读取延迟小幅抬升 | RPO=0， RTO 较小（分钟级） |
| 同城两中心 | 主中心 + 灾备中心， 支持同步 / 异步两种复制模式 | 异步复制模式存在数据丢失风险 | 同步模式：RPO=0； 异步模式 RPO>0 |
| 两地三中心 | 任意单个中心故障， 集群服务不中断、数据无丢失 | 同时损毁两个 中心则集群不可用； 跨城专线部署与运维成本高昂 | RPO 由复制模式决定， 同步架构 RPO=0 |
| 异步复制 | 上下游集群各自独立高可用， 用于跨城异地灾备、数据多集群分发 | 异步链路存在同步延迟， 故障会丢失延迟窗口内数据； 恢复后依赖校验保证数据一致性 | RPO≠0（等于链路同步延迟时长） |
3. 各架构适用业务场景
3.1. 同城三中心
适用：金融核心、支付交易等强监管、要求 RPO=0 的同城核心业务； 优化：就近调度 Region Leader 与 TiDB Server 同机房部署，降低跨区读写延迟。
3.2. 同城两中心
适用：中型企业同城灾备业务，预算有限场景； 选型建议：核心交易业务必须使用同步复制保障 RPO=0，非核心后台业务可选用异步复制控制成本。
3.3. 两地三中心
适用：头部政企、银行核心系统，需要抵御单城市机房故障风险； 风险管控：做好双中心同时故障应急预案，提前演练降级切换方案，评估专线冗余与成本投入。
3.4. 异步跨城复制架构
适用：异地数据灾备、多业务集群数据同步、下游数仓同步场景； 管控要点：监控 TiCDC 同步延迟，设置延迟告警阈值，明确可容忍 RPO 时长上限，定期演练灾备切换与数据校验流程。