我正在考虑在前面创建缓存层的最佳方法,或者作为对我的RESTful API(用Ruby编写)的GET请求的第一层.
并非每个请求都可以缓存,因为即使对于某些GET请求,API也必须验证请求的用户/应用程序.这意味着我需要配置哪个请求是可缓存的以及每个缓存的答案有效多长时间.对于少数情况,我需要非常短的到期时间,例如15秒及以下.即使尚未达到过期日期,我也应该能够让API应用程序使缓存条目到期.
我已经考虑了许多可能的解决方案,我的两个最佳想法:
API的第一层(甚至在路由之前),我自己的缓存逻辑(手中有所有配置选项),答案和存储到Memcached的到期日期
一个网络服务器代理(高可配置),也许像Squid之类的东西,但我从来没有使用代理这样的情况,我绝对不确定它
我还考虑过像Varnish这样的缓存解决方案,我将Varnish用于"通常"的Web应用程序,它令人印象深刻,但配置有点特别.但如果它是最快的解决方案,我会使用它.
另一个想法是缓存到Solr索引,我已经在数据层中使用它来查询数据库以查找大多数请求.
如果某人有关于此主题的提示或良好来源,请告诉我.
当我搜索文档时，我拿了前10个并将其提供给视图，如果用户滚动到列表的末尾，则应显示下10个元素。
我知道显示的文档的最后一个文档ID，现在我必须获取下一个10。基本上，我将执行完全相同的搜索，但偏移量为10，但是使用相同的查询进行搜索会更好，将最后检索到的文档的文档ID，并在具有该ID的文档之后检索匹配的文档。
Elasticsearch可以做到吗？
===更新
我想指出更多我的问题，因为目前所描述的似乎还不够清楚。抱歉
案子：
您有一种饲料，饲料会每秒增长。如果用户转到该提要，则将获得最近的10个条目；如果向下滚动，则希望获得下一个10个条目。
由于Feed每秒增长，因此通常的偏移量/限制（elasticsearch中的/大小）无法解决此问题，因此您将显示已显示的条目或全新的条目，具体取决于第一次请求（前10个条目）之间的时间以及下一个条目的请求。
在已经显示的条目之后获取下一个10个元素的请求将为后端提供最后显示的条目的ID。后端知道忽略此特定条目之前的所有条目。
目前，我正在用代码处理这个问题，我从Elasticsearch请求具有所有匹配条目的列表，并对其进行迭代，这样我就可以做我想做的所有事情（毫不奇怪）并提取所需的全部块。
我的问题是：elasticsearch中是否存在针对此问题的内置解决方案。因为按照我的方式解决问题并不是最快的。