Docker CPU配置本质是组合--cpu-shares（争用时相对权重，默认1024）、--cpu-period与--cpu-quota（硬性时间上限，如100ms周期内限50ms），分层协作实现精细化负载均衡。
在 Docker 中配置 CPU 周期与份额，本质是组合使用 --cpu-period、--cpu-quota 和 --cpu-shares 三个参数，分别实现“硬性时间限制”和“软性调度权重”。它们不是互斥的，而是分层协作：份额决定争用时的相对比例，周期+配额则划定绝对上限。真正实现精细化负载均衡，关键在于理解各自作用域并按需搭配。
CPU份额（--cpu-shares）：控制争用时的调度优先级
CPU 份额是一个相对权重值，默认 1024，合法范围是 2–262144。它不设上限，只在多个容器同时抢 CPU 时起作用——比如两个容器份额为 2048 和 1024，当宿主机 CPU 满载，前者会获得约两倍于后者的运行时间。
- 空闲时，所有容器都能用满 CPU，份额无约束力
- 仅在同一台宿主机内有效，无法跨节点比较
- 适合区分服务等级：核心 API（2048）、后台任务（512）、日志采集（256）
CPU周期与配额（--cpu-period + --cpu-quota）：设定硬性使用上限
这对参数模拟“虚拟 CPU 核心”，通过 Linux CFS 的 cpu.cfs_quota_us / cpu.cfs_period_us 实现。默认周期是 100000 微秒（100ms），配额为 -1（不限制）。若设为 --cpu-period=100000 --cpu-quota=30000，表示该容器每 100ms 最多运行 30ms，即稳定占用 30% 的单核算力。
- 配额 ÷ 周期 = 实际 CPU 使用率（如 50000/100000 = 0.5 → 半核）
- 周期可调小（如 50000），但通常保持默认更稳定；配额必须 ≥ 1000 才有实际意义
- 适用于需要严格控速的场景：定时脚本、ETL 任务、避免突发计算拖垮服务
如何协同配置达成负载均衡效果
单独用份额只能“分蛋糕”，单独用配额容易“一刀切”。真实生产中建议组合：
- 对关键服务：设高份额（2048）+ 合理配额（如 --cpus=1.2），既保优先又防过载
- 对批量任务：设低份额（512）+ 明确配额（--cpu-quota=20000 --cpu-period=100000），限制其最多占 20% 算力且不抢资源
- 验证是否生效：运行后执行
docker inspect 容器名 | grep -E "(CpuShares|CpuPeriod|CpuQuota)" - 注意：若同时设了
--cpus=1.5，Docker 会自动换算为等效的 period+quota（如 150000/100000），此时再手动设 quota 可能被覆盖
常见误区与避坑提醒
很多团队误以为设了 --cpu-shares 就能限频，结果压测时发现容器仍跑满 CPU——这是因为没发生资源争用，份额根本不触发。同样，只设 --cpu-quota 不调 --cpu-period，可能因默认周期过大导致响应毛刺。
- 份额不是限制，只是“投票权”；配额才是“天花板”
- 周期值太小（如 10000）可能导致调度抖动，一般不建议修改默认 100000
- 容器内看到的 CPU 使用率（如 top）反映的是宿主机视角的占比，不是容器独占核数
- 在 Kubernetes 中，这些参数对应
resources.limits.cpu（配额逻辑）和resources.requests.cpu（份额逻辑的近似体现）
