向量数据库实战：选型、调优与落地~系列文章16：Milvus 分布式部署实战-开发者社区

Milvus 分布式部署实战：从单机到集群的完整踩坑记录 🏗️

🔥本文是《向量数据库实战：选型、调优与落地》专栏第 16 篇
⏱️阅读时间：约 15 分钟

🎯 开篇：什么时候需要分布式？

单机 Milvus 的极限：

指标	单机极限
数据量	~5000 万条（受内存限制）
QPS	~5000（取决于硬件）
可用性	单点故障

当你的需求超过这些数字时，就必须上分布式了👇

数据量 > 5000 万条
QPS > 5000
需要高可用（不能宕机）
需要在线扩缩容

🏗️ Milvus 分布式架构

┌─────────────────────────────────────────────────────────────┐ │ Milvus Cluster 架构 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 接入层（Access Layer） │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ Proxy 1 │ │ Proxy 2 │ │ Proxy 3 │ ← 负载均衡 │ │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ ┌───────────┬───────────┼───────────┬───────────┐ │ │ ▼ ▼ ▼ ▼ ▼ │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────────┐ │ │ │Query │ │Data │ │Index │ │Coord │ │ etcd │ │ │ │Node │ │Node │ │Node │ │ZK │ │ (元数据) │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │搜索执行│ │数据管理│ │索引构建│ │调度协调│ │ 3节点集群 │ │ │ └──────┘ └──────┘ └──────┘ └──────┘ └──────────┘ │ │ │ │ │ ┌──────────┐ │ │ │ MinIO │ │ │ │ (对象存储) │ │ │ └──────────┘ │ │ │ │ 各组件均可独立扩缩容！ │ │ │ └─────────────────────────────────────────────────────────────┘

四大组件

组件	职责	扩缩容建议
Proxy	接入层，处理客户端请求	按 QPS 扩，通常 2-5 个
Query Node	执行搜索查询	按数据量和 QPS 扩
Data Node	管理数据写入和持久化	按写入 QPS 扩
Index Node	构建向量索引	按索引构建需求扩

🛠️ Kubernetes 部署（推荐）

Step 1：安装 Milvus Operator

# 添加 Helm 仓库helm repoaddmilvus https://zilliztech.github.io/milvus-helm/ helm repo update# 安装 Milvus Operatorkubectl apply-fhttps://raw.githubusercontent.com/milvus-io/milvus-operator/main/deploy/manifests/deployment.yaml

Step 2：部署 Milvus Cluster

# milvus-cluster.yamlapiVersion:milvus.io/v1beta1kind:Milvusmetadata:name:my-milvusspec:mode:clusterconfig:dataNode:concurrency:4queryNode:scheduler:cpuRatio:0.9components:proxy:replicas:2resources:limits:cpu:"2"memory:"4Gi"queryNode:replicas:3resources:limits:cpu:"4"memory:"16Gi"dataNode:replicas:2resources:limits:cpu:"2"memory:"8Gi"indexNode:replicas:2resources:limits:cpu:"4"memory:"8Gi"dependencies:etcd:replicas:3minio:replicas:3pulsar:replicas:3

# 部署kubectl apply-fmilvus-cluster.yaml# 查看状态kubectl get milvus my-milvus

集群资源估算

数据量	Query Node	Data Node	Index Node	总内存
100 万	2×8GB	2×4GB	2×4GB	~32GB
1000 万	3×16GB	3×8GB	2×8GB	~104GB
5000 万	5×32GB	5×16GB	3×16GB	~368GB
1 亿	8×64GB	8×32GB	4×32GB	~960GB

⚙️ 关键配置调优

消息队列选择

消息队列	优点	缺点	推荐场景
Pulsar	功能全，多层存储	资源消耗大	生产推荐🏆
Kafka	生态好，性能高	需要自己运维	已有 Kafka 的团队
Rockemq	轻量	功能较少	小规模集群

负载均衡策略

# Proxy 层负载均衡配置proxy:maxTaskNum:1024# 最大并发任务数timeTickInterval:200# 时间戳间隔(ms)# 前端 Nginx 负载均衡upstream milvus_proxy{least_conn;# 最少连接数策略server proxy-1:19530; server proxy-2:19530; server proxy-3:19530;}

📊 分布式性能实测

测试环境：K8s 集群，6 节点，1 亿条 1024 维向量

配置	QPS	P50 延迟	P99 延迟	召回率
单机（128GB）	3200	5.2ms	12ms	96.8%
集群（3 Query）	8500	4.8ms	10ms	96.8%
集群（5 Query）	14000	4.5ms	9ms	96.8%
集群（8 Query）	18000	4.2ms	8ms	96.8%

关键发现：

🟢Query Node 数量与 QPS 近似线性关系
🟢延迟几乎不随节点增加而增加
🟢召回率保持一致

⚠️ 踩坑记录

坑 1：etcd 磁盘 IO 瓶颈

问题：etcd 对磁盘 IO 非常敏感，慢磁盘会导致整个集群不稳定 解决：etcd 必须用 SSD，推荐 NVMe

坑 2：Segment 数量过多

问题：大量小 Segment 导致查询性能下降 解决： - 批量写入（每次 > 1000 条） - 定期 compaction - 监控 segment 数量

坑 3：内存 OOM

问题：Query Node 加载数据时 OOM 解决： - 合理估算内存需求 - 配置 loadMemoryLimit - 使用分段加载策略

坑 4：索引构建阻塞查询

问题：大量数据写入后，索引构建占用资源导致查询变慢 解决： - Index Node 独立部署 - 配置索引构建的资源限制 - 错峰构建索引

🔑 本篇核心要点回顾

要点	说明
何时上分布式	数据量>5000万或 QPS>5000
推荐部署方式	Kubernetes + Milvus Operator
核心组件	Proxy/Query/Data/Index Node
消息队列	生产推荐 Pulsar
关键坑	etcd 用 SSD、批量写入、内存估算