基于资源的HTTP Cache的实现介绍
我们都知道浏览器会缓存访问过网站的网页，浏览器通过URL地址访问一个网页，显示网页内容的同时会在电脑上面缓存网页内容。如果网页没有更新的话，浏览器再次访问这个URL地址的时候，就不会再次下载网页，而是直接使用本地缓存的网页。只有当网站明确标识资源已经更新，浏览器才会再次下载网页。
对于浏览器的这种网页缓存机制大家已经耳熟能详了，举个例子来说，JavaEye的新闻订阅地址：http://www.iteye.com/rss/news?， 当浏览器或者订阅程序访问这个URL地址的时候，JavaEye的服务器在response的header里面会发送给浏览器如下状态标识：
Etag "427fe7b6442f2096dff4f92339305444"Last-Modified Fri, 04 Sep 2009 05GMT这就是告诉浏览器，新闻订阅这个网络资源的最后修改时间和Etag。于是浏览器把这两个状态信息连同网页内容在本地进行缓存，当浏览器再次访问JavaEye新闻订阅地址的时候，浏览器会发送如下两个状态标识给JavaEye服务器：
If-None-Match "427fe7b6442f2096dff4f92339305444"If-Modified-Since Fri, 04 Sep 2009 05GMT就是告诉服务器，我本地缓存的网页最后修改时间和Etag是什么，请问你服务器的资源有没有在我上次访问之后有更新啊？于是JavaEye服务器会核对一下，如果该用户上次访问之后没有更新过新闻，那么根本就不必生成这个RSS了，直接告诉浏览器：“没什么新东西，你还是看自己缓存的网页吧”，于是服务器就发送一个304 Not Modified的消息，其他什么都不用干了。
这就是HTTP层的Cache，使用这种基于资源的缓存机制，不但大大节省服务器程序资源，而且还减少了网页下载次数，节约了很多网络带宽。
我们通常的动态网站编程，服务器端程序根本就不去处理浏览器发送过来的If-None-Match和If-Modified-Since状态标识，只要有请求就生成网页发送给浏览器。对于一般情况来说，用户不会总是没完没了刷新一个页面，所以大家并不认为这种基于资源的缓存有什么太大的作用，但实际情况并非如此：
比方说Google每天爬JavaEye网站大概15万次左右，但实际上JavaEye每天有更新的内容不会超过1万个网页。因为很多内容更新比较快，因此Google就会反复不停的爬取，这样本身就造成了很多资源的浪费。如果我们使用HTTP Cache，那么只有当网页内容发生改变的时候，才会真正进行爬取，其他时候我们直接告诉Google的爬虫304 Not Modified就可以了。这样不但降低了服务器本身的负载和爬虫造成的网络带宽消耗，实际上也大大提高了Google爬虫的工作效率，岂不是皆大欢喜？
比方说一些历史讨论帖子，已经过去了几个月了，这些帖子内容很少更新。用户可能通过搜索，收藏链接，文章关联等方式时不时访问到这个页面。那么只要用户访问过一次以后，后续所有访问服务器直接发送304 Not Modified就可以了，不用真正生成页面。
比方说JavaEye的论坛帖子列表页面，分页到20页后面的帖子已经很少有人直接访问了，但是从服务器日志去看，每天仍然有大量爬虫反复爬取这些分页到很后面的页面。这些页面由于用户很少去点击，所以基本上没有被应用程序的memcached缓存住，每次访问都会造成很高的资源消耗，爬虫隔一段时间就爬一次，对服务器是很大的负担。如果使用了HTTP Cache，那么只要爬虫爬过一次以后，以后无论爬虫爬多少次，都可以直接返回304 Not Modified了，极大的节省了服务器的负载。
如果我们要在自己的程序里面实现HTTP Cache，是件非常简单的事情，特别是对Rails来说只需要添加一点点代码，以上面的JavaEye新闻订阅来说，只要添加一行代码：
def news :News.:News.end用最新新闻文章作为Etag，该文章最后修改时间作为资源的最后修改时间，这样就OK了。如果浏览器发送过来的标识和服务器标识一致，说明内容没有更新，直接发送304 Not Modified；如果不一致，说明内容更新，浏览器本地的缓存太古老了，那么就需要服务器真正生成页面了。
以上只是一个最简单的例子，如果我们需要根据状态做一些更多的工作也是很容易的。比方说JavaEye博客的RSS订阅地址：?http://robbin.iteye.com/rss
@blogs = @blog_owner.@hash = @blogs.if :@blog_owner.@blog_owner.:@hash) :"rss/blog"end这个实现稍微复杂一些。我们需要判断博客订阅所有的输出文章是否有更新，所以我们用博客文章内容最后修改时间和博客的评论数量做一个hash，然后用这个hash值作为资源的Etag，那么只要这些博客文章当中任何文章内容被修改，或者有新评论，都会改变Etag值，从而通知浏览器内容有更新了。
除了RSS订阅之外，JavaEye网站还有很多地方适合使用HTTP Cache，比方说JavaEye论坛的版面列表页面，一些经常喜欢泡论坛的用户，可能时不时会上来刷新一下版面， 看看有没有新的帖子，那么我们就不必每次用户请求的时候都去执行程序，生成页面给他。我们判断一下如果没有新帖子的话，直接告诉他304 Not Modified就可以了，在没有使用HTTP Cache之前的版面Action代码：
def board @topics = @forum.@announcements = (:1).1 ? Topic.:::'show'end添加HTTP Cache以后，代码如下：
def board @topics = @forum.if :@topics[0].:@topics.@announcements = (:1).1 ? Topic.:::'show' endend对于登录用户，不使用HTTP Cache，这是因为登录用户需要实时接收站内短信通知和订阅通知，因此我们只能对匿名用户使用HTTP Cache，然后我们使用当前所有帖子id和回帖数构造hash作Etag，这样只要当前分页列表页面有任何帖子发生改变或者有了新回帖，就更新页面，否则就不必重新生成页面。
论坛帖子页面实际上也可以使用HTTP Cache，只不过Etag的hash算法稍微复杂一些，需要保证帖子的任何改动都要引起hash值的改变，示例代码如下：
def show @topic = Topic.:update_....... if Topic.if ...... @posts = @topic.:@posts.@topic.@topic.@topic.@topic.if :end end分别根据主题贴，该分页的所有回帖和帖子页面的广告内容进行hash，计算出来一个唯一的Etag值，保证任何改动都会生成新的Etag，这样就搞定了，是不是很简单！这种帖子的缓存非常有效，可以避免Rails去render页面和下载页面，极大的减轻了服务器负载和带宽。
再举一个需求比较特殊的例子：对于知识库搜索相关文章的推荐页面，比方说：http://www.iteye.com/wiki/topic/462476?也就是本文的相关文章推荐内容，我们并不希望用户和爬虫每次访问这个页面都实际执行一遍全文检索，然后构造页面内容，在一个相对不长的时间范围内，这篇文章的相关推荐文章改变的概率不大，因此我们希望比方说5天之内，用户重复访问该页面，就直接返回304 Not Modified，那么Rails没有直接的设施给我们使用，需要我们稍微了解一些Rails的机制，自己编写，代码示例如下：
def topic @topic = Topic.:unless if 5.:else Time.end endend 每次用户请求，我们判断用户是否5天之内访问过该页面，如果访问过，直接返回304 Not Modified，如果没有访问过，或者上次访问已经超过了5天，那么设置最近修改时间为当前时间，然后生成页面给用户。是不是很简单？
?