02 Milvus-Milvus整体架构

「milvus-course-ai.zip」链接https://pan.quark.cn/s/00f3d411bb6dgithubhttps://github.com/yuanmomoya/milvus学习目标学完本章后你应该能够说清 Proxy、Coord、Node、etcd、MinIO、Pulsar/Rocksmq 的职责。画出 Milvus 写入流、查询流和索引构建流。理解 Segment 生命周期、Flush、Compaction、WAL。判断一个生产问题大概率发生在哪个组件。区分单机 Standalone 和分布式 Cluster 的架构差异。理论知识形象化理解Milvus 的架构可以想象成一个大型物流中心。Proxy 是前台接待负责接收客户订单Coord 系列像调度室决定货物放在哪里、由谁搬运、什么时候合并Node 系列像具体操作工位真正执行写入、查询和建索引etcd 是调度室墙上的总账本MinIO/S3 是后方仓库消息队列则是传送带和流水号系统。写入一条向量不是把数据直接塞进某个单独文件就结束。它会先进入 WAL像订单先贴上可追溯的流水号DataNode 再消费消息、形成 growing segmentFlush 后数据落到对象存储Segment 被封存IndexNode 再把它加工成适合快速搜索的索引。查询时Proxy 会把请求拆给多个 QueryNode拿到局部 TopK 后再归并成全局 TopK。所以排查 Milvus 问题要像看物流链路一样定位是前台接单慢、传送带堵了、仓库 IO 慢、调度表错了还是搜索工位内存不够。架构图不是背组件名而是建立“现象到组件”的映射。总体架构Milvus 采用计算存储分离和多组件协同架构。Proxy 接入请求Coord 系列负责元数据和调度Node 系列负责具体执行etcd 保存元数据对象存储保存 Binlog/Index 文件消息队列承载写入日志和事件流。SDK / REST / 应用服务ProxyRootCoordQueryCoordDataCoordIndexCoordDataNodeQueryNodeIndexNodeetcd 元数据Pulsar/Rocksmq 消息流MinIO/S3 对象存储组件职责组件职责生产关注点Proxy接收客户端请求、鉴权、路由、参数校验QPS、连接数、请求错误率RootCoord管理数据库、Collection、字段、时间戳元数据一致性、DDL 延迟DataCoord管理 Segment、Flush、CompactionSegment 数量、Compaction 积压DataNode消费写入日志生成 Binlog写入吞吐、Flush 延迟QueryCoord调度 QueryNode管理 load/release加载耗时、副本分配QueryNode加载 Segment执行搜索和查询内存、搜索延迟、慢查询IndexCoord调度索引构建任务索引任务积压IndexNode构建向量/标量索引CPU/GPU、构建耗时etcd元数据和服务发现备份、延迟、磁盘空间MinIO/S3Binlog、DeltaLog、Index 文件容量、吞吐、可靠性Pulsar/RocksmqWAL 和消息流消费延迟、积压、持久化写入流程QueryNodeDataCoordMinIO/S3DataNodeWAL/MQProxy应用QueryNodeDataCoordMinIO/S3DataNodeWAL/MQProxy应用insert/upsert写入 WALack写入成功消费写入消息形成 growing segmentflush binlog上报 sealed segment通知加载新 segment写入成功通常意味着数据进入 WAL并不等于索引已经构建完成。新写入数据可能先在 growing segment 中被暴力搜索Flush 后成为 sealed segment再由 IndexNode 构建索引。查询流程QueryNode BQueryNode AQueryCoordProxy应用QueryNode BQueryNode AQueryCoordProxy应用search(collection, vector, filter)获取 shard/segment 分布搜索部分 Segment搜索部分 Segment局部 TopK局部 TopK归并、排序、回填字段全局 TopK查询性能由多个因素共同决定Collection 是否已 loadSegment 是否过碎索引是否构建完成过滤条件能否减少搜索范围输出字段是否过大。Segment 生命周期insert/upsertflush 或达到阈值IndexNode 构建索引QueryNode 加载Compaction 合并/清理release_collectionGrowingSealedIndexedLoadedCompactedReleasedGrowing Segment新写入数据通常未构建索引查询时可能暴力搜索。Sealed Segment已封存数据文件落到对象存储。Indexed Segment索引构建完成适合高性能 ANN 搜索。Compacted Segment合并小 Segment 或清理删除数据后的新 Segment。Flush、Compaction、WAL机制解决的问题过度使用的代价WAL写入可靠性和异步消费消息积压会影响数据可见性Flush将内存数据持久化为 sealed segment频繁 flush 会产生大量小 SegmentCompaction合并 Segment、清理删除数据占用 IO/CPU可能影响前台负载完整代码基础代码见../demos/basic-search生产观察建议配合docker compose logs -f standalone和第 20 章监控指标阅读。常见错误现象可能组件排查方向insert 返回慢Proxy/DataNode/MQ看写入吞吐、消息队列积压、批大小search 慢QueryNode/Proxy看 Collection load 状态、Segment 数量、索引参数create index 慢IndexCoord/IndexNode看索引任务队列、CPU/GPU、对象存储吞吐元数据异常RootCoord/etcd检查 etcd 健康和磁盘空间面试题Milvus 为什么要把 Coord 和 Node 拆开写入成功和可被索引搜索之间为什么可能有时间差Segment 过碎会带来什么问题etcd 和对象存储分别保存什么Standalone 与 Cluster 的主要差异是什么练习题启动 Milvus 后插入 10 万条随机向量观察日志中的 Segment 和 Flush 信息。在搜索前后分别调用load_collection和release_collection比较延迟和错误信息。故意频繁 flush观察搜索性能和 Segment 数量变化。小结理解 Milvus 架构的关键是抓住两条链路写入链路把数据可靠地变成 Segment 和索引查询链路把分散在多个 QueryNode 的局部结果归并成全局 TopK。后续所有调优都离不开这两条链路。