4. 控制平面定义：Loki中控制平面与数据平面的划分，调度策略在控制平面中的位置
在分布式系统的架构设计中，控制平面（Control Plane）与数据平面（Data Plane）的分离是保障系统可扩展性与可管理性的核心原则。Loki 作为云原生日志聚合系统，其查询路径同样遵循这一划分逻辑。理解两个平面的边界与职责，是优化查询调度策略的前提。
4.1 控制平面与数据平面的职责边界
Loki 的查询请求从用户发起（如 Grafana 面板或 LogCLI）到最终返回日志结果，经历了两个截然不同的处理阶段。下表从职责、组件、资源消耗三个维度对两个平面进行对比：
| 维度 | 控制平面（Control Plane） | 数据平面（Data Plane） |
|---|---|---|
| 核心职责 | 查询解析、计划生成、任务调度、元数据路由 | 数据读取、过滤、聚合、结果返回 |
| 关键组件 | Query Frontend、Querier（调度角色）、Scheduler | Querier（执行角色）、Ingester、Store Gateway、Index Gateway |
| 主要资源消耗 | CPU（解析与调度）、内存（查询计划缓存） | CPU（数据扫描与过滤）、内存（数据块缓存）、磁盘 I/O（索引与日志块读取） |
| 延迟敏感性 | 中等（调度决策影响整体延迟） | 高（直接决定查询响应时间） |
| 扩展方式 | 按查询并发数水平扩展 | 按数据量与查询负载水平扩展 |
关键认知：控制平面不直接接触日志数据，它只负责“告诉系统去哪里查、查什么、怎么查”。数据平面则负责实际的数据搬运与计算。这种分离使得调度策略可以独立于数据存储细节进行优化。
4.2 控制平面的核心组件与调度链路
控制平面在 Loki 查询路径中由三个组件构成一条完整的调度链路：
- Query Frontend（查询前端）：接收用户查询请求，进行语法解析、查询拆分（按时间范围拆分为多个子查询）、结果缓存检查。它是控制平面的入口。
- Scheduler（调度器）：接收来自 Query Frontend 的拆分后子查询，根据 Querier 的负载与可用性，将子查询分发给空闲的 Querier 实例。它是调度策略的核心执行者。
- Querier（查询器，调度角色）：从 Scheduler 拉取任务，执行实际的数据平面操作（如从 Ingester 或 Store 读取数据），并将结果返回给 Query Frontend 进行合并。
下图展示了控制平面内部组件之间的调度关系：
4.3 调度策略在控制平面中的位置
调度策略并非一个独立的组件，而是嵌入在 Scheduler 组件内部的一组算法与规则。它在控制平面中处于承上启下的核心位置：
- 承上：接收来自 Query Frontend 的拆分后子查询，这些子查询已经包含了时间范围、标签选择器、聚合函数等元信息。
- 启下：决定将每个子查询分配给哪个 Querier 实例执行，分配依据包括 Querier 的当前负载、数据本地性（Data Locality）、租户隔离策略等。
调度策略的决策输入：
- Querier 负载报告：每个 Querier 定期向 Scheduler 上报当前正在处理的查询数量与资源使用率。
- 数据分片信息：对于 Store Gateway 查询，调度器需要知道哪些 Querier 更接近目标数据分片。
- 租户优先级：在多租户场景下，高优先级租户的查询可能被优先调度。
- 查询超时预算：调度器会避免将查询分配给已经接近超时阈值的 Querier。
4.4 控制平面与数据平面的交互模式
调度策略的最终效果体现在控制平面如何驱动数据平面工作。下图展示了两个平面之间的典型交互流程：
4.5 调度策略的关键决策点
在控制平面中，调度策略主要围绕以下三个决策点展开：
| 决策点 | 描述 | 对性能的影响 |
|---|---|---|
| 负载均衡 | 将子查询均匀分配给所有可用的 Querier 实例，避免单点过载 | 防止部分 Querier 成为瓶颈，提升整体吞吐量 |
| 数据本地性 | 优先将查询调度到缓存了目标数据块的 Querier 实例 | 减少跨节点数据传输，降低查询延迟 |
| 租户隔离 | 为不同租户的查询分配独立的 Querier 资源池 | 避免“吵闹邻居”效应，保障高优先级租户的查询质量 |
常见误区：许多运维人员误以为调度策略只影响控制平面的性能。实际上，一个糟糕的调度策略（如忽略数据本地性）会导致数据平面产生大量的跨节点数据读取，从而显著增加查询延迟。调度策略是连接两个平面的“桥梁”，其质量直接影响端到端查询性能。