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

  • Sebastien Auvray
  • 张龙

2008 年 11 月 20 日

话题:RubyWeb框架Ruby on Rails语言 & 开发架构

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

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

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

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

Rack::Cache 扮演着网关代理(VarnishSquid)的角色,我们可以轻松使用它。它支持基于过期(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

 

RubyWeb框架Ruby on Rails语言 & 开发架构