解读

面试官真正想考察的是“在真实业务场景下，如何把持续涌入的增量知识快速、安全地注入到百亿级向量索引中，并保证线上检索质量不降级”。
国内大厂线上环境普遍要求数据合规留痕、跨城容灾、可灰度回滚，因此回答必须同时覆盖技术链路与治理流程。
<5min 的时效意味着不能走“T+1 全量重建”，而要流式增量更新；FAISS 原生只支持追加写与全量合并，没有“原地删除/修改”，所以必须用分层索引+版本热切换策略。
Kafka 侧要应对流量突刺、消息乱序、重复消费三大痛点，必须结合Exactly-Once 语义与分区顺序性保证。

知识点

1. FAISS 索引结构：Flat、IVF、HNSW、IVF+HNSW 混合；增量只能追加，删除需逻辑标记+定期合并。
2. Kafka 事务机制：幂等 producer + transactional write 实现端到端 Exactly-Once。
3. 分层索引：热索引（内存 HNSW）+ 温索引（IVF1024,HNSW32）+ 冷索引（IVF4096,PCA），每层大小按分钟级/小时级/天级滚动。
4. 向量 ID 映射：雪花 ID 分段（时间戳+分片+自增），保证顺序写入与快速定位失效向量。
5. 热切换：双 Buffer + 原子引用替换，切换时老索引继续服务 30s，待新索引 warmup 完成后再下线，零停机。
6. 资源隔离：Kafka 独立 topic 分区对应FAISS 分片，消费者组内再分并发槽，避免单分区瓶颈导致长尾延迟。
7. 合规留痕：Kafka 消息落盘到 HDFS/OSS 并写入Hive 审计表，向量变更记录通过FAISS ID 映射表回查，满足网信备案要求。
8. 性能指标：单分片 4 核 8 G 可支撑每秒 5k 向量 768 维写入，端到端延迟 P99 < 3min；合并阶段使用 GPU（A10） 把千万级聚类压缩到10min 内完成。

答案

整体架构分四层：数据采集层、流式计算层、向量存储层、服务层。

1. 数据采集层
   业务方通过SDK 埋点或CDC 工具把新增文档/图片/商品写入Kafka Topic：vec_raw；
   消息体采用Avro 序列化，字段含text、doc_id、op_type（add/del）；
   开启Kafka 幂等 producer，retries=Integer.MAX_VALUE，acks=all，enable.idempotence=true。

2. 流式计算层（Flink）
   消费 vec_raw，调用自研向量化服务（基于国内备案的 text2vec-large-chinese）生成 768 维向量；
   keyBy(doc_id) 保证同一 doc 的顺序性，process function 内维护 RocksDB 状态做去重与合并；
   输出到Kafka Topic：vec_embed，分区键=shard_id（doc_id 哈希 % 64），保证同一分片内顺序；
   开启Flink Kafka Producer 事务，checkpoint 间隔 30s，Exactly-Once 语义。

3. 向量存储层
   每个分片对应一个 FaissProxy 进程，内部维护三层索引：

   • Hot：HNSW M=32，efConstruction=200，内存 <1G，保存最近 5min 数据；
   • Warm：IVF1024+HNSW32，内存 <5G，保存最近 1h 数据；
   • Cold：IVF4096+PCA128，磁盘 mmap，全量天级备份。
     消费线程收到vec_embed后：
     a. 追加写入 Hot 索引；
     b. 同步写 WAL（本地 SSD），异步刷盘 OSS；
     c. 每 5min 或 10w 条触发Hot→Warm 滚动：把 Hot 向量 dump 为临时文件，新建 Warm 索引，GPU 聚类 1min 内完成；
     d. 滚动完成后通过原子引用替换切换searcher对象，老对象延迟 30s 销毁；
     e. 每天凌晨 04:00触发Warm→Cold 合并，合并过程双 Buffer，服务无抖动。

4. 服务层
   对外提供gRPC 接口，请求带 shard_key，路由到对应 FaissProxy；
   TopK 结果回传后，业务侧再回表 MySQL/StarRocks 补全字段；
   监控指标：Kafka 消费延迟、FAISS 查询 RT、索引版本号、内存占用；
   告警阈值：消费延迟 >3min 或 查询 RT P99 >100ms 立即电话告警。

5. 容灾与回滚

   • 跨城双活：上海+北京双集群，Kafka MirrorMaker 2 同步 vec_embed；
   • 版本回滚：索引文件命名带时间戳，切换失败时秒级回滚到上一版本；
   • 灰度发布：按用户尾号灰度 5%→30%→100%，实时对比 TopK 重合率 <95% 自动熔断。

通过以上链路，实测 4 核 8 G 容器可在峰值 5k qps 写入下，端到端延迟 P99 2min48s，满足**<5min 近实时**要求。

拓展思考

1. 如果业务要求 <30s 可见，可把Hot 索引直接换成 Milvus 的 Growing Segment，FAISS 只负责 Warm/Cold，双引擎混合检索，但需额外维护两套 ID 映射，复杂度翻倍。
2. 当向量维度升到 1536 以上，HNSW 内存膨胀 2 倍，可引入国内云厂商的 RDMA+NVMe 池化内存，把热索引放到 分布式共享内存 减少单机内存压力。
3. 面对“逻辑删除”占比 >30% 的场景，定期合并开销过大，可尝试FAISS 1.7.4 的 IDSelector Bitmap，查询阶段过滤，牺牲 5% 延迟换取 零合并，但需额外 1bit/向量内存，亿级向量约 120M，可接受。
4. 合规层面，若向量本身含敏感特征（如人脸），需先走国密 SM4 加密再存 FAISS，检索阶段解密，密钥托管在 HSM 硬件模块，性能损耗约 8%，但通过国密局认证，满足金融级要求。