您当前的位置: 首页 » AMPZ/Nginx/IIS发布安装 » 使用Rack::Cache进行平滑的HTTP缓存
使用Rack::Cache进行平滑的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即将发布的基准将会很有意思。
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即将发布的基准将会很有意思。