mad*_*ode 22 api rest memcached caching varnish
我正在考虑在前面创建缓存层的最佳方法,或者作为对我的RESTful API(用Ruby编写)的GET请求的第一层.
并非每个请求都可以缓存,因为即使对于某些GET请求,API也必须验证请求的用户/应用程序.这意味着我需要配置哪个请求是可缓存的以及每个缓存的答案有效多长时间.对于少数情况,我需要非常短的到期时间,例如15秒及以下.即使尚未达到过期日期,我也应该能够让API应用程序使缓存条目到期.
我已经考虑了许多可能的解决方案,我的两个最佳想法:
API的第一层(甚至在路由之前),我自己的缓存逻辑(手中有所有配置选项),答案和存储到Memcached的到期日期
一个网络服务器代理(高可配置),也许像Squid之类的东西,但我从来没有使用代理这样的情况,我绝对不确定它
我还考虑过像Varnish这样的缓存解决方案,我将Varnish用于"通常"的Web应用程序,它令人印象深刻,但配置有点特别.但如果它是最快的解决方案,我会使用它.
另一个想法是缓存到Solr索引,我已经在数据层中使用它来查询数据库以查找大多数请求.
如果某人有关于此主题的提示或良好来源,请告诉我.
memcached 是一个很好的选择，我看到你已经提到了这个作为一个可能的选择。此外，Redis 似乎在这个级别上作为另一种选择受到了很多赞扬。
在应用程序级别上，就按文件和/或模块缓存文件的更细粒度的方法而言，本地存储始终是用户可能反复请求的常见对象的一个选项，即使只是丢弃响应一样简单对象进入会话，以便可以重用，而不是进行另一个 http 休息调用和适当的编码。
现在人们来回讨论 varnish 与 squid，两者似乎各有利弊，所以我无法评论哪个更好，但很多人说带有调整过的 apache 服务器的 Varnish 非常适合动态网站。
小智 5
首先,将RESTful API构建为RESTful.这意味着经过身份验证的用户还可以获取缓存内容,以便将所有状态保留在包含身份验证详细信息所需的URL中.当然,这里的命中率会更低,但它可以缓存.
有了大量登录用户,在整页缓存后面有一些模型缓存是非常有益的,因为许多模型仍然是共享的,即使有些模型不是(在一个良好的OOP结构中).
然后,对于整页缓存,您最好将所有请求保留在Web服务器上,特别是在下一步(在您的情况下为Ruby)中远离动态处理.从普通Web服务器缓存完整页面的最快方法始终是Web服务器前的缓存代理.
在我看来,清漆是好的和容易的,但有些人更喜欢鱿鱼.