专栏首页互联网杂技总结Web应用中常用的各种Cache

总结Web应用中常用的各种Cache

cache是提高应用性能重要的一个环节,写篇文章总结一下用过的各种对于动态内容的cache。

文章以Nginx,Rails,Mysql,Redis作为例子,换成其他web服务器,语言,数据库,缓存服务都是类似的。

以下是3层的示意图,方便后续引用:

1.客户端缓存

一个客户端经常会访问同一个资源,比如用浏览器访问网站首页或查看同一篇文章,或用app访问同一个api,如果该资源和他之前访问过的没有任何改变,就可以利用http规范中的304 Not Modified 响应头(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 ),直接用客户端的缓存,而无需在服务器端再生成一次内容。

在Rails里面内置了fresh_when这个方法,一行代码就可以完成:

class ArticlesController
  def show
    @article = Article.find(params[:id])
    fresh_when :last_modified => @article.updated_at.utc, :etag => @article
  endend

下次用户再访问的时候,会对比request header里面的If-Modified-Since和If-None-Match,如果相符合,就直接返回304,而不再生成response body。

但是这样会遇到一个问题,假设我们的网站导航有用户信息,一个用户在未登陆专题访问了一下,然后登陆以后再访问,会发现页面上显示的还是未登陆状态。或者在app访问一篇文章,做了一下收藏,下次再进入这篇文章,还是显示未收藏状态。解决这个问题的方法很简单,将用户相关的变量也加入到etag的计算里面:

 fresh_when :etag => [@article.cache_key, current_user.id]
    fresh_when :etag => [@article.cache_key, current_user_favorited]

另外提一个坑,如果nginx开启了gzip,对rails执行的结果进行压缩,会将rails输出的etag header干掉,nginx的开发人员说根据rfc规范,对proxy_pass方式处理必须这样(因为内容改变了),但是我个人认为没这个必要,于是用了粗暴的方法,直接将src/http/modules/ngx_http_gzip_filter_module.c这个文件里面的这行代码注释掉,然后重新编译nginx:

  //ngx_http_clear_etag(r);

或者你可以选择不改变nginx源代码,将gzip off掉,将压缩用Rack中间件来处理:

config.middleware.use Rack::Deflater

除了在controller里面指定fresh_when以外,rails框架默认使用Rack::ETag middleware,它会自动给无etag的response加上etag,但是和fresh_when相比,自动etag能够节省的只是客户端时间,服务器端还是一样会执行所有的代码,用curl来对比一下。

Rack::ETag自动加入etag:

curl -v http://localhost:3000/articles/1
< Etag: "bf328447bcb2b8706193a50962035619"
< X-Runtime: 0.286958
curl -v http://localhost:3000/articles/1 --header 'If-None-Match: "bf328447bcb2b8706193a50962035619"'
< X-Runtime: 0.293798

用fresh_when:

curl -v http://localhost:3000/articles/1 --header 'If-None-Match: "bf328447bcb2b8706193a50962035619"'
< X-Runtime: 0.033884

2. Nginx缓存

有一些资源可能会被调用很多,又无关用户状态,并且很少改变,比如新闻app上的列表api,购物网站上ajax请求分类菜单,可以考虑用Nginx来做缓存。

主要有2种实现方法:

A. 动态请求静态文件化

在rails请求完成以后,将结果保存成静态文件,后续请求就会直接由nginx提供静态文件内容,用after_filter来实现一下:

class CategoriesController < ActionController::Base
  after_filter :generate_static_file, :only => [:index]

  def index
    @categories = Category.all
  end

  def generate_static_file
    File.open(Rails.root.join('public', 'categories'), 'w') do |f|
      f.write response.body
    end
  endend

另外我们需要在任何分类更新的时候,删除掉这个文件,避免缓存不刷新的问题:

class Category < ActiveRecord::Base
  after_save :delete_static_file
  after_destroy :delete_static_file

  def delete_static_file
    File.delete Rails.root.join('public', 'categories')
  endend

Rails 4之前,处理这种生成静态文件缓存可以用内置的caches_page, rails 4之后变成了一个独立gem actionpack-page_caching,和手工代码对比一下,

class CategoriesController < ActionController::Base
  caches_page :index

  def update
    #...
    expire_page action: 'index'
  endend

如果只有一台服务器,这个方法简单又实用,但是如果有多台服务器,就会出现更新分类只能刷新自己本身这台服务器缓存的问题,可以用nfs来共享静态资源目录解决,或者用第2种:

B. 静态化到集中缓存服务

首先我们得让Nginx有直接访问缓存的能力:

upstream redis {
    server redis_server_ip:6379;
  }

  upstream ruby_backend {
    server unicorn_server_ip1 fail_timeout=0;
    server unicorn_server_ip2 fail_timeout=0;
  }

  location /categories {
    set $redis_key $uri;
    default_type   text/html;
    redis_pass redis;
    error_page 404 = @httpapp;
  }

  location @httpapp {
    proxy_pass http://ruby_backend;
  }

Nginx首先会用请求的uri作为key去redis里面获取,如果获取不到(404)就转发给unicorn进行处理,然后改写generate_static_file和delete_static_file方法:

redis_cache.set('categories', response.body)
  redis_cache.del('categories')

这样除了集中管理以外,还能够设置缓存的失效时间,对于一些更新无时效性要求的数据,就可以不用处理刷新机制,简单地固定时间刷新一次:

 redis_cache.setex('categories', 3.hours.to_i, response.body)

3. 整页缓存

Nginx缓存在处理带参数资源或者有用户状态的请求时候,就非常难以处理,这个时候可以用到整页缓存。

比如说分页请求列表,我们可以将page参数加入到cache_path:

class CategoriesController
  caches_action :index, :expires_in => 1.day, :cache_path => proc {"categories/index/#{params[:page].to_i}"}end

比如说我们只需要针对rss输出进行缓存8小时:

class ArticlesController
  caches_action :index, :expires_in => 8.hours, :if => proc {request.format.rss?}end

再比如说对于非登陆用户,我们可以缓存首页:

class HomeController
  caches_action :index, :expires_in => 3.hours, :if => proc {!user_signed_in?}end

4. 片段缓存

如果说前面2种缓存能够用到的场景有限,那么片段缓存是适用性最广的。

场景1:我们需要在每个页面一段广告代码,用来显示不同广告,如果没有使用片段缓存,那么每个页面都会要去查询广告的代码,并且花费一定时间去生成html代码:

- if advert = Advert.where(:name => request.controller_name + request.action_name, :enable => true).first
  div.ad
    = advert.content

加了片段缓存以后,就可以少去这个查询:

- cache "adverts/#{request.controller_name}/#{request.action_name}", :expires_in => 1.day do
  - if advert = Advert.where(:name => request.controller_name + request.action_name, :enable => true).first
    div.ad
      = advert.content

场景2:阅读文章,文章的内容可能比较长时间都不会改变,经常变化可能是文章评论,就可以对文章主体部分加上片段缓存:

- cache "articles/#{@article.id}/#{@article.updated_at.to_i}" do
  div.article
    = @article.content.markdown2html

节约了生成markdown语法转换到html时间,这里用文章最后更新时间作为cache key的一部分,文章内容如果有改变,缓存自动失效,默认activerecord的cache_key方法也是用updated_at,你也可以加入更多的参数,比如article上有评论数的counter cache,更新评论数的时候不会更新文章时间,可以将这个counter也加入到key的一部分

场景3:复杂页面结构的生成

数据结构比较复杂的页面,在生成的时候避免不了大量的查询和html渲染,用片段缓存,可以将这部分时间大大地节约,以我们网站游记页面 http://chanyouji.com/trips/109123 (请允许小小地打个广告,带点流量)来说:

需要获取天气数据,照片数据,文本数据等,同时还要生成meta,keyword等seo数据,而这些内容又是和其他动态内容交叉,片段缓存就可以分开多个:

- cache "trips/show/seo/#{@trip.fragment_cache_key}", :expires_in => 1.day do
  title #{trip_name @trip}
  meta name="description" content="..."
  meta name="keywords" content="..."

body
  div
    ...
- cache "trips/show/viewer/#{@trip.fragment_cache_key}", :expires_in => 1.day do
  - @trip.eager_load_all

小贴士,我在trip对象里面加了一个eager_load_all方法,缓存没有命中的时候,查询的时候避免出现n+1问题:

def eager_load_all
    ActiveRecord::Associations::Preloader.new([self], {:trip_days => [:weather_station_data, :nodes => [:entry, :notes => [:photo, :video, :audio]]]}).run
  end

小技巧1:带条件的片段缓存

和caches_action不同,rails自带的片段缓存是不支持条件的,比如说我们想未登陆用户给他用片段缓存,而登陆用户不使用,写起来就很麻烦,我们可以改写一下helper就可以了:

 def cache_if (condition, name = {}, cache_options = {}, &block)
    if condition
      cache(name, cache_options, &block)
    else
      yield
    end
  end- cache_if !user_signed_in?, "xxx", :expires_in => 1.day do

小技巧2:关联对象的自动更新

常使用对象update_at时间戳来作为cache key,可以在关联对象上加上touch选项,自动更新关联对象时间戳,比如我们可以在更新或者删除文章评论的时候,自动个更新:

class Article
  has_many :commentsendclass Comment
  belongs_to :article, :touch => trueend

5. 数据查询缓存

通常来说web应用性能瓶颈都出现在DB IO上,做好数据查询缓存,减少数据库的查询次数,可以极大提高整体响应时间。

数据查询缓存分2种:

A. 同一个请求周期内的缓存

举一个显示文章列表的例子,输出文章标题和文章类别,对应代码如下

# controller
  def index
    @articles = Article.first(10)
  end# view- @articles.each do |article|
  h1 = article.name
  span = article.category.name

会发生10条类似的sql查询:

SELECT `categories`.* FROM `categories` WHERE `categories`.`id` = ?

rails内置了query cache (https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb ),在同一个请求周期内,如果没有update/delete/insert的操作,会对相同的sql查询进行缓存,如果文章类别都是相同的话,真正去查询数据库只会有1次。

如果文章类别都不一样,就会出现N+1查询问题(常见的性能瓶颈),rails推荐的解决方法是用Eager Loading Associations ( http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations )

def index
    @articles = Article.includes(:category).first(10)
  end

查询语句会变成

SELECT `categories`.* FROM `categories` WHERE `categories`.`id` in (?,?,?...)

B. 跨请求周期的缓存

同请求周期缓存所带来性能优化是很有限的,很多时候我们需要用跨请求周期的缓存,将一些常用的数据(比如User model)缓存,对于active record来说,利用统一的查询接口来fetch cache,利用callback来expire cache,就很容易实现,而且有一些现成的gem可以来用。

比如说 identity_cache ( https://github.com/Shopify/identity_cache )

class User < ActiveRecord::Base
  include IdentityCacheendclass Article < ActiveRecord::Base
  include IdentityCache
  cached_belongs_to :userend# 都会命中缓存User.fetch(1)Article.find(2).user

这个gem的优点是代码实现简单,cache设置灵活,也方便扩展,缺点是需要用不同的查询方法名(fetch),以及额外的关系定义。

如果想在无数据缓存的应用无缝加入缓存功能,推荐@hooopo 做的second_level_cache (https://github.com/hooopo/second_level_cache ) 。

class User < ActiveRecord::Base
  acts_as_cached(:version => 1, :expires_in => 1.week)end#还是使用find方法,就会命中缓存User.find(1)#无需额外用不一样的belongs_to定义Article.find(2).user

实现原理是扩展了active record底层arel sql ast处理 (https://github.com/hooopo/second_level_cache/blob/master/lib/second_level_cache/arel/wheres.rb )

它的优点是无缝接入,缺点是扩展比较困难,对于只获取少量字段的查询无法缓存。

本文分享自微信公众号 - 交互设计前端开发与后端程序设计(interaction_Designer),作者:json

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-07-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 通俗讲解:缓存、缓存算法和缓存框架

    1 引言 我们都听过 cache,当你问他们是什么是缓存的时候,他们会给你一个完美的答案,可是他们不知道缓存是怎么构建的,或者没有告诉你应该采用什么标准去选择缓...

    前朝楚水
  • 如何做出优雅的搜索功能?

    前言 搜索从宏观上来看有两种,一种是搜索引擎,另一种是垂直搜索。搜索引擎有 Google,Bing,百度,搜狗等等,而垂直搜索则是在大多数产品内置的对内容的检...

    前朝楚水
  • JS编程小常识很有用

    2.JS中的真真假假 空,null,undefined,false,0,””,'',NaN都为假,其他都为真 3.函数,类,对象,构造器有什么区别? 答:...

    前朝楚水
  • 国内一个款不错的二级缓存框架J2Cache

    缓存技术在软件开发中已经无处不在,今天分享一款国内开源的相当不错的缓存框架J2Cache 。J2Cache 是 OSChina 目前正在使用的两级缓存框架(要求...

    java乐园
  • 架构学习之路——高可用高并发系统设计原则

    墨菲定律 - 任何事没有表面看起来那么简单 - 所有的事都会比预计的时间长 - 可能出错的事情总会出错 - 担心某种事情发生,那么它就更有可能发生

    博文视点Broadview
  • HTTP缓存

    P.S.关于HTTP Header的更多信息,请查看4.2 Message Headers

    ayqy贾杰
  • 玩转Spring Cache --- 整合进程缓存之王Caffeine Cache和Ehcache3.x【享学Spring】

    前面文章大篇幅详细讲解了Spring Cache缓存抽象、三大缓存注解的工作原理等等。若是细心的小伙伴会发现:讲解时的Demo我使用的缓存实现方案均是Sprin...

    YourBatman
  • LevelDB 完全解析(5):Cache

    在 LevelDB 中,block cache 和 table cache 都是基于 ShardedLRUCache 实现的。

    linjinhe
  • 【译】CPU 高速缓存原理和应用

    曾三次获得 F1 世界冠军的杰基•斯图尔特 (Jackie Stewart) 表示,了解汽车的工作原理让他成为了一名更好的驾驶员。

    潘少
  • 我接手了一个“垃圾”系统,全栈优化后将性能提升了350倍

    我所在的前一家公司构建了一个大规模捐赠和支付软件系统,在一些盛大的节日里,我们一次活动中就会收到成千上万笔捐款。我在那家公司的其中一项职责就是扩展这个系统,确保...

    深度学习与Python

扫码关注云+社区

领取腾讯云代金券