1. 原理与体系结构：为什么在 Linux 实现多用户资源隔离需要 cgroups
在现代 Linux 系统中，多用户资源隔离的核心技术就是 cgroups（控制组）。它通过将一组进程聚合到一个独立的“资源域”来实现对 CPU、内存、IO、进程数等资源的统一管理与限制。这是实现“公平、可预测与可控”的多用户环境的基础能力。资源域的边界与配额由内核在运行时强制执行，确保某个用户或服务的峰值压力不会吞没系统其他部分。
与传统的进程组概念不同，cgroups 将资源分配作为一项可编程、可追踪的机制，具备动态调整的能力。统一层级（v2 统一树）或多层控制器（v1）都可以实现对 CPU、内存、PID、IO、网络等资源的约束。理解这一点，有助于设计出对“温度阈值”之类的动态策略友好的隔离方案。你可以把 cgroups 看作是一个“资源预算与执行边界”的管控中心。
在多用户场景下，合理的资源分配策略不仅能防止单个用户占满机器，还能提升整体吞吐与交互体验。隔离粒度的选择、控制器的组合以及运行策略，共同决定了隔离的粒度与复杂度。本文将以基于 cgroups 的限制原理为出发点，结合实际操作步骤，带你从原理到落地实现全面解析。
1.1 cgroups 的核心机制
核心机制是对进程集合的资源配额强制执行，Linux 内核会在调度、内存分配、IO 调度等关键路径上进行检查，确保超出配额的行为被限制或阻断。控制组边界由文件接口暴露，运维人员可通过挂载的虚拟文件系统对边界进行设定与调整。
在实际操作中，理解“控制器、层级、并发”三大要素很重要。控制器负责资源类型（如 cpu、memory、pids），层级表示资源域的组织结构，而并发则体现为同一父级下多个子组共享资源的方式。正确组合这三者，便能实现精准的多用户隔离。
1.2 资源控制器与层级的关系
控制器是资源的实际实现单元，常见的包括 cpu、memory、pids、io、hugetlb 等。通过为不同的控制器配置不同的配额，可以实现对各类资源的独立约束。层级结构决定了配额的传播与继承，父级分配的 quota 会向下传递到子级。
在 cgroups v2（统一层级）中，所有控制器在同一层级树中协同工作，能达到更简化的配置与更一致的行为。而在传统的 cgroups v1 中，每个控制器独立挂载在不同的层级，需要对每个控制器单独管理。了解这点，有助于后续针对性地做多用户隔离设计。
2. Linux 系统中的实现架构与版本选择
2.1 v2 与 v1 的差异
cgroups v2 提供统一的层级树，将多种控制器整合到一个统一的文件系统中，简化了创建、继承和传播行为。写入 cpu.max、memory.max、cgroup.procs 等文件即可实现限制与进程迁移，更易于理解和运维。
相对而言，cgroups v1 的灵活性较高，但配置复杂度也高，需要分别管理每个控制器的子树与限制文件。若你的发行版偏向 systemd 的现代治理，通常会推荐使用 cgroups v2，以获得更一致的行为和更简便的管理口径。
2.2 为什么在多用户场景中更偏向使用 cgroups v2
统一树结构减少边界错位的风险，在多用户场景下尤其重要，因为你需要对不同用户的进程进行一致的封控与隔离。更直观的控制文件与原子操作使得实现动态阈值、快速回收资源更为直接。
此外，现代发行版对 systemd 的集成使得通过 systemd 提供的 unit、slice、scope 机制与 cgroups v2 的协同工作更加顺畅。对于需要实现“按用户分组、按服务分组”的场景，使用 v2 可以更容易实现组内隔离、跨组协同与统一监控。
3. 设计思路：如何在多用户环境中分配资源
3.1 用户隔离的粒度选型
粒度越细，隔离越强，但维护成本也越高。在实践中，通常以用户或租户为单位建立一个或多个 cgroup，必要时再在同一用户内部按服务拆分。统一用户级别的资源域可以确保单个用户的浪涌不会影响其他用户。
对关键服务可以进一步在其所属的用户域内再细分，例如把数据库、应用逻辑、后台任务分别放置在独立的子域，避免互相竞争。这种分层策略既实现了公平性，也保留了灵活的扩展能力。
3.2 资源策略：CPU、内存、PID、I/O 等限制
常见的限制策略包括：CPU 配额与周期、内存上限、进程数上限、IO 带宽等。在 cgroups v2 中，可以通过 cpu.max、memory.max、pids.max、io.weight 等文件实现。合理设定阈值并结合监控，能够在高负载时平滑地抑制资源竞争。
动态调整策略则需要结合运行时监控指标：CPU 使用率、内存使用峰值、活动进程数量等，并考虑“温度”级别的阈值来触发自适应控制。本文后面会给出一个实际操作示例，其中引入 temperature=0.6 的概念来说明自适应阈值的思路。
4. 实操指南：基于 cgroups v2 的多用户隔离实现
4.1 环境准备与挂载
确保内核启用并挂载了 cgroup v2 统一树，这是实现多用户隔离的前提。若系统未挂载，需要先完成挂载操作。下面给出常见的检查与挂载步骤。
挂载验证与创建工作目录可帮助你确认当前系统是否已经采用统一层级，并为后续分组做好准备。
# 检查系统是否已挂载 cgroup v2
mount | grep 'type cgroup2'
# 如果未挂载，手动挂载（示例路径可根据实际系统调整）
sudo mkdir -p /sys/fs/cgroup
sudo mount -t cgroup2 none /sys/fs/cgroup
在多用户环境中，确保 systemd 或 Init 系统能够配合 cgroups v2 的管理，以便后续通过 slice、scope、unit 等机制进行资源分配与监控。
4.2 创建并配置用户专属 cgroup
为每个用户创建独立的 cgroup 子树，并写入初始的资源限制。通过统一树来管理 CPU、内存、以及其他控制器的配额，能够实现明确的隔离边界。
下面给出一个基于 cgroup v2 的实际示例，展示如何为用户 alice 创建专属域并设定基本限制。请在具有 root 权限的环境中执行。
# 1) 假设系统已经是 cgroup v2 的统一树，直接在统一根下创建 alice 的专属域
sudo mkdir /sys/fs/cgroup/alice# 2) 设置 CPU 限制：每个周期为 100000 微秒，其中 alice 可用 40000 微秒
echo "40000 100000" | sudo tee /sys/fs/cgroup/alice/cpu.max# 3) 设置内存上限（如 2GB）
echo 2147483648 | sudo tee /sys/fs/cgroup/alice/memory.max# 4) 将某个进程加入 alice 的 cgroup（替换 为实际进程号）
echo | sudo tee /sys/fs/cgroup/alice/cgroup.procs
如需把更多控制器加入到 alice 的域中，可以继续写入对应的控制器参数，例如 pids.max、io.weight 等。并且，在 cgroup v2 下，将子进程加入同一域后，资源限制将自动生效并向下传递，使得该域下的所有子进程都受同样的约束。
另外一种更易集成的方法是借助 systemd 的 unit/slice/scope 机制，例如创建一个 alice.slice，并用 systemd 绑定进程到该 slice，以实现更高层次的管理。以下展示 systemd-run 的简易用法。
# 使用 systemd-run 将一个命令放入 alice.slice 的资源域中
sudo systemd-run --slice=alice.slice --unit=alice-task /usr/bin/your_application
# 如果需要显式设置资源上限，可以在创建 slice 时指定相关参数
4.3 将进程加入到 cgroup 并验证
验证操作是确保隔离生效的关键步骤，你需要确认进程确实处于 alice 的控制组中，同时检查各项限制是否按预期运行。
通过查看 cgroup 的状态及进程所属情况，可以快速确认隔离效果。
# 查看 alice 域的当前限制
cat /sys/fs/cgroup/alice/cpu.max
cat /sys/fs/cgroup/alice/memory.max# 查看 alice 下的进程列表
cat /sys/fs/cgroup/alice/cgroup.procs# 查看某个进程所在的控制组（对比 pid 号）
cat /proc//cgroup
在多用户环境中，若需要对同一用户下的多项服务进行分组，可以为不同服务再创建子域，如 alice/db、alice/app 等，并将相关进程逐一加入对应子域，形成更细粒度的隔离。
5. 监控、调优与排错
5.1 监控要点与工具
监控是维持长期稳定隔离的关键环节。对于 cgroups v2，常用的监控点包括 cpu.stat、cpu.max、memory.usage_in_bytes、memory.max、cgroup.procs 等文件的实时值，以及系统整体的负载情况。通过读取这些文件，可以了解当前资源分配的利用率、限制是否达到阈值，以及是否有进程被挤出或迁移到其他域。
除了文件系统接口，还可以借助系统自带的监控工具（如 top、htop、pidstat）与系统日志，结合自定义脚本实现更全面的观测。定期对比实际使用与设定的阈值，是发现异常并快速响应的有效方式。
5.2 常见排错与调优思路
若一个进程在 alice 域中依然显示高峰期资源消耗，可能存在以下情况：未正确将进程加入目标控制组、父子域继承关系未生效、或是某些控制器未正确启用。检查要点包括：读取 cgroup.procs、确认内核是否开启了所需控制器、以及查看系统日志以定位策略冲突。
在动态阈值控制场景中，温控策略的引入可以让资源控制更具鲁棒性。例如温度参数 temperature=0.6 可以作为信号触发阈值调整或节流动作的依据，具体实现通常需要结合监控脚本与调度输入。
在实际运维中，为了实现“温度感知”的资源管理，可以在监控端持续采集系统使用率，在达到 temperature=0.6 的阈值时，通过自动化脚本动态调整 alice 的资源配额，或将新创建的进程快速分配到更合适的域中。这样的策略有助于在高并发场景下维持响应性，同时避免单点资源挤占导致的稳定性问题。
