ORM緩存引言

從10年前的2003年開始，在Web應用領域，ORM(對象-關系映射)框架就開始逐漸普及，并且流行開來，其中最廣為人知的就是Java的開源ORM框架Hibernate，后來Hibernate也成為了EJB3的實現框架；2005年以后，ORM開始普及到其他編程語言領域，其中最有名氣的是Ruby on rails框架的ORM － ActiveRecord。如今各種開源框架的ORM，乃至ODM(對象-文檔關系映射，用在訪問NoSQLDB)層出不窮，功能都十分強大，也很普及。

然而圍繞ORM的性能問題，也一直有很多批評的聲音。其實ORM的架構對插入緩存技術是非常容易的，我做的很多項目和產品，但凡使用ORM，緩存都是標配，性能都非常好。而且我發現業界使用ORM的案例都忽視了緩存的運用，或者說沒有意識到ORM緩存可以帶來巨大的性能提升。

ORM緩存應用案例

我們去年有一個老產品重寫的項目，這個產品有超過10年歷史了，數據庫的數據量很大，多個表都是上千萬條記錄，最大的表記錄達到了9000萬條，Web訪問的請求數每天有300萬左右。

老產品采用了傳統的解決性能問題的方案：Web層采用了動態頁面靜態化技術，超過一定時間的文章生成靜態HTML文件；對數據庫進行分庫分表，按年拆表。動態頁面靜態化和分庫分表是應對大訪問量和大數據量的常規手段，本身也有效。但它的缺點也很多，比方說增加了代碼復雜度和維護難度，跨庫運算的困難等等，這個產品的代碼維護歷來非常困難，導致bug很多。

進行產品重寫的時候，我們放棄了動態頁面靜態化，采用了純動態網頁；放棄了分庫分表，直接操作千萬級，乃至近億條記錄的大表進行SQL查詢；也沒有采取讀寫分離技術，全部查詢都是在單臺主數據庫上進行；數據庫訪問全部使用ActiveRecord，進行了大量的ORM緩存。上線以后的效果非常好：單臺MySQL數據庫服務器CPU的IO Wait低于5%；用單臺1U服務器2顆4核至強CPU已經可以輕松支持每天350萬動態請求量；最重要的是，插入緩存并不需要代碼增加多少復雜度，可維護性非常好。

總之，采用ORM緩存是Web應用提升性能一種有效的思路，這種思路和傳統的提升性能的解決方案有很大的不同，但它在很多應用場景(包括高度動態化的SNS類型應用)非常有效，而且不會顯著增加代碼復雜度，所以這也是我自己一直偏愛的方式。因此我一直很想寫篇文章，結合示例代碼介紹ORM緩存的編程技巧。

今年春節前后，我開發自己的個人網站項目，有意識的大量使用了ORM緩存技巧。對一個沒多少訪問量的個人站點來說，有些過度設計了，但我也想借這個機會把常用的ORM緩存設計模式寫成示例代碼，提供給大家參考。我的個人網站源代碼是開源的，托管在github上：robbin_site

ORM緩存的基本理念

·我在2007年的時候寫過一篇文章，分析ORM緩存的理念：ORM對象緩存探討 ，所以這篇文章不展開詳談了，總結來說，ORM緩存的基本理念是：

·以減少數據庫服務器磁盤IO為最終目的，而不是減少發送到數據庫的SQL條數。實際上使用ORM，會顯著增加SQL條數，有時候會成倍增加SQL。

·數據庫schema設計的取向是盡量設計 細顆粒度 的表，表和表之間用外鍵關聯，顆粒度越細，緩存對象的單位越小，緩存的應用場景越廣泛

盡量避免多表關聯查詢，盡量拆成多個表單獨的主鍵查詢，盡量多制造 n + 1 條查詢，不要害怕“臭名昭著”的 n + 1 問題，實際上 n + 1 才能有效利用ORM緩存

利用表關聯實現透明的對象緩存

在設計數據庫的schema的時候，設計多個細顆粒度的表，用外鍵關聯起來。當通過ORM訪問關聯對象的時候，ORM框架會將關聯對象的訪問轉化成用主鍵查詢關聯表，發送 n + 1條SQL。而基于主鍵的查詢可以直接利用對象緩存。

我們自己開發了一個基于ActiveRecord封裝的對象緩存框架：second_level_cache ，從這個ruby插件的名稱就可以看出，實現借鑒了Hibernate的二級緩存實現。這個對象緩存的配置和使用，可以看我寫的ActiveRecord對象緩存配置 。

下面用一個實際例子來演示一下對象緩存起到的作用：訪問我個人站點的首頁。 這個頁面的數據需要讀取三張表：blogs表獲取文章信息，blog_contents表獲取文章內容，accounts表獲取作者信息。三張表的model定義片段如下，完整代碼請看models ：

class Account < ActiveRecord::Base  
  acts_as_cached  
  has_many :blogs  
end 
 
class Blog < ActiveRecord::Base  
  acts_as_cached  
  belongs_to :blog_content, :dependent => :destroy   
  belongs_to :account, :counter_cache => true 
end 
 
class BlogContent < ActiveRecord::Base  
  acts_as_cached  
end 

傳統的做法是發送一條三表關聯的查詢語句，類似這樣的：

SELECT blogs.*, blog_contents.content, account.name   
    FROM blogs   
    LEFT JOIN blog_contents ON blogs.blog_content_id = blog_contents.id   
    LEFT JOIN accounts ON blogs.account_id = account.id  

往往單條SQL語句就搞定了，但是復雜SQL的帶來的表掃描范圍可能比較大，造成的數據庫服務器磁盤IO會高很多，數據庫實際IO負載往往無法得到有效緩解。

我的做法如下，完整代碼請看home.rb ：

@blogs = Blog.order('id DESC').page(params[:page]) 

這是一條分頁查詢，實際發送的SQL如下：

SELECT * FROM blogs ORDER BY id DESC LIMIT 20 

轉成了單表查詢，磁盤IO會小很多。至于文章內容，則是通過blog.content的對象訪問獲得的，由于首頁抓取20篇文章，所以實際上會多出來20條主鍵查詢SQL訪問blog_contents表。就像下面這樣：

DEBUG -  BlogContent Load (0.3ms)  SELECT `blog_contents`.* FROM `blog_contents` WHERE `blog_contents`.`id` = 29 LIMIT 1  
DEBUG -  BlogContent Load (0.2ms)  SELECT `blog_contents`.* FROM `blog_contents` WHERE `blog_contents`.`id` = 28 LIMIT 1  
DEBUG -  BlogContent Load (1.3ms)  SELECT `blog_contents`.* FROM `blog_contents` WHERE `blog_contents`.`id` = 27 LIMIT 1  
......  
DEBUG -  BlogContent Load (0.9ms)  SELECT `blog_contents`.* FROM `blog_contents` WHERE `blog_contents`.`id` = 10 LIMIT 1 

但是主鍵查詢SQL不會造成表的掃描，而且往往已經被數據庫buffer緩存，所以基本不會發生數據庫服務器的磁盤IO，因而總體的數據庫IO負載會遠遠小于前者的多表聯合查詢。特別是當使用對象緩存之后，會緩存所有主鍵查詢語句，這20條SQL語句往往并不會全部發生，特別是熱點數據，緩存命中率很高：

DEBUG -  Cache read: robbin/blog/29/1  
DEBUG -  Cache read: robbin/account/1/0  
DEBUG -  Cache read: robbin/blogcontent/29/0  
DEBUG -  Cache read: robbin/account/1/0  
DEBUG -  Cache read: robbin/blog/28/1  
......  
DEBUG -  Cache read: robbin/blogcontent/11/0  
DEBUG -  Cache read: robbin/account/1/0  
DEBUG -  Cache read: robbin/blog/10/1  
DEBUG -  Cache read: robbin/blogcontent/10/0  
DEBUG -  Cache read: robbin/account/1/0  

拆分n+1條查詢的方式，看起來似乎非常違反大家的直覺，但實際上這是真理，我實踐經驗證明：數據庫服務器的瓶頸往往是磁盤IO，而不是SQL并發數量。因此 拆分n+1條查詢本質上是以增加n條SQL語句為代價，簡化復雜SQL，換取數據庫服務器磁盤IO的降低 當然這樣做以后，對于ORM來說，有額外的好處，就是可以高效的使用緩存了。

#p#

按照column拆表實現細粒度對象緩存

數據庫的瓶頸往往在磁盤IO上，所以應該盡量避免對大表的掃描。傳統的拆表是按照row去拆分，保持表的體積不會過大，但是缺點是造成應用代碼復雜度很高；使用ORM緩存的辦法，則是按照column進行拆表，原則一般是：

·將大字段拆分出來，放在一個單獨的表里面，表只有主鍵和大字段，外鍵放在主表當中

·將不參與where條件和統計查詢的字段拆分出來，放在獨立的表中，外鍵放在主表當中

按照column拆表本質上是一個去關系化的過程。主表只保留參與關系運算的字段，將非關系型的字段剝離到關聯表當中，關聯表僅允許主鍵查詢，以Key-Value DB的方式來訪問。因此這種緩存設計模式本質上是一種SQLDB和NoSQLDB的混合架構設計

下面看一個實際的例子：文章的內容content字段是一個大字段，該字段不能放在blogs表中，否則會造成blogs表過大，表掃描造成較多的磁盤IO。我實際做法是創建blog_contents表，保存content字段，schema簡化定義如下：

CREATE TABLE `blogs` (  
  `id` int(11) NOT NULL AUTO_INCREMENT,  
  `title` varchar(255) NOT NULL,  
  `blog_content_id` int(11) NOT NULL,  
  `content_updated_at` datetime DEFAULT NULL,  
  PRIMARY KEY (`id`),  
);  
 
CREATE TABLE `blog_contents` (  
  `id` int(11) NOT NULL AUTO_INCREMENT,  
  `content` mediumtext NOT NULL,  
  PRIMARY KEY (`id`)  
); 

blog_contents表只有content大字段，其外鍵保存到主表blogs的blog_content_id字段里面。

model定義和相關的封裝如下：

class Blog < ActiveRecord::Base  
  acts_as_cached  
  delegate :content, :to => :blog_content, :allow_nil => true 
 
  def content=(value)  
    self.blog_content ||= BlogContent.new  
    self.blog_content.content = value  
    self.content_updated_at = Time.now  
  end 
end 
 
class BlogContent < ActiveRecord::Base  
  acts_as_cached  
  validates :content, :presence => true 
end      

在Blog類上定義了虛擬屬性content，當訪問blog.content的時候，實際上會發生一條主鍵查詢的SQL語句，獲取blog_content.content內容。由于BlogContent上面定義了對象緩存acts_as_cached，只要被訪問過一次，content內容就會被緩存到memcached里面。

這種緩存技術實際會非常有效，因為： 只要緩存足夠大，所有文章內容可以全部被加載到緩存當中，無論文章內容表有多么大，你都不需要再訪問數據庫了 更進一步的是： 這張大表你永遠都只需要通過主鍵進行訪問，絕無可能出現表掃描的狀況 為何當數據量大到9000萬條記錄以后，我們的系統仍然能夠保持良好的性能，秘密就在于此。

還有一點非常重要： 使用以上兩種對象緩存的設計模式，你除了需要添加一條緩存聲明語句acts_as_cached以外，不需要顯式編寫一行代碼 有效利用緩存的代價如此之低，何樂而不為呢？

以上兩種緩存設計模式都不需要顯式編寫緩存代碼，以下的緩存設計模式則需要編寫少量的緩存代碼，不過代碼的增加量非常少。

寫一致性緩存

寫一致性緩存，叫做write-through cache，是一個CPU Cache借鑒過來的概念，意思是說，當數據庫記錄被修改以后，同時更新緩存，不必進行額外的緩存過期處理操作。但在應用系統中，我們需要一點技巧來實現寫一致性緩存。來看一個例子：

我的網站文章原文是markdown格式的，當頁面顯示的時候，需要轉換成html的頁面，這個轉換過程本身是非常消耗CPU的，我使用的是Github的markdown的庫。Github為了提高性能，用C寫了轉換庫，但如果是非常大的文章，仍然是一個耗時的過程，Ruby應用服務器的負載就會比較高。

我的解決辦法是緩存markdown原文轉換好的html頁面的內容，這樣當再次訪問該頁面的時候，就不必再次轉換了，直接從緩存當中取出已經緩存好的頁面內容即可，極大提升了系統性能。我的網站文章最終頁的代碼執行時間開銷往往小于10ms，就是這個原因。代碼如下：

def md_content  # cached markdown format blog content  
  APP_CACHE.fetch(content_cache_key) { GitHub::Markdown.to_html(content, :gfm) }  
end 

這里存在一個如何進行緩存過期的問題，當文章內容被修改以后，應該更新緩存內容，讓老的緩存過期，否則就會出現數據不一致的現象。進行緩存過期處理是比較麻煩的，我們可以利用一個技巧來實現自動緩存過期：

def content_cache_key  
  "#{CACHE_PREFIX}/blog_content/#{self.id}/#{content_updated_at.to_i}" 
end 

當構造緩存對象的key的時候，我用文章內容被更新的時間來構造key值，這個文章內容更新時間用的是blogs表的content_updated_at字段，當文章被更新的時候，blogs表會進行update，更新該字段。因此每當文章內容被更新，緩存的頁面內容的key就會改變，應用程序下次訪問文章頁面的時候，緩存就會失效，于是重新調用GitHub::Markdown.to_html(content, :gfm)生成新的頁面內容。 而老的頁面緩存內容再也不會被應用程序存取，根據memcached的LRU算法，當緩存填滿之后，將被優先剔除。

除了文章內容緩存之外，文章的評論內容轉換成html以后也使用了這種緩存設計模式。具體可以看相應的源代碼：blog_comment.rb

#p#

片段緩存和過期處理

Web應用當中有大量的并非實時更新的數據，這些數據都可以使用緩存，避免每次存取的時候都進行數據庫查詢和運算。這種片段緩存的應用場景很多，例如：

·展示網站的Tag分類統計(只要沒有更新文章分類，或者發布新文章，緩存一直有效)

·輸出網站RSS(只要沒有發新文章，緩存一直有效)

·網站右側欄(如果沒有新的評論或者發布新文章，則在一段時間例如一天內基本不需要更新)

以上應用場景都可以使用緩存，代碼示例：

def self.cached_tag_cloud  
  APP_CACHE.fetch("#{CACHE_PREFIX}/blog_tags/tag_cloud") do  
    self.tag_counts.sort_by(&:count).reverse  
  end 
end 

對全站文章的Tag云進行查詢，對查詢結果進行緩存

<% cache("#{CACHE_PREFIX}/layout/right", :expires_in => 1.day) do %> 
 
<div class="tag"> 
  <% Blog.cached_tag_cloud.select {|t| t.count > 2}.each do |tag| %> 
  <%= link_to "#{tag.name}<span>#{tag.count}</span>".html_safe, url(:blog, :tag, :name => tag.name) %> 
  <% end %> 
</div> 
......  
<% end %> 

對全站右側欄頁面進行緩存，過期時間是1天。

緩存的過期處理往往是比較麻煩的事情，但在ORM框架當中，我們可以利用model對象的回調，很容易實現緩存過期處理。我們的緩存都是和文章，以及評論相關的，所以可以直接注冊Blog類和BlogComment類的回調接口，聲明當對象被保存或者刪除的時候調用刪除方法：

class Blog < ActiveRecord::Base 
  acts_as_cached  
  after_save :clean_cache  
  before_destroy :clean_cache  
  def clean_cache  
    APP_CACHE.delete("#{CACHE_PREFIX}/blog_tags/tag_cloud")   # clean tag_cloud  
    APP_CACHE.delete("#{CACHE_PREFIX}/rss/all")               # clean rss cache  
    APP_CACHE.delete("#{CACHE_PREFIX}/layout/right")          # clean layout right column cache in _right.erb  
  end  
end  
 
class BlogComment < ActiveRecord::Base 
  acts_as_cached  
  after_save :clean_cache  
  before_destroy :clean_cache  
  def clean_cache  
    APP_CACHE.delete("#{CACHE_PREFIX}/layout/right")     # clean layout right column cache in _right.erb  
  end  
end    

在Blog對象的after_save和before_destroy上注冊clean_cache方法，當文章被修改或者刪除的時候，刪除以上緩存內容。總之，可以利用ORM對象的回調接口進行緩存過期處理，而不需要到處寫緩存清理代碼。

對象寫入緩存

我們通常說到緩存，總是認為緩存是提升應用讀取性能的，其實緩存也可以有效的提升應用的寫入性能。我們看一個常見的應用場景：記錄文章點擊次數這個功能。

文章點擊次數需要每次訪問文章頁面的時候，都要更新文章的點擊次數字段view_count，然后文章必須實時顯示文章的點擊次數，因此常見的讀緩存模式完全無效了。每次訪問都必須更新數據庫，當訪問量很大以后數據庫是吃不消的，因此我們必須同時做到兩點：

·每次文章頁面被訪問，都要實時更新文章的點擊次數，并且顯示出來

·不能每次文章頁面被訪問，都更新數據庫，否則數據庫吃不消

對付這種應用場景，我們可以利用對象緩存的不一致，來實現對象寫入緩存。原理就是每次頁面展示的時候，只更新緩存中的對象，頁面顯示的時候優先讀取緩存，但是不更新數據庫，讓緩存保持不一致，積累到n次，直接更新一次數據庫，但繞過緩存過期操作。具體的做法可以參考blog.rb ：

# blog viewer hit counter  
def increment_view_count  
  increment(:view_count)        # add view_count += 1  
  write_second_level_cache      # update cache per hit, but do not touch db  
                                # update db per 10 hits  
  self.class.update_all({:view_count => view_count}, :id => id) if view_count % 10 == 0  
end 

increment(:view_count)增加view_count計數，關鍵代碼是第2行write_second_level_cache，更新view_count之后直接寫入緩存，但不更新數據庫。累計10次點擊，再更新一次數據庫相應的字段。另外還要注意，如果blog對象不是通過主鍵查詢，而是通過查詢語句構造的，要優先讀取一次緩存，保證頁面點擊次數的顯示一致性，因此 _blog.erb 這個頁面模版文件開頭有這樣一段代碼：

<%   
  # read view_count from model cache if model has been cached.  
  view_count = blog.view_count  
  if b = Blog.read_second_level_cache(blog.id)  
    view_count = b.view_count  
  end 
%>  

采用對象寫入緩存的設計模式，就可以非常容易的實現寫入操作的緩存，在這個例子當中，我們僅僅增加了一行緩存寫入代碼，而這個時間開銷大約是1ms，就可以實現文章實時點擊計數功能，是不是非常簡單和巧妙？實際上我們也可以使用這種設計模式實現很多數據庫寫入的緩存功能。

常用的ORM緩存設計模式就是以上的幾種，本質上都是非常簡單的編程技巧，代碼的增加量和復雜度也非常低，只需要很少的代碼就可以實現，但是在實際應用當中，特別是當數據量很龐大，訪問量很高的時候，可以發揮驚人的效果。我們實際的系統當中，緩存命中次數:SQL查詢語句，一般都是5:1左右，即每次向數據庫查詢一條SQL，都會在緩存當中命中5次，數據主要都是從緩存當中得到，而非來自于數據庫了。

其他緩存的使用技巧

還有一些并非ORM特有的緩存設計模式，但是在Web應用當中也比較常見，簡單提及一下：

用數據庫來實現的緩存

在我這個網站當中，每篇文章都標記了若干tag，而tag關聯關系都是保存到數據庫里面的，如果每次顯示文章，都需要額外查詢關聯表獲取tag，顯然會非常消耗數據庫。在我使用的acts-as-taggable-on插件中，它在blogs表當中添加了一個cached_tag_list字段，保存了該文章標記的tag。當文章被修改的時候，會自動相應更新該字段，避免了每次顯示文章的時候都需要去查詢關聯表的開銷。

HTTP客戶端緩存

基于資源協議實現的HTTP客戶端緩存也是一種非常有效的緩存設計模式，我在2009年寫過一篇文章詳細的講解了：基于資源的HTTP Cache的實現介紹 ，所以這里就不再復述了。

用緩存實現計數器功能

這種設計模式有點類似于對象寫入緩存，利用緩存寫入的低開銷來實現高性能計數器。舉一個例子：用戶登錄為了避免遭遇密碼暴力破解，我限定了每小時每IP只能嘗試登錄5次，如果超過5次，拒絕該IP再次嘗試登錄。代碼實現很簡單，如下：

post :login, :map => '/login' do  
  login_tries = APP_CACHE.read("#{CACHE_PREFIX}/login_counter/#{request.ip}")  
  halt 403 if login_tries && login_tries.to_i > 5  # reject ip if login tries is over 5 times  
  @account = Account.new(params[:account])  
  if login_account = Account.authenticate(@account.email, @account.password)  
    session[:account_id] = login_account.id  
    redirect url(:index)  
  else 
    # retry 5 times per one hour 
    APP_CACHE.increment("#{CACHE_PREFIX}/login_counter/#{request.ip}", 1, :expires_in => 1.hour)  
    render 'home/login' 
  end 
end 

等用戶POST提交登錄信息之后，先從緩存當中取該IP嘗試登錄次數，如果大于5次，直接拒絕掉；如果不足5次，而且登錄失敗，計數加1，顯示再次嘗試登錄頁面。

以上相關代碼可以從這里獲取：robbin_site

原文鏈接：http://robbinfan.com/blog/38/orm-cache-sumup