问题描述
我正在考虑在前面创建缓存层或作为对我的 RESTful API(用 Ruby 编写)的 GET 请求的第一层的最佳方法.
I'm thinking about the best way to create a cache layer in front or as first layer for GET requests to my RESTful API (written in Ruby).
并非每个请求都可以缓存，因为即使对于某些 GET 请求，API 也必须验证发出请求的用户/应用程序.这意味着我需要配置可缓存的请求以及每个缓存的答案的有效期.在某些情况下，我需要一个非常短的到期时间，例如15s及以下.即使尚未达到到期日期，我也应该能够让 API 应用程序让缓存条目到期.
Not every request can be cached, because even for some GET requests the API has to validate the requesting user / application. That means I need to configure which request is cacheable and how long each cached answer is valid. For a few cases I need a very short expiration time of e.g. 15s and below. And I should be able to let cache entries expire by the API application even if the expiration date is not reached yet.
我已经想过很多可能的解决方案，我最好的两个想法:
I already thought about many possible solutions, my two best ideas:
API 的第一层(甚至在路由之前)，我自己的缓存逻辑(让我掌握所有配置选项)，答案和到期日期存储到 Memcached
first layer of the API (even before the routing), cache logic by myself (to have all configuration options in my hand), answers and expiration date stored to Memcached
一个网络服务器代理(高度可配置)，可能类似于 Squid，但我以前从未在这种情况下使用过代理，我绝对不确定
a webserver proxy (high configurable), perhaps something like Squid but I never used a proxy for a case like this before and I'm absolutely not sure about it
我也考虑过像 Varnish 这样的缓存解决方案，我将 Varnish 用于普通"的 Web 应用程序，它令人印象深刻，但配置有点特殊.但如果它是最快的解决方案，我会使用它.
I also thought about a cache solution like Varnish, I used Varnish for "usual" web applications and it's impressive but the configuration is kind of special. But I would use it if it's the fastest solution.
另一个想法是缓存到 Solr 索引，我已经在数据层中使用它来不为大多数请求查询数据库.
An other thought was to cache to the Solr Index, which I'm already using in the data layer to not query the database for most requests.
如果有人有关于此主题的提示或好的来源，请告诉我.
If someone has a hint or good sources to read about this topic, let me know.
推荐答案
memcached 是一个很好的选择，我看到你已经提到了这个可能的选择.此外，Redis 似乎在这个级别上作为另一种选择受到了很多赞扬.
memcached is a great option, and I see you mentioned this already as a possible option. Also Redis seems to be praised a lot as another option at this level.
在应用程序级别上，就按文件和/或模块缓存文件的更细粒度的方法而言，本地存储始终是用户可能反复请求的常见对象的一个选项，即使是简单的只是将响应对象放入会话中以便可以重用，而不是进行另一个 http 休息调用和适当的编码.
On an application level, in terms of a more granular approach to cache on a file by file and/or module basis, local storage is always an option for common objects a user may request over and over again, even as simple as just dropping response objects into session so that can be reused vs making another http rest call and coding appropriately.
现在人们反复讨论 varnish 与 squid，两者似乎各有利弊，所以我无法评论哪个更好，但很多人说带有调整过的 apache 服务器的 Varnish 非常适合动态网站.
Now people go back and forth debating about varnish vs squid, and both seem to have their pros and cons, so I can't comment on which one is better but many people say Varnish with a tuned apache server is great for dynamic websites.
这篇关于缓存 GET 调用的 RESTful API 结果的最佳方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！