Docker CPU份额机制基于CFS实现相对权重调度，仅在资源争用时按比例分配CPU时间，默认值1024，合法范围2–262144；空闲时不生效，不保证最低性能，也不限制最大使用量。
Docker本身不支持真正的“实时”CPU调度（如Linux的SCHED_FIFO或SCHED_RR），它基于CFS（Completely Fair Scheduler）做公平、权重制的CPU时间分配，而非硬实时保障。所谓“CPU实时份额分配策略”，实际是指在多容器竞争场景下，通过CPU shares机制实现可预期、有优先级的相对资源倾斜。关键不是“实时性”，而是“可预测的相对权重控制”。
CPU份额（cpu-shares）的本质作用
- 是一个相对权重值，影响CFS调度器中进程的
vruntime增长速度 - 仅在CPU资源紧张（争用）时生效；空闲时所有容器都能跑满可用CPU
- 默认值为1024，合法范围是2–262144（新版Docker支持上限提升）
- 不限制最大CPU使用量，也不保证最低性能
如何配置CPU份额策略
✅ 使用 --cpu-shares 设置启动时权重
# 高优先级服务（如API网关）：获得2倍于默认容器的CPU时间 docker run -d --name api-gateway --cpu-shares 2048 nginx # 普通服务（如前端静态服务）：保持默认权重 docker run -d --name frontend nginx # 后台任务（如日志清理）：降低权重，避免抢占主服务资源 docker run -d --name log-cleaner --cpu-shares 256 alpine sh -c "while :; do find /var/log -mmin +60 -delete; sleep 3600; done"
⚠️ 注意：份额只在同一批运行中的容器之间比较有效。若只有1个容器在跑，设成262144也无意义。
✅ 验证配置是否生效
# 查看容器实际设置的shares值 docker inspect api-gateway | grep CpuShares # 进入容器对应cgroup路径（需宿主机权限） cat /sys/fs/cgroup/cpu/docker/<container-id>/cpu.shares</container-id>
输出应为 2048，说明已写入底层cgroup。
✅ 多容器共存时的份额比例计算逻辑
假设三容器同时高负载运行：
-
api-gateway:--cpu-shares 2048 -
frontend:--cpu-shares 1024（默认） -
log-cleaner:--cpu-shares 256
总份额 = 2048 + 1024 + 256 = 3328
则理论CPU时间占比约为：
- api-gateway：2048 / 3328 ≈ 61.5%
- frontend：1024 / 3328 ≈ 30.8%
- log-cleaner：256 / 3328 ≈ 7.7%
这个比例会在内核CFS调度中动态体现，无需额外干预。
⚠️ 常见误区与避坑提醒
-
不要混用
--cpu-shares和--cpus/--cpu-quota做同一目标：前者是软权重，后者是硬限制，目标不同 -
份额值不是“核数”：设
--cpu-shares 2048≠ 绑定2个CPU核心 -
不能跨主机比较：份额只在单机cgroup层级起作用，K8s中需配合
requests/limits使用 - 低份额容器可能被饿死：若关键服务设为256而其他全设1024+，在持续满载下响应会明显延迟
✅ 进阶建议：结合其他参数增强可控性
| 场景 | 推荐组合 | 说明 |
|---|---|---|
| 防止单容器吃光CPU |
--cpus=0.8 或 --cpu-quota=80000 --cpu-period=100000
|
硬性限频，适合批处理或非关键服务 |
| 绑定特定物理核减少干扰 | --cpuset-cpus="0-1" |
适用于低延迟服务（如金融行情推送） |
| 混合部署时分层保障 |
--cpu-shares 2048（核心服务） + --cpu-shares 512（边缘服务） |
构建QoS分级体系 |
不复杂但容易忽略。
