📚 课程目录第3章资源争抢现象

资源争抢现象：常见表现、影响评估与监控指标

在多租户环境中，资源争抢并非偶发的“卡顿”或“变慢”，而是一种由共享资源池的分配机制、租户负载特征和调度策略共同决定的系统性现象。理解其常见表现、影响评估方法和监控指标，是后续进行根因定位与隔离方案设计的基础。本节将围绕这三个层面展开，帮助读者建立从“感知异常”到“量化判断”再到“持续观测”的完整认知链路。

3.1 常见表现：从用户感知到系统日志的四个层次

资源争抢的表现具有“层层传导”的特征。最早被感知的往往是业务层，而最根本的诱因通常隐藏在基础设施层。下表归纳了四个典型层次的表现特征及其典型场景：

层次	典型表现	示例场景
业务层	接口响应时间（RT）上升、超时率增加、交易失败	促销租户的批量任务导致另一租户的下单接口 P99 延迟从 80ms 飙升至 2s
应用层	线程池队列积压、连接池获取等待、CPU 自旋增加	共享 Tomcat 线程池被日志刷屏租户占满，正常租户请求排队
数据库层	锁等待时间变长、缓冲池命中率下降、慢查询增多	某租户全表扫描占用大量 Buffer Pool，导致其他租户的索引查询被迫换页
基础设施层	CPU steal 时间升高、磁盘 IOPS 饱和、网络重传率上升	宿主机上 CPU 密集型租户导致同物理机其他虚拟机 steal 超过 30%

值得注意的是，资源争抢的表现往往具有“非线性”特征。当资源利用率低于某个阈值（例如 CPU 低于 70%）时，争抢影响不明显；一旦超过临界点，延迟会呈指数级恶化。这种“悬崖式”劣化使得问题难以通过简单的阈值告警提前发现。

判断要点：如果应用层指标（如 RT、错误率）异常，但数据库和中间件指标正常，应优先排查 CPU steal 和宿主机层面的争抢；反之，如果数据库锁等待和 IO 延迟同时升高，则更可能是存储或锁资源争抢。

3.2 影响评估：从“是否受影响”到“影响面多大”

评估资源争抢的影响，不能只看单一指标，而需要建立多维度的评估框架。核心思路是区分“受害租户”与“肇事租户”，并量化两者的损失与收益。

影响评估应遵循以下四个步骤：

界定影响范围：通过租户 ID 或业务标签，筛选出受影响的服务实例、数据库分片或存储卷。确认是单个租户、部分租户还是所有租户均受影响。
量化性能退化程度：对比争抢时段与基线时段的 P50/P99 延迟、吞吐量（QPS/TPS）、错误率。计算退化比例，例如“P99 延迟上升 15 倍”或“吞吐量下降 40%”。
评估业务损失：将技术指标转化为业务语言。例如，支付类租户的延迟增加可能导致订单超时赔付；数据分析租户的任务执行时间延长可能影响 SLA 承诺。
识别肇事租户特征：分析争抢期间资源消耗最高的租户，判断其负载类型（CPU 密集、IO 密集、内存密集）和触发原因（定时任务、突发流量、数据倾斜）。

以下是一个典型的影响评估案例：某金融云平台在业务高峰时段，租户 A（核心交易系统）的 P99 延迟从 50ms 恶化至 800ms，而租户 B（日志分析）的 CPU 使用率持续接近 100%。通过监控发现，租户 B 正在执行大规模数据扫描任务，占用了宿主机 60% 的 CPU 资源，同时大量读取磁盘导致 IO 队列深度超过 200。评估结论为：租户 B 的批量任务属于“非关键型”负载，但其资源消耗对租户 A 的“关键型”交易链路造成了严重冲击。

常见误区：仅关注“肇事租户”的资源利用率，而忽略“受害租户”的延迟敏感度。例如，即使肇事租户只占 30% CPU，但如果受害租户的延迟要求极高（如毫秒级），仍然可能造成不可接受的业务影响。评估时应同时考虑资源消耗的绝对值和租户的 SLA 敏感度。

3.3 监控指标：构建“资源-调度-体验”三层指标体系

有效的监控体系应覆盖从物理资源到用户感知的完整链路。建议按照以下三层结构设计指标，并建立指标之间的关联分析能力。

3.3.1 资源层指标：发现争抢的“物理证据”

CPU Steal（%steal）：虚拟机/容器等待宿主机 CPU 调度的时间占比。该指标是识别 CPU 争抢最直接的信号，超过 10% 即需要关注。
磁盘 IOPS 与吞吐量：对比磁盘的额定能力与实际使用量。当 IOPS 接近上限且延迟上升时，可能存在 IO 争抢。
网络重传率与丢包率：物理网卡或虚拟交换机的拥塞会导致重传增加，影响租户间通信质量。
内存回收与 Swap：当宿主机内存不足时，会发生内存回收甚至 Swap，导致应用线程阻塞。

3.3.2 调度层指标：观察资源分配的“公平性”

调度等待时间：任务在队列中等待被调度的时间，反映 CPU 或 IO 调度器的拥塞程度。
时间片抢占次数：CFS 调度器中，高优先级任务抢占低优先级任务的次数。
锁等待时间与死锁检测：数据库层面的行锁、表锁等待时间，以及分布式锁的获取超时次数。

3.3.3 体验层指标：量化租户的实际感受

端到端延迟（P50/P95/P99）：按租户维度统计请求延迟分布，是判断争抢是否影响用户体验的最终依据。
错误率与重试率：超时、连接拒绝、5xx 错误的比例。
SLA 达成率：租户请求在约定时间内完成的比例，直接反映业务承诺是否被破坏。

以下是一个用于快速定位争抢的监控查询示例（PromQL 风格）：

# 1. 查找 CPU steal 超过 10% 的宿主机
avg by (host) (rate(node_cpu_steal_seconds_total[5m])) > 0.1

# 2. 按租户维度统计容器 CPU 使用率，找出 Top 5 肇事者
topk(5, sum by (tenant_id) (rate(container_cpu_usage_seconds_total[5m])))

# 3. 关联查询：受害租户的 P99 延迟与宿主机的 steal 时间
histogram_quantile(0.99, sum by (le, tenant_id) (rate(http_request_duration_seconds_bucket{tenant_id="tenant_A"}[5m])))

  监控策略建议：不要孤立地设置静态阈值，而应建立“基线动态对比”机制。例如，将当前 15 分钟的 P99 延迟与过去 7 天同一时段的 P99 延迟进行对比，当偏差超过 3 倍标准差时触发告警。这种方式能有效过滤业务自身波动带来的误报，聚焦于真正的资源争抢事件。

3.4 误区与复盘：资源争抢判断中的常见陷阱

在实际运维中，对资源争抢的误判往往比争抢本身更危险。以下是三类高频误区：

误区一：将“资源使用率高”等同于“资源争抢”。高利用率可能是租户自身负载的正常表现，只要调度延迟和体验指标未受影响，就不构成争抢。争抢的本质是“资源分配不均导致部分租户的服务质量受损”。
误区二：只关注 CPU 而忽略 IO 与内存带宽。现代多租户环境中，磁盘 IO 和内存带宽的争抢往往比 CPU 更隐蔽。例如，NVMe 磁盘在并发读写时的延迟抖动可能达到数十毫秒，而 CPU 指标却表现正常。
误区三：忽略“吵闹邻居”的周期性特征。许多争抢由定时任务（如每日凌晨的数据备份、报表计算）触发。如果监控周期过短（如仅观察 5 分钟），可能无法捕捉到完整的争抢过程，导致根因定位失败。

复盘案例：某 SaaS 平台曾出现间歇性租户访问变慢，初步排查发现数据库 CPU 利用率仅 40%，网络流量也不高。后通过深入排查发现，问题根源在于共享存储阵列上，另一个租户的每日快照任务占用了大量存储控制器缓存，导致该租户的随机读延迟从 1ms 飙升至 20ms。由于存储层的争抢不会直接体现在计算节点的 CPU 或网络指标上，只有同时监控存储延迟和控制器队列深度才能发现。这一案例说明，监控指标的覆盖广度直接决定了根因定位的效率。

上图展示了资源争抢从基础设施到用户体验的完整传导链路。监控系统需要同时覆盖四个层次，并将各层指标进行关联分析。例如，当体验层 P99 延迟升高时，应逐层向下排查：应用层线程池是否排队？调度层锁等待是否增加？基础设施层 CPU steal 或 IO 延迟是否异常？只有建立这种“自上而下”的排查路径，才能快速锁定争抢发生的具体位置。