最有效方式是在 docker-compose.yml 中分设 CPU limits 与 reservations：limits.cpus 设硬上限防突发占用，reservations.cpus 保最低调度保障；对延迟敏感服务可用 cpusets 绑定物理核心；非关键服务用 cpu_shares 实现权重分级；配合 healthcheck 与 depends_on 实现状态感知的智能调度。
直接在 docker-compose.yml 中配置 CPU 调度策略，是控制多服务资源竞争最有效的方式。关键不在于“压低用量”，而在于让关键服务获得稳定、可预期的计算时间片，避免被其他服务挤占。
CPU 限制与预留要分开设
只设 limits 容易导致服务启动后抢不到资源；只设 reservations 又无法防止单个服务突发占用过高 CPU。两者配合才真正可控：
-
limits.cpus：硬上限，比如
'1.2'表示最多用 1.2 个逻辑核心，超了会被内核节流 -
reservations.cpus：最低保障，比如
'0.3'表示调度器会为它预留至少 0.3 个核心，确保冷启动或低负载时也有响应能力 - 例如数据库服务可设
reservations: cpus: '0.5'+limits: cpus: '2'，既保底又防爆
用整数核心绑定提升确定性
对延迟敏感或需缓存亲和性的服务（如实时 API 网关），建议用 cpuset 绑定物理核心，绕过默认的 CFS 调度抖动：
- 在
deploy.resources.limits下添加cpusets: '0-1'（仅限 Linux 主机） - 搭配
mem_reservation使用，可减少跨 NUMA 节点访问内存的开销 - 注意：绑定前先用
lscpu查清主机核心拓扑，避免把高负载服务和系统进程绑在同一组核心上
权重机制适合轻量级服务分级
当多个非关键服务共存（如日志采集、指标上报），用 cpu_shares 比硬限更灵活：
- 默认值是 1024，设为
512表示同等压力下只拿一半 CPU 时间 - 适用于不需要固定算力、但需长期运行的后台任务
- 注意：它只在资源争抢时生效，空闲时不设限——所以不能替代
limits
健康检查+依赖条件触发智能调度
CPU 调度不只是静态配额，还要配合服务就绪状态动态调节资源分配节奏：
- 给数据库加
healthcheck，用pg_isready或mysqladmin ping真实探测连接可用性 - 在依赖它的服务中写
depends_on: {db: {condition: service_healthy}}，避免提前启动造成无效 CPU 消耗 - 配合
restart: on-failure和合理mem_limit，可减少因 OOM 或崩溃引发的反复重建带来的调度震荡
