容量规划、混沌与可观测

• 连接数上限的含义与影响因素
• 连接池参数的合理设置
• 连接数耗尽与过载的应对

数据库连接数上限（max_connections）决定了数据库同时可接受的最大客户端连接数，超出上限的连接会被拒绝或排队。连接数上限受数据库内存（每个连接占用缓冲、线程栈等资源）、CPU 与文件描述符限制，不宜盲目调大。连接池规划遵循“池化复用的连接数远小于高峰并发”的原则：通过连接池复用连接，把活跃连接控制在数据库可承受范围内，同时避免连接数过多导致内存与上下文切换开销。关键参数包括连接池大小、空闲连接超时、最大等待时间等，需结合 QPS 与单连接耗时估算，并预留余量应对突发流量。

连接数上限与连接池是数据库并发控制的第一道闸门。理解“连接是有限资源”与“池化复用”的原理，能回答“为什么不是连接数越多越好”，以及如何通过压测与监控确定合理上限与池大小。

• 复制中断的常见原因
• 中断演练的步骤
• 自动恢复与验证方法

复制中断演练是指在受控环境下人为制造主从复制中断（如停止复制线程、网络抖动、主库故障），验证从库是否快速发现并恢复、主从数据是否一致。演练流程包括：先建立基线，记录复制位点与延迟；再注入中断故障，观察复制状态的告警与检测；随后恢复复制，核对复制位点与数据一致性，验证增补/回放机制是否正常。自动恢复验证则检验复制监控、自动重连与故障切换策略的有效性，确保复制中断不会造成数据丢失或长期延迟。

复制中断演练考验的是“复制链路是否可观测、可恢复、可自愈”。核心是验证监控告警、自动恢复与一致性的闭环，避免故障真实发生时才发现复制已静默中断。

• RTO 的定义
• 切换演练的测量方法
• 切换风险与优化

RTO（Recovery Time Objective）是服务从故障到恢复可用的最大允许时间。主从切换的 RTO 实测需在演练中测量从故障注入到业务恢复可用的时间，包括故障检测、选主、数据追平、应用重连等环节。实测方法：在低峰期注入主库故障，记录故障发生时刻与业务恢复时刻，统计延迟抖动与切换耗时，重复多次取中位数以排除偶然。实测中需关注切换对数据一致性（RPO）的影响、连接中断对应用的影响以及切换后的性能回退。

主从切换 RTO 实测是把“能在多少秒内恢复”从口号变成可量化指标。关注切换链路各环节耗时与一致性，是验证高可用能力的关键。

• 备份策略与恢复目标
• 恢复演练的流程
• 恢复时间（RTO）实测

备份恢复演练是验证备份可用性与恢复能力的关键环节，目标是在规定时间内把数据恢复到可用状态。演练流程：从备份介质恢复数据，按既定恢复步骤还原到指定时间点，校验数据完整性、权限与业务一致性。恢复时间（RTO）实测需记录从启动恢复到对外可用的耗时，包括备份拉取、还原、日志重放、校验等环节。应定期演练并验证恢复到不同时间点（如最近备份点、指定时间点）的可行性，避免“备份存在但恢复不了或恢复太慢”的隐患。

备份恢复演练的核心是“备份必须可恢复、恢复必须够快”。定期演练并实测恢复时间，能发现备份损坏、恢复脚本错误等隐性风险，是数据安全最后一道防线。

• 容量模型的输入指标
• 估算方法
• 容量输出与余量设计

容量模型估算以 QPS、吞吐、数据量、并发数等为主要输入，估算数据库所需的 CPU、内存、磁盘与网络资源。思路是：先确定关键指标（峰值 QPS、平均/峰值吞吐、单查询耗时、数据增长速度），再按单节点能力换算所需节点数，并考虑读写比例、缓存命中率与高峰系数。例如：通过单查询 CPU 消耗与节点 CPU 核数估算可承载 QPS；按数据量×冗余因子×增长速率估算存储容量；按每秒写入字节数估算磁盘负载。容量模型需预留余量（如 30%-50%）并定期复核，随负载变化调整。

容量模型估算是把业务负载翻译成硬件资源的过程，核心是“以指标驱动、以单机能力为基准、留足余量”。理解各指标的换算关系，才能避免容量不足或过度采购。

• Little 定律的公式
• 并发与延迟的关系
• 在连接池建模中的应用

Little 定律（L = λ × W）指出：系统中的平均并发任务数 L 等于平均到达率 λ 乘以平均停留时间 W。在数据库场景中，可用来估算满足一定吞吐所需的连接数或并发数：并发连接数 = QPS × 单请求平均耗时。例如，若 QPS 为 1000、单请求平均耗时 50ms，则平均并发连接数约为 50。该定律帮助连接池与并发参数设计，但也需注意它假设稳态、到达率与耗时稳定，实际存在突发与波动，需结合峰值与余量设计。

Little 定律把并发、吞吐与延迟连接起来，是连接池大小与并发规划的理论基础。核心是“连接数 = 吞吐 × 响应时间”，并认识到稳定态假设需结合实际波动修正。

• 压测工具的参数
• OLTP 场景的建模
• 压测结果解读

sysbench 与 pgbench 是常用的 OLTP 压测工具。设计场景时需配置：并发数、线程数、读写比例、事务结构（如点查、范围查、插入、更新混合）、表大小与数据分布、持续时间与预热。sysbench 的 oltp_read_write 等脚本模拟混合读写事务，pgbench 的 TPC-B 类似场景模拟账户转账等。设计要点是让压测负载贴近真实业务：控制思考时间、数据分布与热点，预热数据库避免缓存冷启动干扰，分梯度加压找出吞吐拐点。结果解读关注 TPS、延迟的 P99/P95、错误率与资源使用率。

压测场景设计的核心是“贴近真实业务 + 控制变量”。理解工具参数含义与负载建模，才能让压测结果有参考价值，避免测试负载与生产脱节。

• TPC-C 的 OLTP 含义
• TPC-H 的 OLAP 含义
• 基准的局限

TPC-C 是模拟 OLTP 事务的基准，以订单、库存、支付等业务为模型，衡量系统在高并发事务下的吞吐能力（tpmC）与性价比；TPC-H 是模拟 OLAP 分析查询的基准，通过一组复杂查询与数据规模衡量系统的大数据量分析性能（QphH）。它们的价值在于提供可横向比较的标准化指标。局限在于：基准负载与真实业务分布差异大，未必反映实际热点、数据倾斜与混合负载；追求 tpmC/QphH 排名可能忽视运维、一致性、可用性等真实需求；且不同厂商的优化手段（如硬件堆叠、参数调优）使结果可比性受限。

TPC 基准是行业标准化的性能标尺，但需清醒认识其负载模型与真实业务的差异。回答要点是“基准提供参考、真实场景需自有压测验证”。

• 思考时间的含义
• 思考时间对吞吐的影响
• 贴近真实负载的建模

思考时间（think time）是用户在两次请求之间的停顿时间，模拟真实用户处理的间隔。压测中加入思考时间会降低实际到达率，更接近真实负载，测出的吞吐与并发更真实；若省略思考时间，压测会形成持续的饱和请求，测出的是系统极限吞吐而非真实使用吞吐。建模时需按真实用户行为设置思考时间分布（通常为负指数或固定值），并结合并发用户数，使压测负载与真实场景匹配。

思考时间是压测负载真实性的关键参数。理解它决定“测系统极限”还是“测真实负载”，从而正确解读压测结果。

• 故障演练的场景
• 注入方式与隔离
• 演练的观察与验证

数据库故障演练需设计主库宕机、网络分区等关键故障场景。设计要点：先确定演练目标（验证高可用、切换、恢复），在小范围/低峰期注入故障，避免影响生产；控制爆炸半径，设置审批与回滚预案。主库宕机演练通过 kill 主进程或模拟崩溃，观察自动选主、切换、恢复与业务连续性；网络分区演练通过隔离节点或断网，验证多数派可用性、脑裂防护与数据一致性。演练后评估 RTO/RPO、故障检测时间与告警有效性，并复盘改进。

故障演练设计核心是“受控、可观测、可回滚”。理解各故障注入手段与验证指标，能提前暴露高可用设计的缺陷。

• 磁盘满/IO hang 的注入
• 数据库的响应与保护
• 验证与恢复

注入磁盘满或 IO hang 可验证数据库在存储异常下的行为。磁盘满时，数据库写入会失败，WAL 无法落盘，事务可能阻塞或回滚，需验证数据库是否优雅报错、是否触发只读保护或告警，避免损坏数据。IO hang 时，读写请求长时间无响应，需观察数据库超时、连接堆积、锁等待与故障转移机制。验证目的是确认数据库能识别存储异常、有限降级、不产生数据损坏，并能在恢复后自愈。演练后用监控指标（延迟、错误率、活跃连接）评估影响并调整容错策略。

存储异常是数据库故障的常见根因，注入磁盘满/IO hang 能验证数据库的容错与降级能力。核心是确认“不损坏数据、及时告警、可靠恢复”。

• 脑裂的产生
• 防护机制
• 验证方法

脑裂（split-brain）指网络分区导致集群出现多个主节点，各自接受写入，造成数据不一致。防护机制包括：基于多数派（quorum）的选举，只有获得多数派投票的节点才能成为主；使用 fencing（如仲裁、租约）淘汰旧主；引入隔离观察者（如 ZooKeeper、仲裁者）打破平局。验证方法是注入网络分区，确认集群只产生一个主节点、旧主被正确隔离、恢复后数据一致，并验证 fencing 机制能否阻止旧主继续写。

脑裂防护是分布式高可用的核心命题，验证重点是“多数派共识 + 旧主隔离”。理解这些机制能回答如何防止双主造成的脏写。

• 稳态指标的定义
• 实验前后的对比
• 指标异常的判定

混沌实验通过注入故障验证系统韧性，稳态指标（steady state）是判断系统是否健康的基准，包括吞吐、延迟（P95/P99）、错误率等。实验前需采集正常状态下的稳态指标作为基线，实验期间持续监测，故障注入后若指标在可接受范围内恢复或未超出容忍阈值，则系统通过；若指标严重恶化且无法恢复，则实验失败。稳态指标设定需结合业务 SLO，如“P99 延迟 < 100ms、错误率 < 0.1%”，并区分瞬时波动与持续恶化。

混沌实验的核心是“有基线、可对比、可判定”。稳态指标把韧性从定性变成定量，是判断故障注入是否突破系统容忍极限的依据。

• 混沌平台的能力
• 故障注入的类型
• 平台与演练的结合

Chaos Mesh 等混沌平台提供故障注入、实验编排与观测能力，可对数据库注入网络延迟、网络分区、进程暂停、磁盘 IO 故障、CPU 压力等故障。数据库演练中，平台支持定义故障注入的时长、范围与目标，自动执行实验并收集指标，还支持通过实验组（experiment）编排复杂场景。结合稳态指标与监控，平台可自动评估系统韧性，并支持在 CI/CD 中作为发布门禁。使用混沌平台能标准化、可重复地开展数据库故障演练，降低人工注入的风险。

混沌平台把故障演练从手工脚本提升为平台化、可编排、可观测的标准实践。理解其故障注入类型与实验编排，是开展自动化韧性验证的关键。

• 峰值与常态的定义
• 区分的意义
• 容量设计的依据

容量规划需区分常态负载与峰值负载：常态负载是平稳期或日常的典型负载，决定系统的平均资源消耗；峰值负载是促销、季末、突发流量等场景下的最高负载，决定系统的瞬时资源上限。二者差异大时，需避免按常态购满导致峰值不足，或按峰值永久购满造成浪费。容量设计上，常态负载决定资源规格，峰值负载决定预留与弹性策略（如云伸缩、降级、限流），并评估峰值持续时间与频率，决定是否用临时扩容还是常驻冗余。

区分峰值与常态是容量规划避免“过配置”与“不足”的关键。核心是“常态定规格、峰值定弹性”，并考虑峰值的频率与时长。

• 容量增长预测方法
• 扩容触发条件
• 扩容节奏控制

存储容量增长预测基于历史使用量、数据增长速度与业务增长率，常用趋势外推（线性/指数拟合）结合业务预期预估未来容量。规划扩容节奏时，需设定容量水位阈值（如使用率达 70%-80% 触发扩容），并考虑扩容耗时（新增节点、数据迁移、rebalance）与磁盘采购周期，预留充足准备时间。扩容节奏应“快于增长、预留缓冲”，避免容量打满后被动扩容；同时结合数据生命周期策略（TTL、归档、压缩）控制增长。

容量预测与扩容节奏是“增长有多快、提前多久扩”的规划问题。核心是设水位阈值、按增长速率预留提前量，并用数据治理控制增长。

• 瓶颈资源的识别
• 拐点的含义
• 压测与监控定位

容量拐点指负载增长到某一临界点后，某项资源（CPU、IO、内存）成为瓶颈，导致性能不再线性提升甚至恶化。识别方法：通过压测分梯度加压，同步监控 CPU、IO 利用率、内存使用与延迟，观察资源利用率拉满而吞吐停滞或延迟急速上升的拐点。典型瓶颈：CPU 打满导致延迟飙升；IO 利用率高导致排队等待；内存不足触发 GC 或颠簸。识别后需针对瓶颈资源扩容或优化（加 CPU、换磁盘、调缓存），并建立监控告警在接近拐点前预警。

容量拐点识别是“资源在哪个点成为瓶颈”的判断。核心是压测加压 + 资源利用率与延迟联动观测，定位最先耗尽的资源并优化。

• 云数据库的弹性能力
• 上限与限制
• 弹性与成本评估

云数据库的容量弹性表现为按需扩缩容、自动水平扩展与存储随用随付。评估弹性时需关注：存储与计算是否可独立伸缩、扩容是否在线、是否受配额与实例规格上限约束。云数据库存在上限（如单实例存储上限、连接数上限、规格档位），弹性扩容受规格档位与配额限制，且扩缩容有时差。评估需结合业务峰值与增长，确认弹性能力能否覆盖需求，并评估弹性成本（按需计费 vs 预留）与扩容耗时，避免“弹性”无法满足瞬时爆发。

云数据库弹性评估的核心是“弹性能力是否覆盖需求、上限在哪里、成本是否可控”。理解配额与规格档位，避免文件弹性而实际受限。

• 基线与趋势对比方法
• 同比/环比/季节性
• 扩容触发阈值设定

容量基线是历史负载的参照基准，通过对比当前负载与基线发现异常或增长趋势。趋势对比含同比（与去年同期）、环比（与上一周期）、季节性（规律性波动，如业务高峰、节假日）三个维度，用于识别自然增长与周期性波动，避免把季节性波动误判为容量问题。扩容触发阈值需结合基线、增长速率与季节性峰值设定，如“P95 利用率超过 75% 且持续 N 分钟”或“预测 xx 天后达到峰值水位”，并区分各资源（CPU/内存/磁盘）的独立阈值。

容量基线对比与阈值设定是“看趋势、定水位”的过程。核心是结合同比/环比/季节性识别真实增长，按趋势与峰值设定有前瞻性的扩容阈值。

• 数据分布差异
• 差异对结果的影响
• 修正方法

压测数据与生产数据在分布上的差异（如数据量、索引分布、热点、倾斜、重复值）会导致压测结果失真。例如：压测数据过少导致索引全部命中缓存、低估了真实 IO；数据倾斜导致某分区/节点过载 vs 压测均匀分布。修正方法：按生产数据规模与分布生成压测数据、构造与生产一致的索引与统计信息、模拟热点与倾斜、使用真实抽样数据脱敏后压测，并分析数据分布对执行计划的影响。

压测数据分布决定压测结果是否可信。核心是“数据像生产、分布像生产”，否则测得的是理想化而非真实性能。

• 统计显著性的含义
• 多次测量与取中位
• 波动与公差

基准测试受环境波动（缓存、GC、调度、网络）影响，单次测量不可靠，需多次测量保证统计显著性。多次测量取中位数（而非平均值）能抵御极端值干扰，因为平均值易被偶发尖峰拉高，中位数更稳健地反映典型性能。同时应控制变量（相同硬件、预热、固定负载），报告 P95/P99 与方差，多次运行取稳定结果，并确保样本量足够使差异具有统计意义，避免把噪声当性能差异。

统计显著性保证“测出的差异是真实而非噪声”。核心是多次测量、取中位数、控制变量、报告分位数。

• 压测写负载对复制的影响
• 从库延迟的来源
• 压测设计的考量

压测产生的写负载会传导到复制链路：主库写入加快，从库需同步回放，若从库回放能力不足或主库压力过大，会产生复制延迟（lag）。压测中若并发写远超从库处理能力，从库延迟会持续累积，影响读写分离场景下读的新鲜度。设计压测时需关注：压测写入是否会让从库延迟超阈值、是否需增加从库资源或调整复制策略、压测是否会造成从库与主库性能差异。合理的压测应同时监测主从复制延迟，评估高写入下的复制健壮性。

压测不仅要测主库能力，还要看复制链路能否跟上。核心是“高写入下复制延迟是否可控”，否则读写分离会读到旧数据。

• 故障注入与压测结合
• 验证目标
• 综合评估

混沌压测是把故障注入与高负载压测结合，在系统承压的同时注入故障，验证系统在“负载+故障”双重压力下的韧性。开展方式：先施加持续压测使系统处于高负载，再注入故障（如节点宕机、网络分区、磁盘异常），观察系统在高负载下能否正确降级、切换、限流并恢复。验证目标包括：故障切换是否影响业务、高负载下故障检测是否延迟、恢复后吞吐是否回弹。综合评估稳态指标、故障隔离效果与恢复能力，找出单点与韧性短板。

混沌压测模拟“最坏情况”下的系统表现，比单独压测或单独故障注入更接近真实风险。核心是“压测暴露容量、故障暴露韧性、二者叠加验证极限”。

• 压测指标的可视化
• 瓶颈定位方法
• 结果分析

压测结果可视化通过图表展示吞吐、延迟（平均值/P95/P99）、错误率、资源利用率（CPU/内存/IO/网络）随时间的变化，帮助把整体性能与资源使用关联起来。瓶颈定位方法：从延迟分解（客户端、网络、数据库、磁盘）+ 资源利用率 + 慢查询分析入手，识别最先耗尽的资源、延迟拐点与锁等待。通过对比不同并发/不同段的曲线，定位吞吐停滞、延迟骤升的拐点对应的瓶颈资源，并据此提出优化方向。

可视化与瓶颈定位是“把压测数据变成可执行结论”的过程。核心是关联吞吐-延迟-资源，定位瓶颈资源与拐点。

• 演练结果的反馈
• 容量修正
• SLO 的调整

演练（压测、故障演练、容量验证）后，需根据实测结果修正容量规划与 SLO。容量修正：若实测容量低于预期，调整资源规格或扩容计划；若余量不足，更新容量模型与扩容阈值。SLO 修正：若演练发现延迟/可用性无法达到承诺的 SLO，需调整 SLO 目标或通过优化提升能力；若实测优于承诺，可适当收紧或维持。修正过程需记录演练数据、更新基线，把教训沉淀到容量模型与 SLO 定义中，形成“演练-测量-修正”的闭环。

演练的目的是反哺改进，容量与 SLO 修正让演练结果真正落地。核心是“实测驱动修正、闭环持续改进”。

• 爆炸半径控制
• 审批流程
• 自动熔断机制

故障演练的爆炸半径控制是确保演练不影响生产的关键，包括：限定演练范围（单节点、单实例、非核心业务）、控制故障强度与时长、在低峰期进行、设置回滚预案。审批流程上，演练需经评审，明确影响面、风险与负责人，重大演练需审批通过并公示。自动熔断机制是演练安全阀：当演练引发的指标（延迟、错误率、活跃连接）超出预设阈值时，自动终止演练并恢复，防止故障失控扩散。落地时需把熔断阈值与监控打通，实现演练的自动保护。

爆炸半径控制、审批与熔断是“演练可控”的三重保障。核心是让演练在可控范围内进行，异常时自动止损。

• 告警有效性的含义
• 混沌实验触发告警
• 验证告警链路

混沌实验可验证告警系统是否有效：注入故障后，检查是否触发预期告警、告警是否及时（延迟）、告警信息是否准确（告警对象与级别）。验证内容包括：告警检测链路（监控采集、阈值判断、通知路由）是否完整、告警是否可被真实故障触发、以及是否存在“静默故障”（无告警但服务已异常）。通过混沌实验可发现告警缺失、阈值不当、通知不达等问题，从而完善告警规则与监控覆盖。

告警有效性验证是“故障可知”的保障。混沌实验主动制造故障，检验告警是否及时、准确、不遗漏，避免“故障发生却无人知”。

• 演练问题的识别
• 容量改进
• 架构改进

演练结果反哺是韧性建设的闭环：通过演练暴露的问题（容量不足、单点故障、切换失败、恢复过慢）被记录并分级，推动容量与架构改进。容量改进：针对演练发现的容量拐点与瓶颈，调整资源规格、扩容计划与容量模型。架构改进：针对演练发现的架构缺陷（如单点、无冗余、脑裂风险、备份不可恢复），重构高可用架构、补充冗余与隔离、优化故障处理。改进需有明确的优先级、负责人与验证闭环，让每次演练都沉淀为系统韧性的提升。

演练的价值在于把发现的问题转化为改进。核心是“演练-识别问题-改进-再验证”的持续闭环，让韧性不断提升。

• MTTR 的含义
• MTTR 的度量
• 改进手段

MTTR（Mean Time To Repair，平均修复时间）是衡量系统从故障发生到恢复可用所需平均时间的韧性指标，反映故障恢复能力。度量方法：统计每次故障的检测时间、定位时间、修复时间与验证时间，取平均值。改进手段：缩短故障检测（完善监控与告警）、提高自动切换与自动恢复能力、沉淀故障预案与 runbook、优化切换与回滚流程、通过演练验证改进效果。MTTR 越低，系统韧性越强，但需兼顾测量口径统一与故障分类。

MTTR 是从故障到恢复的时间度量，是韧性量化指标。改进核心是“快检测、快定位、快恢复、多演练”。

• 韧性文化的内涵
• 常态化演练机制
• 文化建设内容

数据库韧性文化指把韧性建设内化为团队日常实践，常态化演练是核心：把演练从“出了问题做一次”变为定期、自动、可重复的执行。建设内容：制定演练计划与频率（定期 + 随机）、建立演练责任人机制、把演练接入 CI/CD 作为发布门禁、沉淀演练平台与编排、指标化评估韧性（通过率、MTTR）、鼓励演练发现问题并修复。文化上强调“主动暴露问题优于被动承受故障”，让韧性成为团队共识与考核的一部分。

韧性文化是“主动演练、持续改进”的组织保障。核心是把演练制度化、常态化、平台化，让韧性成为团队习惯而非一次性行动。

• 混沌实验作为门禁
• 实验通过率设定
• 失败处理与回滚

混沌实验可作为发布门禁：在版本发布前，对新版本自动执行一组混沌实验（如故障注入、韧性验证），以实验通过率作为准入标准，只有通过率达标才允许发布，防止带有韧性退化的版本上线。通过率按实验集合中通过的实验占比计算，设定阈值（如 100% 或 95%）。失败处理与回滚：实验不通过时，发布被阻断，需定位退化点、修复或回滚到上一版本，并将失败实验记录为回归用例，避免同类问题复发。

混沌实验作为发布门禁把韧性验证嵌入交付流程。核心是“以通过率守护发布、失败即阻断并回滚”，防止韧性退化上线。