1. 向量检索与缓存基础

各位同学好，我是老赵。今天咱们开始这门课的第一章——向量检索与缓存基础。说实话，我做了十几年后端架构，真正让我觉得「这玩意儿不搞缓存根本跑不动」的场景，向量检索排前三。

你想想看，一个高并发推荐系统，用户请求进来，你要在几亿甚至几十亿的向量里找到最相似的 Top-K。纯暴力计算？那延迟直接上天。所以，缓存不是可选项，是必选项。

1.1 向量检索原理：它到底在干什么？

向量检索，说白了就是把非结构化数据（图片、文本、音频）转成一组浮点数，然后在这组浮点数里找「最像」的。

举个例子。一张猫的图片，经过模型会变成一个 512 维的向量：[0.12, -0.34, 0.78, ...]。另一张猫的图片，向量是 [0.11, -0.33, 0.79, ...]。这两组数在空间里离得很近，我们就说它们「相似」。

那怎么衡量距离？最常用的有三种：

距离度量	公式	适用场景
欧氏距离 (L2)	√Σ(aᵢ - bᵢ)²	图像检索、人脸识别
余弦相似度	cos(θ) = (A·B) / (||A||·||B||)	文本匹配、语义搜索
内积 (IP)	Σ(aᵢ × bᵢ)	推荐系统、广告 CTR 预估

我在项目中遇到过一个问题：用欧氏距离做文本检索，结果总是不太对。后来发现文本向量经过 L2 归一化后，欧氏距离和余弦相似度其实等价。嗯，这个坑我踩过，你们注意一下。

1.2 为什么需要缓存？

直接上结论：向量检索的计算成本太高了。

我给你算笔账。假设你有 1 亿条 128 维的向量，用暴力搜索（Flat）做一次查询，需要计算 1 亿次距离。哪怕每次计算只要 1 微秒，一次查询也要 100 秒。这还不算 IO 开销。

所以业界通常用近似最近邻（ANN）算法，比如 HNSW、IVF、PQ。这些算法能把延迟降到毫秒级，但依然扛不住高并发。

举个例子。我去年帮一家电商平台做向量检索优化。他们用 HNSW 做商品相似推荐，单机 QPS 大概 2000。但双十一流量峰值到了 5 万 QPS。不加缓存？机器得加 25 倍，成本根本扛不住。

你想想看，用户搜「红色连衣裙」，今天搜和明天搜，结果大概率是一样的。那为什么每次都要重新算一遍？把热门查询的结果缓存起来，直接返回，不香吗？

1.3 缓存的核心指标

做缓存不能拍脑袋。我习惯用三个指标来衡量缓存系统的好坏：命中率、延迟、吞吐量。这三个指标互相制约，你得找到平衡点。

1.3.1 命中率 (Hit Ratio)

命中率 = 缓存命中的请求数 / 总请求数。这是最直观的指标。

• 高命中率（>90%）：说明缓存策略有效，大部分请求不需要回源计算。
• 低命中率（<50%）：缓存基本白搭，甚至可能因为维护缓存带来额外开销。

我记得有一次，团队把缓存 TTL 设成了 24 小时。结果热门商品向量变了，缓存一直没更新，命中率倒是 99%，但推荐结果全是错的。这就是典型的「高命中率陷阱」——命中率高不代表效果好，还得看数据新鲜度。

1.3.2 延迟 (Latency)

延迟就是一次查询从发出到返回的时间。向量检索的延迟通常分两段：

1. 缓存命中：理想情况 < 1ms，通常用 Redis 或本地内存实现。
2. 缓存未命中（回源）：取决于 ANN 算法，HNSW 一般在 5-20ms，IVF 在 10-50ms。

我建议把 P99 延迟作为核心监控指标。为什么？因为平均延迟会掩盖问题。有一次我们平均延迟只有 3ms，但 P99 到了 200ms。查了半天，发现是缓存热 key 导致 Redis 实例 CPU 打满。嗯，这个后面会细讲。

1.3.3 吞吐量 (Throughput)

吞吐量就是系统每秒能处理的查询数（QPS）。缓存对吞吐量的提升是立竿见影的。

给你一个真实数据对比：

场景	无缓存 QPS	有缓存 QPS	提升倍数
暴力搜索 (Flat)	10	5000	500x
HNSW (EF=128)	2000	50000	25x
IVF (nlist=4096)	1500	30000	20x

你看，哪怕用了 ANN 算法，加上缓存后吞吐量还能再提升一个数量级。这就是缓存的威力。

1.4 本章知识体系总览

下面这张图把本章的核心逻辑串起来了。你可以看到，向量检索是地基，缓存是加速器，而三个指标是衡量系统好坏的标尺。

好了，第一章的内容就到这里。这一章我们打下了基础，后面会一步步深入具体的缓存策略和实战方案。记住我今天说的三个指标，后面每一章都会用到它们来衡量方案的好坏。