我们使用REDIS具有非常简单的缓存/高速缓存系统的现有API。它支持通过键搜索。因此，一个转换为以下内容的查询很容易根据其主要键进行缓存。
SELECT * FROM [Entities] WHERE PrimaryKeyCol = @p1
任何后续请求都可以通过其主键在Redis中查找实体，也可以返回数据库，然后使用该结果填充缓存。
我们正在构建一个新的API过程，该API将允许更多的参数搜索，将返回结果中的多个条目，并且将在相当高的请求量下(足够，以便它会影响我们现有的DTUSQL Azure中的利用(。
查询将通过其他几个术语进行搜索，一个搜索中的多个PK，其他各种FK查找列，例如/包含文本上的语句等...
在这种情况下，是否有我们可以考虑的任何设计模式或缓存策略。Redis似乎并不特别适合这些类型的查询。我正在考虑简单地放大查询参数，然后缓存哈希作为键，整个结果将其设置为值。
，考虑到Redis的键值性质，这感觉就像是一种天真的方法，并且一个实体可能包含在多个查询哈希下的多个结果集中。
。(用于参考，此数据的来源是当前SQL Azure，我们正在使用Azure的托管Redis服务。我们还在寻找击中数据库的替代方法到CosmosDB，在Azure搜索中托管数据，但对此进行了其他影响，包括实现时间，数据的"新鲜度"等...(
就个人而言，我不会尝试缓存结果，只是单个实体。过去我做这样的事情时，我会返回实时查询中的ID列表，并从缓存层检索单个实体。这样，ID列表总是"新鲜的"，并且您没有讨厌的缓存逻辑问题。
如果您确实确实有通常会重新出现的搜索，则可以缓存(IDS的(结果，但是您可能会遇到分页等问题。缓存查询结果可能很棘手，因为通常需要缓存所有结果，而不仅仅是第一个"页面"价值。这通常非常昂贵，并且具有超过缓存价值的高转移成本。
此外，您绝对会在缓存查询结果中遇到新鲜问题。随着新记录显示，它们不会在缓存列表中。仅通过实体缓存而避免这种情况，因为ID列表始终是新鲜的，只有实体本身就可以是陈旧的(但这具有更容易的Cache-ospiration方法论(。
。如果您担心实体的陈旧性，不仅可以返回ID，还可以返回"最后更新日期"，这使您可以将每个实体的新鲜度与缓存进行比较。
<</p>