【向量检索引擎】Proxy 与 Coordinator：接入面、TSO 与集群大脑

第 1 篇 给出四层地图；第 3 篇 与 第 5 篇 把数据面落到 Channel / Streaming Node。控制面仍缺两块：无状态 Proxy 如何成为唯一对外入口，以及 单活跃 Coordinator 如何持有拓扑、时间戳与调度。

本文依据官方 Architecture Overview / Storage/Computing Disaggregation（四层）、Timestamp 文档，钉住 Access Layer 与 Coordinator 的职责清单。不展开一致性四级语义的产品用法全文（第 12 篇），不展开 Data Node 任务内部（第 10 篇）。

本文是「向量检索引擎」系列第 4 篇（共 18 篇）。→ 系列目录

版本锚定：Milvus 2.6.x。

一、Access Layer：无状态 Proxy

官方四层文档对 Access Layer 的定义：

• 由一组 无状态 Proxy 组成，是系统前门与用户端点；
• 校验客户端请求，并对返回结果做 reduce / 后处理；
• Proxy 本身无状态，对外可经 Nginx、Kubernetes Ingress、NodePort、LVS 等提供统一入口；
• Milvus 采用 MPP 架构，Proxy 聚合各路中间结果后再交给客户端。

结合 Architecture 的 API 路径表：

Proxy 因此同时具备三种角色：协议边界（SDK/REST → 内部 RPC）、路由缓存持有者（Architecture：优先用 routing cache，缺缓存才问 Coordinator）、最终归并器（跨 shard 的 Top-\(k\) / query 结果）。

无状态的直接后果：扩 Proxy 副本不迁移本地段数据；会话亲和性不是正确性前提。代价是：每次 search 的最终 reduce 压在 Proxy CPU/内存上——超大 topk、高并发时要把 Proxy 当成独立容量维度（第 17 篇排障）。

二、Coordinator：集群大脑

官方表述：Coordinator 是 Milvus 的大脑；任一时刻全集群恰好一个活跃 Coordinator，负责维护拓扑、调度各类任务、承诺集群级一致性相关职责。

任务清单（官方列举）：

Worker（Streaming / Query / Data）被描述为 dumb executors：听 Coordinator 指令执行；因存算分离而可无状态扩缩（四层文档）。

flowchart LR
  proxy["Proxy"]
  coord["Coordinator<br/>single active"]
  sn["Streaming Node"]
  qn["Query Node"]
  dn["Data Node"]
  proxy -->|"DDL/DCL"| coord
  proxy -->|"DML/DQL"| sn
  coord --> sn
  coord --> qn
  coord --> dn

2.1 为什么是「单活跃」大脑

拓扑、TSO、query view、离线任务队列若多主并发写，容易出现双视图。官方选择 单活跃 Coordinator，用元存储（etcd）支撑高可用元数据与服务注册（四层 · Meta storage）。故障时切换活跃实例属于运维面；客户端经 Proxy 的 Wait for Ready / 重试与 WAL 迁移窗口类似（第 5、14 篇）。

2.2 MixCoord 合并（阅读提示）

部分发行说明与博客提到将历史上拆分的 Root/Data/Query Coord 合并为更简单的协调服务（常称 MixCoord）。本系列以 2.6.x 文档中的「Coordinator」职责表为准；源码目录名可能仍保留历史分包。读源码时按职责（TSO、segment 拓扑、任务调度）检索，不要被旧组件名绑死。

三、TSO 与时间戳：控制面提供的全序原料

Timestamp 文档：DML（插入/删除）会为涉及的实体赋时间戳；同一批 DML 共享同一时间戳值。Streaming 侧 Message 的 TSO 字段决定 WAL 内顺序（第 5 篇）。

对查询侧，官方引入若干时间戳相关概念（产品层多通过 一致性级别 间接配置，用户通常不手写原始 TSO）：

当 Service_timestamp（加可选 Graceful_time）尚不满足 Guarantee_timestamp 时，查询侧 推迟 执行，避免在不完整视图上搜（Timestamp 文档 Scenario 描述）。一致性四级（Strong / Bounded / Session / Eventually）如何映射到 GuaranteeTs，见官方 Consistency Level 与第 12 篇；本篇只钉住：时间语义的权威原料来自 Coordinator 管理的 TSO 体系，查询可见性用 Guarantee/Service 比较落地。

注意：Consistency 文档的示意图仍用「QueryNode 同时收 batch/streaming」的叙述；在 2.6 架构 下 Growing 由 Streaming Node 持有、Sealed 由 Query Node 持有（Data Processing）。读文档时把「查询数据面的 ServiceTime」理解成 参与该次 search 的执行节点所推进的可见水位，具体拼装路径以第 7、9 篇为准。

四、Query view 与路由

Coordinator 的 Query 管理职责包括提供 serving query views 指导路由（Architecture / 四层）。结合 Proxy「routing cache，缺则问 Coordinator」：

1. handoff / 负载均衡改变「哪个 Query Node 持有哪些 Sealed」；
2. Coordinator 更新可服务视图；
3. Proxy / Delegator 按视图把历史检索打到正确节点。

若视图滞后，会出现「段已 flush 但查询仍只打 Growing」或「打到未加载节点」类症状——排障时区分 控制面视图 与 Worker 本地加载状态（第 14、17 篇）。

五、学术谱系与工程间隙

5.1 谱系

Wang et al. (SIGMOD 2021) 已强调分布式与动态更新；2.x/2.6 把协调职责收束到文档化的 Coordinator 任务表，并把流批 Worker 拆开。

5.2 工程间隙

• 「无状态 Worker」假设对象存储与 etcd 可用；对象存储高延迟与按请求计费是官方明确指出的代价（四层 · Object storage），不是实现细节疏忽。
• 单活跃 Coordinator 简化一致性，却使协调者成为控制面热点与故障域——容量与选举时间需纳入 SLO。
• GuaranteeTs 等待会把一致性要求转化为 尾延迟；Strong 与 Eventually 的产品体验差，主要差在等待，而非另一套索引算法。

5.3 开放问题

1. 超大规模下单 Coordinator 的任务队列与 segment 元数据规模上限？
2. Proxy 最终 reduce 是否应下沉到两级树形归并以降低单点带宽？
3. routing cache 的失效策略如何在正确性与 Coordinator QPS 之间自动调参？

六、小结

Proxy 是无状态接入与 MPP 最终归并；Coordinator 是单活跃大脑，握住 DDL、TSO、Streaming 绑定、query view 与离线任务。Worker 执行，不决定集群真值视图。下一篇看持久化形态：对象存储上的 Segment 布局。

参考资料

1. Milvus Documentation v2.6.x, Architecture Overview、Storage/Computing Disaggregation（四层、Coordinator 任务、Object/Meta/WAL 存储）。
2. Milvus Documentation v2.6.x, Timestamp（Guarantee / Service / Graceful）。
3. Milvus Documentation v2.6.x, Consistency Level（四级与 GuaranteeTs 映射；第 12 篇展开）。
4. Wang et al., SIGMOD 2021。
5. 第 1、3、5 篇、系列 index。

返回 系列目录 ｜ 上一篇：Segment 状态机 ｜ 下一篇：对象存储布局