3. 资源争抢现象与影响：争抢的表现形式、对性能与稳定性的影响、典型场景分析
3.1 资源争抢的核心表现形式
在多租户数据中心中，资源争抢并非单一维度的“CPU 满了”或“内存不够了”，而是多个资源维度上租户负载相互挤压、相互干扰的系统性现象。从底层硬件到上层调度，争抢通常表现为以下四种典型形式：
- CPU 时间片争抢：多个虚拟机或容器共享物理核时，Hypervisor 或 CFS 调度器按权重分配时间片。当某个租户的突发计算任务占满可运行队列时，其他租户的 vCPU 会出现明显的等待延迟，表现为
steal指标升高（在 Linux 中可通过top或vmstat观察）。 - 内存带宽与 LLC（最后一级缓存）争抢：即使物理内存容量充足，内存控制器带宽和 LLC 容量仍是共享资源。一个跑着大数据分析或内存数据库的租户，会大量冲刷 LLC，导致相邻租户的缓存命中率骤降，访问延迟成倍增加。
- 存储 I/O 争抢：在分布式存储或本地 NVMe 盘上，不同租户的随机读写请求在队列深度上相互竞争。当某个租户发起高并发小 I/O 时，存储控制器队列被占满，其他租户的 I/O 延迟从毫秒级飙升至百毫秒级，甚至触发超时。
- 网络带宽与队列争抢：在虚拟交换机（vSwitch）或物理 NIC 队列层面，突发流量会占满环形缓冲区，导致其他租户出现丢包、TCP 重传和窗口收缩。尤其在开启
RSS（接收端缩放）但未做流隔离时，多租户流量会哈希到同一队列，形成队头阻塞。
关键识别信号：当租户业务出现“间歇性变慢”且时间点与邻居租户的批处理任务高度重合时，应优先怀疑资源争抢而非自身代码问题。通过监控 steal、iowait、cache-misses、netdev dropped 等指标，可以快速定位争抢维度。
3.2 争抢对性能与稳定性的影响机制
资源争抢的影响并非均匀扩散，而是沿着“延迟敏感型业务 → 吞吐型业务 → 基础设施稳定性”的链条逐级传导。具体影响体现在以下三个层面：
| 影响层面 | 典型表现 | 量化指标 | 业务后果 |
|---|---|---|---|
| CPU 争抢 | vCPU 等待调度，线程饥饿 | steal > 10%，runqueue 深度 > 4 | 请求处理变慢，线程池耗尽 |
| 内存/缓存争抢 | LLC 命中率下降，内存延迟上升 | cache-misses 率 > 20%，内存延迟 > 150ns | 数据库查询变慢，缓存失效风暴 |
| 存储 I/O 争抢 | I/O 排队，磁盘利用率饱和 | iowait > 30%，avgqu-sz > 8 | 日志写入阻塞，事务提交超时 |
| 网络争抢 | 丢包、重传、TCP 拥塞窗口收缩 | 重传率 > 2%，丢包率 > 0.1% | 跨节点调用延迟飙升，分布式事务失败 |
更严重的是，争抢会引发“性能雪崩”正反馈循环：当某个租户因争抢而变慢后，其内部重试机制会加大请求量，进一步加剧争抢；同时，健康检查超时可能导致负载均衡器将流量转移到其他实例，造成争抢的“漂移”和扩散。
3.3 典型场景深度分析
场景一：离线任务与在线业务混部
某互联网公司为提升资源利用率，将离线 Spark 任务与在线推荐服务混部在同一批物理机上。初期运行平稳，但在每日 22:00 的模型训练高峰期，在线服务 P99 延迟从 80ms 飙升至 2.3s。通过监控发现：
# 争抢期间物理机监控数据
CPU steal: 22.7% # 离线任务抢占大量 CPU 时间片
LLC miss rate: 41.3% # 离线任务数据扫描冲刷缓存
内存带宽利用率: 87% # 接近 DDR4 理论带宽上限
在线服务 P99: 2.3s # 正常时段为 80ms根因是离线任务使用了 cgroup 的默认权重，未限制其对 LLC 和内存带宽的占用。通过为离线任务设置 cpu.cfs_quota_us 上限，并启用 Intel RDT（资源目录技术）中的 MBA（内存带宽分配）和 CAT（缓存分配技术），将离线任务的内存带宽限制在 30%，LLC 占用限制在 20% 后，在线服务 P99 恢复至 95ms。
场景二：存储噪声邻居
某金融云平台上，一个租户的日志采集服务（大量顺序写）与另一个租户的 MySQL 数据库（随机读写）共享同一组 NVMe 盘。日志服务的高并发写入占满了存储控制器队列，导致 MySQL 的 fsync 延迟从 2ms 增加到 180ms，主从复制延迟持续升高。
隔离手段：为该场景配置存储 QoS 时，不能只限制 IOPS，还要限制带宽和队列深度。建议使用 blkio 的 throttle 组，同时设置 read_iops、write_iops 和 read_bps、write_bps 双重限制，避免单一维度限制失效。
场景三：网络突发流量冲击
一个多租户 Kubernetes 集群中，某租户的数据同步任务（使用 Kafka MirrorMaker）在整点启动，瞬间产生 5Gbps 的突发流量。由于 vSwitch 的队列是共享的，其他租户的 Web 服务出现大量 TCP 重传，导致 API 网关 5xx 错误率从 0.1% 上升到 4.8%。
排查时发现，物理 NIC 的 tc 队列规则未按租户隔离，所有流量都进入同一个 htb 类。通过配置基于 cgroup 或 iptables 标记的流量分类，为不同租户分配独立的带宽上限和优先级队列，问题得到解决。
3.4 常见误区与复盘要点
误区一：只看 CPU 使用率，忽略 steal 和 load average。 CPU 使用率 100% 并不一定代表争抢，可能是业务自身瓶颈；而 steal 指标升高才是虚拟机被物理机其他租户抢占的直接证据。排查时应同时观察 top 中的 %st 列和 vmstat 的 r（运行队列）值。
误区二：认为内存容量充足就不会争抢。 内存容量充足不代表内存带宽充足。在 NUMA 架构下，跨 NUMA 节点的内存访问会争抢 QPI/UPI 总线带宽，即使本地内存未用满，远端内存访问也可能成为瓶颈。
误区三：将所有性能问题都归因于资源争抢。 需要先排除自身代码问题（如慢 SQL、锁竞争、Full GC），再考虑争抢因素。建议建立“基线对比法”：在低峰期运行同样的压测，对比高峰期与低峰期的性能差异，差异部分才可能是争抢所致。
复盘要点：每次处理完争抢问题后，应记录争抢发生的资源维度、触发条件、影响范围、隔离手段和恢复时间。建议形成标准化的争抢诊断清单，包含：物理机/宿主机监控数据（steal、cache-misses、iowait、网络重传）、邻居租户的活动窗口、隔离策略的生效状态、以及业务侧的 P99/P95 延迟变化曲线。只有将诊断过程标准化，才能在下次争抢发生时快速定位并处置。