一、项目背景

我们的 RAG 知识库跑了一年多，向量规模从几百万涨到上亿，单分片逐渐成为瓶颈。更棘手的是热点：某些高频类目（比如售后政策、产品手册）被反复检索，流量全砸在对应分片上，那台机器 CPU 打满、其余分片却在围观。想扩容，传统做法是停写、整库迁移，业务中断半小时起步，迁移完召回还抖一阵。品牌方（我们内部检索平台）要的是：在线扩容、热点能自动均衡、扩容不伤召回。

二、落地场景

我们给向量库加了分片路由层，按类目/租户做分片键，查询先路由到对应分片再近邻检索。平台持续统计各分片 QPS 和负载，识别热点分片，对热点类目做副本或再分片，把流量摊开。扩容走在线迁移：新分片加入、数据增量同步、流量灰度切过去，全程不停写。管控台有分片热力图和迁移进度。

三、关键技术挑战与解决思路

挑战一是分片路由与一致性。分片键选不好会导致查询跨片广播、延迟飙升。我们按访问亲和性（类目/租户）分片，让大部分查询落单分片，少量跨片查询走聚合，平衡分布与延迟。

挑战二是热点识别与再均衡。我们不止看 QPS，还看单向量查询成本和返回大小，给分片打负载分。热点分片触发再分片或加只读副本，流量按比例分流。

挑战三是在线扩容与迁移。我们用双写+增量追平的迁移：旧分片继续服务，新分片追增量，灰度把读流量切过去，验证召回一致后下线旧分片，全程业务无感。

四、效果数据

规模约 1.2 亿向量的脱敏示意值：热点分片 QPS 峰值从约 3200 降到约 900（再均衡后），热点导致的超时率从约 2.1% 降到约 0.15%；一次扩容的停写时长从约 28 分钟降到约 0（在线迁移）；召回率@10 在扩容前后波动小于 0.3%，基本无损；查询 P99 时延从约 120 毫秒降到约 65 毫秒；分片数随规模从 8 扩到 32，运维人工介入趋近于零。

五、可复用经验总结

第一，向量分片先选对分片键——按访问亲和性分，让多数查询落单分片，跨片查询才可控。第二，热点要识别"成本"而非只看 QPS，再均衡比加机器更治本。第三，扩容走双写+增量追平+灰度读切，在线无损。我们把分片路由与迁移抽成通用件，新租户接入主要配分片键。

结语

向量库扩容最怕"停写半小时、召回抖三天"。我们的老办法是整库迁移，业务 interruptions 谁都受不了。改成按访问亲和性分片后，大部分查询单分片内完成，跨片聚合只是少数，延迟先稳了。

热点识别别只盯 QPS。同样一千次查询，售后政策类和冷门类目的单向量成本天差地别，我们看的是综合负载分，热点分片才不会被误判。再均衡（再分片或加只读副本）比盲目堆机器治本。扩容走双写加增量追平、读流量灰度切，召回前后波动不到 0.3%，业务全程无感。分片路由和迁移抽成通用件后，新租户接入只配分片键，亿级向量也能平滑长大。

案例片段（已脱敏）： ```

分片路由与在线迁移（伪代码节选）

shard = route(query, key=query.category)     # 按类目亲和路由 if shard.load_score > 0.85:    rebalance(shard, add_replica=True)        # 热点再均衡

扩容：双写 + 增量追平 + 灰度读切

new_shard.start_double_write(old=shard) new_shard.catch_up(incremental=True) shift_read_traffic(from=shard, to=new_shard, ratio=step(0.1)) if recall_consistent(new_shard, shard): old_shard.retire() ``` 分片按亲和路由；热点再均衡；扩容双写灰度。

附：规模化落地的体会

分片路由稳定后，我们终于敢对热点类目做精细化运营。比如售后政策这种高频被查的类目，单独分片加只读副本，查询又快又不影响其他类目。以前热点一上来，整库都慢，无辜类目跟着遭殃；现在故障域被切小，爆炸半径可控。在线迁移也改变了我们的容量规划方式。以前容量到了八成就开始焦虑，因为扩容代价大；现在扩容近乎无感，我们敢于把分片压得更满、更省资源，真到拐点再平滑扩。容量规划从防御性预留，变成按需弹性，硬件利用率和稳定性同时改善。

附：给同行的提醒

给检索平台同学的提醒：分片键要跟着访问模式走，不是跟着数据走。我们最初按租户分片，后来发现同一租户内不同类目热度差极大，热点还在；改成按类目亲和分片后，热点才真正被切散。分片键错了，后面再调都事倍功半。扩容也别等到快爆了才动。我们把分片负载分接进监控，持续过热的分片提前再均衡，而不是等超时告警才救火。在线迁移让提前扩容成为可能，把容量管理从救火变预防，运维才睡得着觉。

附：工程落地的细节

热点分片的再均衡我们做了自动化。监控发现分片负载分连续超阈，自动触发再分片或加副本，流量按比例迁移，不用运维半夜爬起来。容量管理从人盯变成系统盯。向量召回我们加了兜底。分片偶尔抖动，查询降级到全量轻量检索，保证不超时、结果略粗但可用。降级不是失败，是保底。用户感知不到一次事故，比零事故更难也更重要。迁移的召回一致性校验我们固化成常态。每次扩容完自动跑一遍召回对比，差异超阈值就告警。在线迁移的信任，来自每次都能证明召回没丢。没有校验的迁移，谁都不敢白天做。最后一句话：向量库上规模后，难点不在检索算法，而在工程化的容量与热点。分片路由、再均衡、在线迁移这三件事做扎实，亿级向量也能像小库一样稳。检索平台的成熟，看扩容当晚运维睡没睡好就知道。