Rails 集合缓存优化实践

flydragon · 2019年01月27日 · 最后由 flydragon 回复于 2019年01月31日 · 1016 次阅读

场景

对获取列表的api接口进行集合缓存,假设获取前10条文章列表。

优化前

关键代码

# model
class Article
  include Mongoid::Document
  include Mongoid::Timestamps

  field :title, type: String
  field :content, type: String
end

# controller
class ArticlesController < Api::BaseController
   def index
      @articles = Article.order_by(id: :asc).limit(10)
   end
end

# view
json.cache! [@articles] do
  json.articles @articles do |article|
    json.call(article, :title, :content)
  end
end

调起api的数据库log

# 第一次调用api
MONGODB | localhost:27017 | _development.find | STARTED | {"find"=>"articles", "filter"=>{}, "limit"=>10, "sort"=>{"id"=>1}}
# 第二次调用api
MONGODB | localhost:27017 | _development.find | STARTED | {"find"=>"articles", "filter"=>{}, "limit"=>10, "sort"=>{"id"=>1}}

优化后

关键代码

# 处理类数据的缓存键(新增)
module ClassDataCacheKeyAble
  extend ActiveSupport::Concern

  included do
    after_create do
      self.class.refresh_class_cache_version
    end

    after_update do
      self.class.refresh_class_cache_version
    end

    after_destroy do
      self.class.refresh_class_cache_version
    end
  end

  class_methods do
    def cache_key_with_version
      "#{cache_key}-#{cache_version}"
    end

    def cache_version
      Redis::Counter.new("class_cache_version:#{cache_key}").value
    end

    def refresh_class_cache_version
      Redis::Counter.new("class_cache_version:#{cache_key}").increment
    end

    def cache_key
      name.tableize
    end
  end
end

# model调整
class Article
  include Mongoid::Document
  include Mongoid::Timestamps
  include ClassDataCacheKeyAble # 引入模块

  field :title, type: String
  field :content, type: String
end

# view调整
json.cache! [Article] do
  json.articles @articles do |article|
    json.call(article, :title, :content)
  end
end

调起api的数据库log

# 第一次调用api
MONGODB | localhost:27017 | _development.find | STARTED | {"find"=>"articles", "filter"=>{}, "limit"=>10, "sort"=>{"id"=>1}}
# 第二次调用api,没有查询数据库

总结

相对优化前,减少了一次数据的列表查询,但多了一次获取全局更新键的redis查询,总体下来性能还是很好的,本地简单测试了一下近两倍左右,随着数据库数量的增加,优化空间会更大。

适用场景:模型总体数据变化不大,例子仅说明问题使用。

大家有没什么更好的方案,欢迎留言指正。

共收到 8 条回复

查询量大的话,稍微增删改article就会可能雪崩?

应该不会,即使缓存失效,也只会查询一次数据库。 相交优化前,好很多,优化前不论数据是否修改每次都会查询数据库。

为什么不直接用Rails.cache的cache_key_with_version

w7938940 回复

怎么用?展示你的code

Rails 5 已经有 collection cache, jbuilder 也有 collection cache

不使用 jbuilder_cache_multi,适用于增删改不频繁,缓存整个集合

json.cache! @user1 do
  json.partial!  'article', collection: @user2, as: :article
end

使用 jbuilder_cache_multi,缓存每个对象

json.cache_collection! @user3 do |article|
  json.partial! 'article', article: article
end

如果对象支持 cache_key 方法就用 cache_key 做缓存的 key,获取的时候使用 Rails.cache.fetch_multi

我代码里面都用的 @articles,显示出来出错了

w7938940 回复

这个优化主要解决的就是,当集合数据没有变化的时候,不需要查询数据库。 你可以试一下你的demo,即时集合数据中的数据没有任何变化,但是为了生成集合缓存键,他还会进行查询数据库。

w7938940 回复

还有为了复用cache_key,为以后缓存优化做准备,引入了cache_key_with_versioncache_version,代码已修改

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册