复杂查询的缓存策略/设计模式

Question

我们有一个现有的 API，它有一个使用 Redis 的非常简单的缓存命中/缓存未命中系统。支持Key搜索。因此，可以根据主键轻松缓存转换为以下内容的查询。

SELECT * FROM [Entities] WHERE PrimaryKeyCol = @p1

任何后续请求都可以通过其主键在 REDIS 中查找实体或故障回复到数据库，然后使用该结果填充缓存。

我们正在构建一个新的 API，它将允许通过更多参数进行搜索，将在结果中返回多个条目，并且将处于相当高的请求量下（足以影响我们在 SQL 中现有的 DTU 利用率天蓝色）。

查询将可以通过其他几个术语、一次搜索中的多个 PK、各种其他 FK 查找列、文本上的 LIKE/CONTAINS 语句等进行搜索...

在这种情况下，是否有任何我们可以考虑的设计模式或缓存策略。Redis 似乎不太适合这些类型的查询。我正在考虑简单地散列查询参数，然后将该散列作为键缓存，并将整个结果集作为值缓存。

但考虑到 Redis 的键值特性，以及一个实体可能包含在多个查询哈希下的多个结果集中这一事实，这感觉有点天真。

（作为参考，此数据的来源目前是 SQL Azure，我们使用的是 Azure 的托管 Redis 服务。我们也在寻找其他方法来访问数据库，包括对数据进行非规范化、将数据 ETL 到 CosmosDB、托管数据在 Azure 搜索中，但这样做还有其他含义，包括实施时间、数据的“新鲜度”等......）

Answer 1

就我个人而言，我不会尝试缓存结果，而只会缓存单个实体。当我过去完成类似的操作时，我会从实时查询返回 ID 列表，并从缓存层检索各个实体。这样，ID 列表始终是“新鲜的”，并且您不会遇到令人讨厌的缓存失效逻辑问题。

如果您确实经常进行重复搜索，则可以缓存（id 的）结果，但您可能会遇到分页等问题。缓存查询结果可能很棘手，因为您通常需要缓存所有结果，而不仅仅是第一个“页面”的值。这通常非常昂贵，并且传输成本很高，超过了缓存的价值。

此外，您绝对会遇到缓存查询结果的新鲜度问题。当新记录出现时，它们不会出现在缓存列表中。使用仅实体缓存可以避免这种情况，因为 ID 列表始终是新鲜的，只有实体本身可能是陈旧的（但这具有更简单的缓存过期方法）。

如果您担心实体的陈旧性，您不仅可以返回 ID，还可以返回“上次更新日期”，这使您可以将每个实体的新鲜度与缓存进行比较。