6.2 高可用与扩展性

6.2 高可用与扩展性

本节摘要：DataHub 是低流量、高价值系统，它的可用性压力不在并发洪峰，而在"组织的信任不能断"。本节给出扩容决策的顺序与判据——无状态层堆副本、存储层按负载特征分别对待、事件链路看积压——并展开三个最常见的运行事件：索引重建、消息积压、主库瓶颈的完整处理流程。读完你应当能独立制定平台的容量与可用性预案。本节承接 6.1 的部署拓扑，每个动作都标注了对应的架构依据。

扩容决策：先问哪层在喊

收到性能问题，按三层顺序诊断，别上来就加机器。第一层无状态服务：前端与 GMS 的负载特征是请求延迟上升、副本 CPU 飙高——处理方式最简单，加副本。它们无状态，扩容没有副作用。GMS 的特殊之处在于它身后是主库：GMS 副本加多了，连接数把主库打满，反而更慢——GMS 扩容前先看主库连接水位，这是新手最常撞的墙。第二层事件链路：表现为"数据迟到"而非"系统变慢"——搜索滞后、血缘不全，系统本身响应正常。处理方向是扩索引消费者与查队列积压，而不是动服务层。第三层存储：查询变慢且加服务副本无效，才轮到存储扩容——主库升配或读写分离、索引加节点、图库升配。三层判据一句话：慢在服务看 CPU，慢在数据看积压，都正常还慢才动存储。

把判据整理成一张速查表，值班时直接对号：

这张表的最后一列与第一列同样重要——扩容动作做错方向时，不仅解决不了问题，还会把故障面扩大一层。

事件一：索引重建

索引重建是 DataHub 运维的家常便饭，触发场景包括：搜索索引结构升级、索引数据损坏、灾难恢复、大批量元数据修正后主动重建。理解重建的前提是 2.1 的结论：索引与图库都是主库的派生视图，重建是恢复视图，不是数据事故——这个认知让重建可以平静地安排与执行。

重建的标准流程四步。第一步，评估窗口：重建耗时与实体总量线性相关，数十万实体量级通常以小时计，安排在业务低峰。第二步，切换保护：重建期间搜索结果不完整，如果组织已把目录嵌入流程（5.5 的成果），要提前公告"重建期间搜索结果不全"。第三步，执行重建：触发从主库到索引的全量导灌任务，监控其进度与错误计数。第四步，验证恢复：抽查核心表能否搜到、字段描述是否完整、血缘图是否恢复，验证通过才算关单。

一个运行细节值得注意：重建任务与日常增量消费并行时，注意任务限速，别让全量灌入把消费者打满、日常增量事件排队——否则重建完的那一刻，积压的增量事件又要追半天。

事件二：消息积压

积压的定义与症状在 2.3 已经建立：变更日志发布后，消费者没能在合理时间内消化。积压本身不是病，持续的积压增长才是。处理流程分三步。

第一步定位积压位置：队列里堆积的是未投递消息还是未确认消息？前者说明消费者处理能力不足或消费者副本数不够；后者通常是消费者反复处理失败卡在同一条毒消息上。第二步处理毒消息：消费者失败重试进入循环时，先隔离问题消息（跳过并记录），让链路恢复流动，再离线分析这条消息为什么处理不了——绝大多数毒消息来自非标准写入（某个自研连接器的畸形提案），修复源头后重放。隔离毒消息的前提是知道卡在哪条：按消费者组的主题与分区定位到反复重试的偏移量，把该条消息的内容完整导出存档，再跳过偏移。存档这步不能省——它是事后修复源头的全部线索，也是重放的原料。第三步容量收尾：若积压根因是能力不足（比如一次十万个实体的批量摄入灌进来），短期扩消费者副本，长期把超大摄入任务限速或分批——摄入端的礼貌是对平台最好的保护。

积压的监控接入在 6.4 展开，这里给出阈值经验：积压深度持续增长超过半小时即告警，秒级到分钟级的波动是正常呼吸，不值得惊动任何人。

事件三：主库瓶颈

主库是唯一不可重建的存储，它的瓶颈处理要最谨慎。瓶颈信号：GMS 响应变慢而自身资源空闲、主库 CPU 与 IO 高、连接数逼近上限。处理选项按代价从低到高排列。

低代价选项：连接治理。摄入执行器与 GMS 的连接池配置往往偏激进，收紧执行器侧的并发与连接上限，主库水位立竿见影。多数"主库扛不住"的初期案例，真相是连接配置问题而非容量问题。中代价选项：读写分离。查询大头是详情页读取，把只读流量分到从库，主库专注写入。改动在 GMS 配置层完成，注意分流的延迟容忍——详情页对秒级延迟不敏感，天然适合读从库。高代价选项：升配与分库。升配直接有效；实体分片是最后的手段，它改变数据的组织方式，牵动所有派生视图的重建策略，不到实体量级真正逼近天花板不要考虑。

💡 主库扩容的决策依据不是今天的负载，而是增长曲线的斜率。每月容量巡检（6.4）里主库的实体量与写入速率两条曲线，是提前一个季度预见瓶颈的信号灯。

一个季度的容灾演练脚本

备份演练别停在"应该做"，给它一个固定脚本。每季度挑一个上午，按下面的动作走一遍，两小时内完成。

第一小时做恢复：从最近一次主库备份在临时环境拉起一套最小平台（只起 GMS 与主库），导入后抽查二十个实体的字段完整性、随机抽五条血缘看边是否在——注意验证的是"这份备份能撑起一个能用的平台"，而不只是"备份文件存在"。第二小时做决策：把恢复耗时、数据时点与生产环境的差距记录成页，讨论两个问题——真实灾难时的业务降级预案（6.2 开头那段话术）是否需要更新、备份周期是否需要加密。演练记录归档进运维手册，四次演练之后，这套流程会从"演练"沉淀为"已验证的恢复能力"。

演练的价值在第一次之后就会显现：几乎每个团队第一次演练都会发现"备份是全的，但恢复步骤文档缺了一半"或者"备份周期比想象的长"。这些问题在演练里暴露是彩排，在真灾难里暴露是事故。

可用性的两个非技术保障

技术之外，两个组织机制决定可用性的成色。备份演练：主库备份每天做不难，难的是每季度做一次真实的恢复演练——从备份拉起一套临时环境，验证数据完整性与服务可用性。没演练过的备份，在灾难来临时给你的只有心理安慰。降级预案：平台不可用期间的应对话术提前写好——"地图在修，血缘影响分析走离线导出加人工确认"。有预案的停机是事故，没预案的停机是信任危机。

本节的每个动作都标了架构依据，这不是学究气——运维动作能否做对，取决于对“谁权威、谁派生”的印象是否牢靠。动作清单可以抄，判断力要回第 2 章去养。

本节要点回顾

• 三层判据：慢在服务看 CPU 加副本，慢在数据看积压扩消费者，都正常才动存储。
• GMS 扩容前看主库连接水位，盲目加副本会打满连接适得其反。
• 索引重建是恢复派生视图，四步流程加限速并行使；重建窗口要向流程使用者公告。
• 积压三步：定位堆积类型、隔离毒消息恢复流动、容量收尾限速超大摄入。
• 主库三档：连接治理、读写分离、升配分库，从便宜到昂贵按序上；备份必须配演练。

稳定性的功课做完了，下一节补安全的门锁：接入账号怎么认证、界面账号怎么管理、策略授权怎么设计。