使用Rack::Cache进行平滑的HTTP缓存

作者 Sebastien Auvray 译者 张龙 发布于 2008年11月20日

领域

架构 & 设计,

语言 & 开发

主题

性能和可伸缩性 ,

Ruby ,

Ruby on Rails ,

Web框架

标签

Ruby on Rails ,

Rails ,

缓存 ,

HTTP ,

扩展性

缓存Web应用的方式有很多，他们通常都很复杂。随着应用基础设施的不断增加，基本的Rails页面缓存的管理变得越发单调乏味了。

Rails 2.2通过HTTP headers：last_modified与etag引入了条件性GET。Ryan Tomayko遵循着RFC2616中的internet标准缓存说明引入了Rack::Cache。

Rack::Cache是Rack中间件的一部分，它通过基本的存储方式（磁盘、堆及memcache）与针对缓存策略的配置系统实现了RFC2616中的大多数缓存特性。它可与任何使用Rack的Ruby web框架协作良好，同时它也通过了Ruby 1.8.6及1.8.7的测试。

其部分设计的灵感来源于Python的缓存框架Django。

Rack::Cache扮演着网关代理（Varnish、Squid）的角色，我们可以轻松使用它。它支持基于过期（expiration-based）的缓存、验证模型及各种header字段。

正如Ryan King所述，如果你的应用真的需要它的话，你可以平滑地移植到真正的网关代理上：

一旦应用变得大而复杂时，你就需要使用一个像squid或者varnish这样的http反向代理缓存，然而从rails式的页面缓存到HTTP缓存的转变不是那么容易的。你不得不对部署和应用进行大面积的更改。这有点不爽。

借助于Rack::Cache，你只需改变部署即可。你甚至可以增量完成它。你可以首先通过Rack::Cache在堆中进行缓存，然后转换到文件系统，最后到memcache中。当到达其范围极限时，你可以在应用前增加squid或者varnhish，然后移除Rack::Cache。对于部署来说，每一步只有一个主要的变化，这比在单独的操作中掺杂着几个大的变化要容易的多。

看看Ryan即将发布的基准将会很有意思。

查看英文原文：Adobe MAX Day 1 Brings AIR 1.5 and Flex 3.2
 

译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。

• 更早的 >