Docker无法提供实时CPU保障，但可通过--cpu-shares、--cpus/--cpu-quota和--cpuset-cpus三类参数协同实现强优先+可预期的CPU资源倾斜：先设高权重，再加硬上限防干扰，最后绑定核心降抖动。
docker本身不提供“实时cpu保障”能力，它基于linux cfs（完全公平调度器）实现的是相对权重调度，而非实时操作系统（rtos）级别的硬实时调度。所谓“绝对优先”在docker层面无法真正实现——你不能让一个容器在任何情况下都抢占其他进程的cpu时间片，这是内核调度模型决定的。
但你可以通过组合配置，在高负载竞争场景下最大程度倾斜资源、逼近业务关键性所需的响应确定性。重点不是“实时”，而是“强优先+可预期”。
✅ 明确目标：让核心业务容器在CPU争用时几乎总是先跑、多跑
这靠三类参数协同实现，按优先级和效果排序如下：
-
--cpu-shares：定义相对权重，是基础调度倾斜手段 -
--cpus或--cpu-quota/--cpu-period：设置硬上限，防止被“饿死”或“撑爆” -
--cpuset-cpus：绑定物理核心，减少上下文切换干扰，提升缓存亲和性
? 1. 设置高权重CPU份额（相对调度优先）
docker run -d \ --name core-api \ --cpu-shares 4096 \ # 是默认值1024的4倍，显著提升竞争时占比 nginx:alpine
- 权重范围：2 ~ 262144（推荐用 512 / 1024 / 2048 / 4096 这类2的幂次，便于比例计算）
- 关键理解：若此时有另一个容器
--cpu-shares 1024，理论CPU时间比 ≈ 4:1 —— 但这只在双方同时满载争抢时才体现；空闲时，核心业务仍可跑满所有CPU - 验证是否生效：
docker inspect core-api | grep CpuShares # 应返回 4096
⚙️ 2. 叠加硬性资源保障（防干扰、防超用）
仅靠 --cpu-shares 不防“邻居容器突发打满CPU”，也不防本容器自己写死循环占光资源。需补充：
方式A：限制最大可用CPU核数（推荐，简洁可靠）
docker run -d \ --name core-api \ --cpu-shares 4096 \ --cpus 2.0 \ # 强制最多用2个逻辑核，避免单点过载拖垮整机 nginx:alpine
-
--cpus 2.0等效于--cpu-period=100000 --cpu-quota=200000 - 宿主机即使有32核，该容器也绝不会超过2核算力，稳定可预期
方式B：更精细配额控制（适合混合部署场景）
# 每100ms周期内最多运行70ms → 约0.7核，且保证最低“保底感” docker run -d \ --name core-api \ --cpu-shares 4096 \ --cpu-period 100000 \ --cpu-quota 70000 \ nginx:alpine
- 注意：
--cpu-quota必须 ≥ 1000 微秒，否则报错 - 优势：比
--cpus更细粒度，适合需要“弹性上限+强权重”的SLO分级场景
? 3. 绑定专用CPU核心（降低干扰，提升稳定性）
docker run -d \ --name core-api \ --cpu-shares 4096 \ --cpus 2.0 \ --cpuset-cpus "0-1" \ # 严格限定只跑在CPU 0和1上 nginx:alpine
- 效果：隔离非核心容器（如日志采集、监控代理）的干扰，减少L3缓存污染与上下文切换开销
- 要求：宿主机至少有2个空闲物理/逻辑核，且未被其他关键进程独占
- 配合
taskset或numactl可进一步优化内存访问路径（进阶）
? 实际效果参考（双容器竞争场景）
| 容器名 | --cpu-shares |
--cpus |
--cpuset-cpus |
CPU争用时典型占比 |
|---|---|---|---|---|
core-api |
4096 | 2.0 | "0-1" |
≈ 85%+（主导调度） |
log-collector |
512 | 0.3 | "2" |
≈ 5%~10%（明显压制） |
注：该比例非绝对固定，但权重+配额+绑定三者叠加后，核心业务的CPU延迟抖动（p99 latency）通常可降低40%~60%，在微服务链路中意义显著。
❗重要提醒（常被忽略）
-
--cpu-shares不保证最低CPU，只影响争用时的分配比例 → 所以必须配合--cpus或--cpu-quota设上限，才能反向形成“资源池隔离感” - 所有CPU参数对已运行容器不可热更新，需
docker stop && docker run重建 - 若宿主机启用了
cgroups v2，部分旧版Docker可能需显式启用--cgroup-parent或升级至24.0+版本 - 真正的“实时性”需求（如μs级中断响应、确定性调度延迟）应考虑使用
realtime调度策略（--ulimit rtprio=99+chrt），但这需宿主机开启CONFIG_RT_GROUP_SCHED，且Docker官方不推荐用于常规业务容器
不复杂但容易忽略。
