4.1 整体架构与核心组件

4.1 整体架构与核心组件

从本章起，索引知识被放进系统里。本节先给出全章的地图：一套典型向量数据库的分层架构，从接入层到存储层每个组件的职责、相互关系与瓶颈指标。旧版教程里"整体架构"与"核心组件"两节在此合并，因为组件从来不能脱离架构位置去理解——同一个缓存，放在接入层和放在索引节点上，回答的是完全不同的问题。

分层架构总览

尽管各家产品的模块命名不同，成熟向量数据库的骨架高度一致，从上到下分五层。接入层负责协议终结、鉴权与限流，是所有请求的入口，瓶颈特征是连接数与吞吐上限。协调器（查询协调与写入协调）把请求翻译成执行计划：查询被扇出到相关分片、结果被归并排序；写入被路由到目标分片并写日志。它是无状态或轻状态的，瓶颈特征是计划的并发度。索引执行节点持有索引结构本身，执行距离计算与近邻搜索，是最吃内存与 CPU 的层，瓶颈特征是内存占用与查询延迟。存储层管持久化：写前日志、段文件、对象存储挂载，瓶颈特征是落盘延迟与恢复速度。元数据服务记录集合定义、分片映射、段清单与租户信息，规模不大但地位关键——它挂了整个集群找不着北。

图 4-1 向量数据库分层架构

两条路径的组件账

上图右下角的两块板值得展开，因为它们是排障时最先要走的两条路。查询路径上，协调器把请求复制到每个相关分片，各分片在自己的索引上取局部 TopK，协调器归并出全局 TopK。这里有个隐藏的数学：全局召回率不低于任何单分片的召回率，但全局延迟约等于最慢的那个分片——分片间的均衡度直接写进 P99。带过滤条件的查询还多一步取舍：先搜后滤可能凑不够 K 条，先滤后搜在选择性强的条件下退化为全量扫描，第五章 5.1 会专门拆解。

写入路径上，数据先写日志（保证崩溃可恢复），再进内存可变段（立即可见或准可见），封段后后台建索引。第三章的分段机制在这里落地为系统组件：可变段、封段队列、合并线程各自占资源，任何一环堵塞都会反压到写入端。把这两条路径烂熟于心，第六章的监控指标就不再是孤立的数字，而是组件状态的外显。

单机形态是特例也是起点

并非所有场景都需要全套组件。嵌入式形态把五层压进一个进程内的库里，没有接入层与协调器，元数据退化成头文件——十万余条、单机内存装得下的场景，它的简单性就是最大优势；反过来，只要业务预期要跨过单机线，一开始就该按集群形态设计数据布局（分片键、租户规划），否则将来迁移的代价远大于提前设计。这个"从哪起步"的判断，和第六章选型时"嵌入式库还是集群库"的问题是同一个问题。

组件视角下的两个典型时刻

把组件图用起来最好的方式是跟着两个时刻走一遍。时刻一：一条查询进来。 接入层验完身份，把请求递给协调器；协调器查元数据服务拿到分片映射，确定这条查询要扇出给哪几个分片、过滤条件能否下推；各索引节点并行执行搜索，返回局部结果；协调器归并、截断、连同距离分数返回。整条链路里，协调器是唯一的全局串行点，它的计划质量（扇出宽度、下推是否成功）决定了这条查询的成本下限——线上排障时先看查询计划，就是在看协调器做了什么决定。

时刻二：一个索引节点宕机。 元数据服务经心跳发现节点失联，把该节点承载的分片主角色标记为待转移；对应从副本被提升为新主，分片映射更新并广播；协调器此后按新映射路由，客户端几乎无感。恢复的旧节点重新加入时以从副本身份追日志，追平后回归副本池。这个流程里最值得记住的是元数据的地位：它既是路由的依据也是故障转移的依据，这就是为什么生产部署中元数据服务自身要做高可用——它的故障半径是整个集群。

组件清单速查

问题：协调器会不会成为性能瓶颈？

会，但瓶颈形态与直觉不同。协调器通常是无状态的，横向扩容容易，真正的瓶颈是它发起的"扇出宽度"：一个查询扇出到几十个分片，集群里并发查询一多，扇出请求的总数瞬间放大，网络与分片端的调度先被压垮。缓解手段按顺序是：控制单集合分片数（分片数与查询扇出成本成正比）、让过滤条件尽量把扇出范围缩到部分分片、以及在接入层对同一用户的重复查询做合并。评估一个向量库的协调层设计时，"扇出请求是全分片广播还是按映射精准路由"是个能区分实现水平的好问题。

问题：所有组件必须都部署吗？

按规模裁剪。单机形态里五层压缩成一个进程；中小规模里接入与协调合并为一个服务、元数据内嵌于主节点；只有平台级规模才值得把五层全部独立部署。裁剪的原则是"故障半径与规模匹配"：规模越小，越要把运维简单性当一等公民，为一台机器的集合部署五个高可用组件属于过度设计。

问题：组件边界以后会怎么演化？

值得跟踪的趋势是"按资源解耦"：索引计算、内存缓存、持久化存储各自独立伸缩、独立故障域，也就是常说的存算分离。它对使用者的影响是容量与算力可以分开采购、扩容不再绑定整机，代价是组件间网络流量上升、故障排查的跨度变大。评估一家产品的架构演进是否成熟，可以看它的组件切分是否正在朝着"每一层按自己的负载特征独立伸缩"的方向走——切得对，扩容便宜；切得碎，运维遭罪。

顺带一个运维视角的注脚：组件图还是排障分工的依据——接入与协调的问题找平台组，索引与召回的问题找检索组，存储与备份的问题找基础组。团队按组件边界划清责任田，事故响应的第一负责人就能在数秒内到位，这或许是这张架构图最被低估的用途。

本节要点回顾

• 五层骨架：接入、协调、索引执行、存储、元数据，各家产品骨架一致、命名不同。
• 查询延迟约等于最慢分片，分片均衡度直接写进尾延迟。
• 写入先日志后内存段，封段后台建索引，写入成功不等于立即可检索。
• 先搜后滤与先滤后搜的取舍发生在协调器与索引节点之间。
• 嵌入式与集群形态的选择本质是规模预期问题，数据布局要提前设计。

整车构造看完了，下一节看车怎么扩载：数据与流量涨起来之后，分片与副本怎么分工。