摘要：這三行代碼，則是在緩存命中時，直接讀取緩存內(nèi)容并且返回。通過上面的源碼分析，我們可以知道，當(dāng)緩存失效時，方法會直接將其代碼塊中的代碼的返回值不加判斷地寫入緩存，并且返回該返回值。

Rails 中的 active_support 組件主要基于 Rails 需要提供了很多非常有用的基礎(chǔ)工具以及對 Ruby 內(nèi)置類進行擴展。其中的 cache 模塊主要提供了 Rails 中底層緩存的定義以及簡單實現(xiàn)。今天要跟大家探討的是之前在使用此模塊所遇到的一個坑，有興趣學(xué)習(xí)其基本用法的可以點擊以下兩個鏈接：

Rails Guides: ActiveSupport::Cache::Store

Rails API: ActiveSupport::Cache::Store

之前在實現(xiàn)一個需要從外部服務(wù)請求數(shù)據(jù)的功能時，處于性能考慮，我在代碼中使用了緩存，并且設(shè)置緩存失效時間為 7 天，示例代碼如下：

def read_external_service(params)
  # 這段代碼稍微解釋下：
  #   當(dāng)緩存命中時，則直接讀取緩存，如果無期待緩存，則通過 HTTP 向外請求結(jié)果，并且將結(jié)果
  #   緩存下來，這樣子，當(dāng)下次繼續(xù)調(diào)用時，則可直接返回緩存內(nèi)容，而無需重復(fù)向外請求
  #
  Rails.cache.fetch "example_cache_key_here", expires_in: 7.days do
    response = HTTParty.get "https://example.com/example/request/path"
    JSON.parse(response.body)["data"]
  end
end

上面的代碼其實不復(fù)雜，核心代碼就是使用了 ActiveSupport::Cache::Store#fetch 方法。

一切都很正常地運行著，直到有一天，線上系統(tǒng)不斷報警，出錯原因就是這段代碼總是返回 nil ，而調(diào)用者又因為沒有判斷 nil 值，就會出現(xiàn) undefined method "xxx" for nil:NilClass 錯誤。在 debug 時，我嘗試了直接調(diào)用外部服務(wù)接口，發(fā)現(xiàn)請求都有正確返回數(shù)據(jù)，不可能返回 nil 啊，難道是緩存了 nil 值？下面就直接通過代碼驗證一下！

[1] pry(main)> require "active_support"
=> true
[2] pry(main)> cache = ActiveSupport::Cache::MemoryStore.new
=> <#ActiveSupport::Cache::MemoryStore entries=0, size=0, options={}>
[3] pry(main)> cache.read :nil_value
=> nil
[4] pry(main)> cache.exist? :nil_value
=> false
[5] pry(main)> cache.fetch :nil_value do
[5] pry(main)*   nil   # this `nil` value will be cached
[5] pry(main)* end
=> nil
[6] pry(main)> cache.read :nil_value
=> nil
[7] pry(main)> cache.exist? :nil_value
=> true

看吧， fetch 方法確實會緩存 nil 值（通過 exist? 方法可以判斷是否緩存了指定的 key ），所以系統(tǒng)出錯原因就清晰了：在某次代碼執(zhí)行中，我的緩存剛好失效了，所以系統(tǒng)向外部發(fā)送了請求，恰巧這時候外部系統(tǒng)因為故障或者其他可能原因，沒有返回期待數(shù)據(jù)，導(dǎo)致代碼中最終緩存了 nil 值，在接下來的時間里，雖然外部系統(tǒng)可能恢復(fù)了正確服務(wù)，可是這時候因為我們的系統(tǒng)已經(jīng)緩存了 nil值，所以在每次調(diào)用時都返回緩存的 nil，而不是重新請求正確結(jié)果，導(dǎo)致最后不停的報錯告警。

這里插播一句，通過后來仔細查閱文檔，才發(fā)現(xiàn)文檔里已經(jīng)注明：

Nil values can be cached.

╮(╯▽╰)╭ 怪我咯~

意識到這個問題之后，解決思路簡單粗暴，就是在可能返回 nil 值的地方放棄寫入緩存：

def read_external_service(params)
  cache_key = "example_cache_key_here"
  result = Rails.cache.read(cache_key)
  # 緩存命中，且內(nèi)容不為 nil ，直接返回緩存內(nèi)容
  return result if result.present?

  # 緩存失效，只能重新請求了~
  response = HTTParty.get "https://example.com/example/request/path"
  result = JSON.parse(response.body)["data"]

  # 請求結(jié)果正確，寫入緩存；否則，放棄之~~~
  Rails.cache.write(cache_key, result, expires_in: 7.days) if result.present?
  result
end

呃~~~雖然解決問題了，可是，就為了告訴系統(tǒng)不要相信 nil，就寫得這么繁瑣，好么？好么？好么？

我嘗試搜索了 #fetch 方法是否有支持比如 reject_nil 這樣的 option，可惜的是，沒有！可是真的沒有嗎？我不信！看源碼去！

首先還是拜訪下 ActiveSupport::Cache::Store 這個類啦，它可是所有緩存實現(xiàn)類的抽象類，別問我抽象類是什么，就是它明明只說話不干活，但是其他干活的都得向它看齊！好啦，說人話，其實就是說，我們在調(diào)用 Rails.cache.read、Rails.cache.fetch 等讀寫方法時，這些方法都是在 ActiveSupport::Cache::Store 中定義的，但是它只定義邏輯，而實際底層的讀寫實現(xiàn)，則都是交由其各種子類實現(xiàn)的，比如前面的 ActiveSupport::Cache::MemoryStore。

首先讓我們來看看 fetch方法的全部內(nèi)容：

def fetch(name, options = nil)
  if block_given?
    options = merged_options(options)
    key = namespaced_key(name, options)

    instrument(:read, name, options) do |payload|
      cached_entry = read_entry(key, options) unless options[:force]
      payload[:super_operation] = :fetch if payload
      entry = handle_expired_entry(cached_entry, key, options)

      if entry
        payload[:hit] = true if payload
        get_entry_value(entry, name, options)
      else
        payload[:hit] = false if payload
        save_block_result_to_cache(name, options) { |_name| yield _name }
      end
    end
  else
    read(name, options)
  end

從代碼中可以看到，當(dāng) #fetch 方法調(diào)用時沒有傳遞 block 的話，它本質(zhì)上就是 read 方法的別名而已。而當(dāng)調(diào)用時傳遞了 block 的話，即如我前面的示例代碼，讓我們把代碼分開看下：

cached_entry = read_entry(key, options) unless options[:force]
payload[:super_operation] = :fetch if payload
entry = handle_expired_entry(cached_entry, key, options)

它首先判斷是否設(shè)置了 force 選項，如果有，則不讀取緩存，由此模擬緩存強制失效；如果未設(shè)置 force 選項或者該選項不等于 true value，則嘗試讀取緩存，并且調(diào)用 handle_expired_entry判斷緩存是否仍舊有效。

if entry
  payload[:hit] = true if payload
  get_entry_value(entry, name, options)

這三行代碼，則是在緩存命中時，直接讀取緩存內(nèi)容并且返回。

else
  payload[:hit] = false if payload
  save_block_result_to_cache(name, options) { |_name| yield _name }
end

else 的代碼則表示，在緩存無命中時， #fetch 代碼直接調(diào)用 #save_block_result_to_cache 方法，并且向其傳遞了一個 block，這個 block 沒有干別的事情，它只會執(zhí)行我們傳遞給 #fetch 方法的 block，讓我們接著往下看看相關(guān)的實現(xiàn)：

def save_block_result_to_cache(name, options)
  result = instrument(:generate, name, options) do |payload|
    yield(name)
  end

  write(name, result, options)
  result
end

可以看到，#save_block_result_to_cache 方法首先執(zhí)行傳遞進來的代碼塊，實際上也就是我們期待在緩存失效時執(zhí)行的代碼，而在獲得執(zhí)行結(jié)果 result 后，方法通過調(diào)用 #write 方法將結(jié)果寫入緩存，最后將 result 返回。

通過上面的源碼分析，我們可以知道，當(dāng)緩存失效時，#fetch 方法會直接將其代碼塊中的代碼的返回值不加判斷地寫入緩存，并且返回該返回值。這里，或許我們可以做點什么，來實現(xiàn)我們想要支持 :reject_nil 的需求？

為了支持 :reject_nil，我們只需要在寫入緩存前判斷是否真的需要 nil 值即可，于是我們只需要在 #save_block_result_to_cache 中加入 #write 的前置條件：

def save_block_result_to_cache(name, options)
  result = instrument(:generate, name, options) do |payload|
    yield(name)
  end

  # options[:reject_nil] && result.nil? 作為前置條件
  write(name, result, options) unless result.nil? && options[:reject_nil]

  result
end

話不多說，讓我們來重新試驗一番：

[1] pry(main)> require "active_support"
=> true
[2] pry(main)> cache = ActiveSupport::Cache::MemoryStore.new
=> <#ActiveSupport::Cache::MemoryStore entries=0, size=0, options={}>
[3] pry(main)> cache.fetch :nil_key1 do
[3] pry(main)*   nil
[3] pry(main)* end
=> nil
[4] pry(main)> cache.exist? :nil_key1
=> true
[5] pry(main)> cache.fetch :nil_key2, reject_nil: true do
[5] pry(main)*   nil
[5] pry(main)* end
=> nil
[6] pry(main)> cache.exist? :nil_key2
=> false

可以看到，當(dāng)我們調(diào)用 #fetch 方法時，如果沒有傳遞 reject_nil: true，則 #fetch 方法會默認緩存 nil 值；而如果我們設(shè)置 reject_nil: true 的話，則 #fetch 就會放棄寫入 nil 值到緩存中。試驗成功?。?！

基于這樣的實現(xiàn)，我的代碼就又可以改為如下了：

def read_external_service(params)
  # 所有改動只是加了一個 `reject_nil: true`，多方便，媽媽再也不用擔(dān)心我掉到坑里去了
  Rails.cache.fetch "example_cache_key_here", expires_in: 7.days, reject_nil: true do
    response = HTTParty.get "https://example.com/example/request/path"
    JSON.parse(response.body)["data"]
  end
end

待會去給 Rails 提交 Pull Request 去 O(∩_∩)O~~

緩存是好個東西，用得好能夠讓應(yīng)用性能表現(xiàn)突飛猛進

要注意緩存寫入的邊界條件，要注意避免緩存了空值，但也并非所有空值都不能緩存（比如有些接口確實就是有可能返回空值嘛），具體看業(yè)務(wù)，沒有絕對的要與不要，反正 :reject_nil 給你了，看你要不要