第四章 系统架构与数据生命周期

第四章 · 系统架构与数据生命周期

本章要回答的三个问题：一个向量从客户端发出到落盘可查，中间经过哪些组件、每一环可能卡在哪里？数据涨到单机装不下、流量涨到单机扛不住时，系统靠什么机制水平扩展？写入、更新、删除、备份这些日常操作，在向量语义下有哪些和传统数据库不同的坑？

为什么会有这一章

第三章结束时，索引的所有知识已经就位，但索引只是发动机，不是整辆车。生产事故的分布很能说明问题：因索引参数不当引发的问题大约只占少数，更多的故障发生在系统层面——写入洪峰把小段堆爆、扩容时数据迁移拖垮在线查询、副本切换后读到旧数据、备份恢复后发现索引没跟上、墓碑积压拖垮召回。这些问题没有一个能靠调索引参数解决，它们的答案都在架构里。

本章把镜头从算法拉远到系统，按数据的一生组织：先看整车的构造（整体架构与核心组件），再看车怎么扩载（分布式扩展），然后跟一条数据走完写入、更新、删除的完整旅程，最后看数据怎么被保护（持久化、备份与压缩）。读完本章，第三章的索引就不再是孤立的知识点，而是架构蓝图上被承载、被调度、被保护的那个部件。

读完能解决什么

对照开头的三个问题，读完你应当获得这些能力：能画出所用向量库的组件图，说清一次查询和一次写入分别经过哪些环节、每个环节的瓶颈指标是什么；面对容量与流量增长，能判断该加分片还是加副本，并估算扩容期间的数据迁移量与在线影响；能设计写入链路的批量策略，说清"写入成功"与"可被检索"之间的时间差从哪来、怎么控制；能为集群制定备份与恢复方案，估算不同压缩档位下的内存账，而不是等 OOM 了才研究量化配置。

这一章同样是为第六章的部署与选型做铺垫：看不懂组件分工，就看不懂监控指标该挂在哪；看不懂数据生命周期，就评估不了产品宣称的"实时""高可用"成色。

各节怎么分工

四节按数据的时空顺序排布。4.1 给出通用的分层架构：接入层、协调器、索引节点、存储与元数据服务，每层一个组件一张表，并标注典型的瓶颈位置——这一节是全章的地图。4.2 讲水平扩展的两种基本手段：分片解决容量、副本解决可用性与读吞吐，顺带说清一致性哈希怎么让扩容少搬数据、跨分片查询怎么扇出与归并。4.3 跟一条数据走完整生命周期：写前日志、内存缓冲、封段建索引、可见性延迟、更新与删除的语义，中间用一张状态图把记录的一生画出来。4.4 讲保护措施：持久化的落盘时机、快照与按时间点恢复、以及量化压缩的内存账怎么算。

四节的依赖是累积的：4.1 的组件图为 4.2 的扩展机制提供挂载点；4.3 的生命周期理解了"段"，4.4 的备份与压缩才有作用对象。

还有一点定位说明：本章讲的是"通用骨架"而非某家产品的部署手册，五层组件的名字在各家文档里叫法不同，但职责划分高度一致。学会按职责而不是按产品名理解架构，你在评估任何一家新供应商时都能快速对号入座，第六章的选型清单正是按这套职责骨架设计的。

先决条件

需要第三章 3.3 的分段与墓碑概念作为前置——本章反复出现的"段"字都源自那里。分布式系统的基础词汇（主从、心跳、故障转移）按日常含义理解即可，本章会在首次出现处给出足够直观的解释，不假设你有运维分布式数据库的经验。

往下走到哪

数据的一生在本章的旅程如下：

走出本章后的去向：想动手部署的读者直接进第六章，本章的组件图与监控点会在那里变成部署清单；想深入查询侧的读者进第五章，看请求落到这些组件之后，引擎内部怎么把它执行到毫秒级。也可以说，本章之前讲的是"数据怎么放"，下一章开始讲"查询怎么跑"，两章在第六章的生产案例里会合。