【向量检索引擎】Proxy 与 Coordinator：接入面、TSO 与集群大脑
内容提要
本文讨论了Milvus 2.6.x的架构，重点在于无状态Proxy和单活跃Coordinator的设计。Proxy负责请求校验和结果处理，Coordinator维护拓扑和任务调度。文章还提到时间戳管理和查询视图的路由，强调无状态Worker的优势与挑战，以及单活跃Coordinator在一致性和故障处理中的重要性。
关键要点
-
Milvus 2.6.x的架构包括无状态Proxy和单活跃Coordinator。
-
无状态Proxy负责请求校验和结果处理，提供统一入口。
-
Proxy的无状态特性使得扩展副本时不迁移本地数据，但增加了CPU和内存的负担。
-
单活跃Coordinator维护拓扑、任务调度和集群一致性，确保系统的高可用性。
-
Coordinator通过元存储（etcd）支持高可用元数据与服务注册。
-
时间戳管理通过TSO体系提供，确保查询的可见性与一致性。
-
Coordinator的Query管理职责包括提供查询视图以指导路由。
-
无状态Worker的设计假设对象存储与etcd可用，但高延迟和按请求计费是潜在代价。
-
单活跃Coordinator简化一致性管理，但也可能成为故障热点。
延伸解读
无状态Proxy的优势与挑战
Milvus 2.6.x中的无状态Proxy设计使得系统在扩展时无需迁移本地数据，提升了灵活性。然而，这也导致了CPU和内存负担的增加，特别是在高并发和超大top-k查询时，Proxy的性能可能成为瓶颈。用户在设计系统时需考虑这一点，以确保资源的合理分配。
单活跃Coordinator的故障风险
单活跃Coordinator虽然简化了一致性管理，但也可能成为故障的单点。若Coordinator出现问题，整个系统的调度和一致性将受到影响。因此，在运维时需要特别关注Coordinator的健康状态，并制定相应的故障切换策略，以保障系统的高可用性。
时间戳管理的复杂性
Milvus的时间戳管理通过TSO体系确保查询的可见性与一致性，但其复杂性也不容忽视。用户在进行DML操作时需理解Guarantee_timestamp和Service_timestamp的关系，以避免在不完整视图上执行查询，从而影响数据的准确性。
延伸问答
Milvus 2.6.x的架构主要包括哪些组件？
Milvus 2.6.x的架构主要包括无状态Proxy和单活跃Coordinator。
无状态Proxy的主要职责是什么？
无状态Proxy负责请求校验和结果处理，提供统一入口，并聚合各路中间结果。
单活跃Coordinator的作用是什么？
单活跃Coordinator负责维护拓扑、调度任务和承诺集群级一致性，确保系统高可用性。
时间戳管理是如何在Milvus中实现的？
时间戳管理通过TSO体系提供，确保查询的可见性与一致性。
无状态Worker的设计假设是什么？
无状态Worker的设计假设对象存储与etcd可用，但高延迟和按请求计费是潜在代价。
Proxy的无状态特性带来了哪些挑战？
Proxy的无状态特性增加了CPU和内存的负担，尤其在高并发和超大topk查询时。
