我们正在开发一个搜索引擎网络应用程序，使用户能够搜索大约 200 个门户网站的内容。
我们的业务合作伙伴负责维护和提供 solr/lucene 实例，该实例正在执行索引数据的主要工作。
我们的应用程序查询 solr 并以人性化的方式呈现结果。但是，我们想知道如何限制查询的数量，或许可以使用某种形式的缓存。结果可能会被缓存几个小时。
我们想知道的是：缓存查询结果的好策略是什么？显然，我们希望方法调用会有很大的不同……做缓存有意义吗？
是否有一些缓存系统特别适合这个用例？我们正在使用 Spring 3 进行开发。
我要记住 Solr 已经内置了很多缓存，以加快常见查询。我建议您在使用自己的查询缓存重新发明轮子之前，先研究一下 Solr/Lucene 的固有功能。
这是一个很好的起点。
最简单的解决方案是在查询到 Solr 之前对其进行重组。
我创建了自己的QueryBuilder方法，在点击 Solr 之前，我通过了我的查询字符串。
所做的只是分解所有参数，然后将它们分类到预定义的组中。
例如，为了规范您的查询以便它们可以缓存，您可以按每个键的字母顺序排序，然后修改查询字符串，然后使用它来查询 Solr。（实际查询结果不变）。
在实际运行查询之前，您可以创建 Solr 查询字符串的哈希，并检查已保存的所有键的内存哈希。如果您发现自己很可能接近数百万个查询键，那么您可能希望开始考虑使用BloomFilter来减少键空间并在缓存命中时仍保持一定程度的准确性。
或者，您可能希望在您和 Solr 之间放置一个反向代理缓存。例如，如果您要查询 Solr 之类的Spring -> Varnish -> Solr，则Varnish可用于缓存，它将使用查询字符串作为哈希。然后，您可以设置 2 小时到期，以便自动刷新/清除/无效结果。
希望这会有所帮助。
我发现在 Lucene 之外缓存结果或呈现的内容效果最好。拥有一个指向缓存层的 API 搜索服务，其中包含来自 Lucene 索引的结果。
如果将缓存层分开，则可以插入所需的任何缓存...分布式缓存（Redis、Azure AppFabric、其他云缓存等）。您还可以缓存网页的部分呈现（即 ASP.NET 中的输出缓存）或使用 RESTful 约定缓存 API 调用本身。诸如缓存预热或主动缓存（基于使用）之类的事情很容易通过服务来完成。
然后，您的应用程序/索引缓存可以在您的应用程序的更多层中“重用”，而不仅仅是在索引级别进行缓存。这一切都取决于您的索引更新是否是实时的，查询对于每个客户端/用户 ID 是否具有日期级别的安全性等。如上所述，Solr 已经为您完成了“一些”这些工作。