缓存 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 即将发布的基准将会很有意思。
暂无签名
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
评论