Milvus 作为一款开源云原生向量数据库，专为亿级规模的近似最近邻（ANN）搜索而设计，其核心在于结合 HNSW 和 IVF-PQ 索引算法，实现高吞吐、低延迟的向量相似性检索，同时通过动态分片和高可用复制机制保障系统在云环境下的弹性扩展与故障恢复。
Milvus 的云原生架构采用存储与计算分离的设计，所有组件均为无状态，支持 Kubernetes 原生部署。这种架构分为接入层、协调服务层、工作节点层和存储层四个独立层次。接入层由 Proxy 组成，提供负载均衡和请求验证；协调服务包括 RootCoord、QueryCoord 等，负责任务调度和元数据管理；工作节点涵盖 QueryNode（查询）、DataNode（数据持久化）和 IndexNode（索引构建）；存储层则使用 etcd（元数据）、Pulsar（流式日志）和 MinIO/S3（对象存储）。这种分层设计允许独立扩展，例如查询负载高时仅扩容 QueryNode，避免资源浪费。
在 ANN 搜索核心，Milvus 支持多种索引融合 HNSW 和 IVF-PQ。HNSW（Hierarchical Navigable Small World）是一种图基索引，适合低延迟场景，通过分层图结构快速逼近最近邻，典型参数为 M=16（每层连接数）、efConstruction=200（构建时搜索范围），在亿级数据集上 QPS 可达数万，召回率>95%。IVF-PQ（Inverted File with Product Quantization）则针对存储压缩，将向量聚类为簇（nlist=10244096），并用 PQ 量化子向量（m=832，bits=8），内存占用降至原 1/4，同时 nprobe=10~50 控制搜索精度与速度。生产中推荐混合：HNSW 用于热数据 IVF-PQ 用于冷数据，阈值相似度>0.7 时融合结果，提升整体精度。
动态分片是 Milvus 规模化的关键，默认哈希分片（基于主键），每个 Collection 初始 2 个 Shard，支持水平扩容至数百 Shard。分片粒度控制在 10~50GB/Shard，避免单点热点；Kubernetes HPA（Horizontal Pod Autoscaler）配置 CPU>70% 时自动扩容 Pod，结合 VChannel（逻辑通道）实现流式写入并行。实际部署中，亿级向量场景下 Shard 数设为数据量/20GB，结合分区（Partition）按业务（如日期）过滤，查询路由仅扫描相关分片，延迟降至 ms 级。
故障容错依赖多副本复制和自动恢复。每个 Shard 支持 3 副本（replication_factor=3），Pulsar 作为 WAL（Write-Ahead Log）确保持久性，节点故障时 Leader 自动切换，RTO<30s。数据多副本存储在对象存储，结合 etcd 心跳检测，QueryCoord 实时调整拓扑。监控要点包括 QPS、P99 延迟、索引构建率、Shard 负载均衡率，使用 Prometheus+Grafana 采集，告警阈值：延迟>100ms 或副本不一致>5% 时触发回滚。
工程化部署清单如下：
- 环境准备：Kubernetes 1.25+，Helm 3.x；存储：S3 兼容桶，Pulsar 集群（或 RocksDB 单机）。
- 资源配置：QueryNode 8C/32G/GPU（A10），IndexNode 16C/64G；HPA minReplicas=3，max=20。
- 索引参数：
| 索引类型 |
参数示例 |
适用规模 |
| HNSW |
M=16, ef=128 |
<1B 低延迟 |
| IVF-PQ |
nlist=8192, m=64 |
>1B 压缩 |
- 分片/复制：shards_num=数据量/50GB，replication_factor=3；分区键如“date”。
- 监控/优化：Prometheus 指标（milvus_query_qps, segment_num），定期 Compact（阈值>10% 碎片）。
- 回滚策略：蓝绿部署，索引重建超时>1h 回滚至 FLAT 精确模式。
在 RAG 等场景，Milvus 通过上述机制支撑每秒万级 QPS，成本仅传统方案 1/3。实际案例显示，10B 向量下 P99 延迟<50ms，扩展无需停机。
资料来源：Milvus GitHub 仓库（https://github.com/milvus-io/milvus），官方架构文档及社区基准测试。