微服務快取原理與最佳實踐

kevwan發表於2021-01-10

為什麼需要快取?

先從一個老生常談的問題開始談起:我們的程式是如何執行起來的?

  1. 程式儲存在 disk
  2. 程式是執行在 RAM 之中,也就是我們所說的 main memory
  3. 程式的計算邏輯在 CPU 中執行

來看一個最簡單的例子:a = a + 1

  1. load x:
  2. x0 = x0 + 1
  3. load x0 -> RAM

上面提到了 3 種儲存介質。我們都知道,三類的讀寫速度和成本成反比,所以我們在克服速度問題上需要引入一個 中間層。這個中間層,需要高速存取的速度,但是成本可接受。於是乎,Cache 被引入

而在計算機系統中,有兩種預設快取:

  • CPU 裡面的末級快取,即 LLC。快取記憶體中的資料
  • 記憶體中的高速頁快取,即 page cache。快取磁碟中的資料

快取讀寫策略

引入 Cache 之後,我們繼續來看看操作快取會發生什麼。因為存在存取速度的差異「而且差異很大」,從而在運算元據時,延遲或程式失敗等都會導致快取和實際儲存層資料不一致。

我們就以標準的 Cache+DB 來看看經典讀寫策略和應用場景。

Cache Aside

先來考慮一種最簡單的業務場景,比如使用者表:userId:使用者id, phone:使用者電話token,avtoar:使用者頭像url,快取中我們用 phone 作為 key 儲存使用者頭像。當使用者修改頭像 url 該如何做?

  1. 更新DB資料,再更新Cache 資料
  2. 更新 DB 資料,再刪除 Cache 資料

首先 變更資料庫變更快取 是兩個獨立的操作,而我們並沒有對操作做任何的併發控制。那麼當兩個執行緒併發更新它們的時候,就會因為寫入順序的不同造成資料不一致。

所以更好的方案是 2

  • 更新資料時不更新快取,而是直接刪除快取
  • 後續的請求發現快取缺失,回去查詢 DB ,並將結果 load cache

這個策略就是我們使用快取最常見的策略:Cache Aside。這個策略資料以資料庫中的資料為準,快取中的資料是按需載入的,分為讀策略和寫策略。

但是可見的問題也就出現了:頻繁的讀寫操作會導致 Cache 反覆地替換,快取命中率降低。當然如果在業務中對命中率有監控報警時,可以考慮以下方案:

  1. 更新資料時同時更新快取,但是在更新快取前加一個 分散式鎖。這樣同一時間只有一個執行緒操作快取,解決了併發問題。同時在後續讀請求中時讀到最新的快取,解決了不一致的問題。
  2. 更新資料時同時更新快取,但是給快取一個較短的 TTL

當然除了這個策略,在計算機體系還有其他幾種經典的快取策略,它們也有各自適用的使用場景。

Write Through

先查詢寫入資料 key 是否擊中快取,如果在 -> 更新快取,同時快取元件同步資料至 DB;不存在,則觸發 Write Miss

而一般 Write Miss 有兩種方式:

  • Write Allocate:寫時直接分配 Cache line
  • No-write allocate:寫時不寫入快取,直接寫入 DB,return

Write Through 中,一般採取 No-write allocate 。因為其實無論哪種,最終資料都會持久化到 DB 中,省去一步快取的寫入,提升寫效能。而快取由 Read Through 寫入快取。

這個策略的核心原則:使用者只與快取打交道,由快取元件和 DB 通訊,寫入或者讀取資料。在一些本地程式快取元件可以考慮這種策略。

Write Back

相信你也看出上述方案的缺陷:寫資料時快取和資料庫同步,但是我們知道這兩塊儲存介質的速度差幾個數量級,對寫入效能是有很大影響。那我們是否非同步更新資料庫?

Write back 就是在寫資料時只更新該 Cache Line 對應的資料,並把該行標記為 Dirty。在讀資料時或是在快取滿時換出「快取替換策略」時,將 Dirty 寫入儲存。

需要注意的是:在 Write Miss 情況下,採取的是 Write Allocate,即寫入儲存同時寫入快取,這樣我們在之後的寫請求只需要更新快取。

async purge 此類概念其實存在計算機體系中。Mysql 中刷髒頁,本質都是儘可能防止隨機寫,統一寫磁碟時機。

Redis

Redis是一個獨立的系統軟體,和我們寫的業務程式是兩個軟體。當我們部署了Redis 例項後,它只會被動地等待客戶端傳送請求,然後再進行處理。所以,如果應用程式想要使用 Redis 快取,我們就要在程式中增加相應的快取操作程式碼。所以我們也把 Redis 稱為 旁路快取,也就是說:讀取快取、讀取資料庫和更新快取的操作都需要在應用程式中來完成。

而作為快取的 Redis,同樣需要面臨常見的問題:

  • 快取的容量終究有限
  • 上游併發請求衝擊
  • 快取與後端儲存資料一致性

替換策略

一般來說,快取對於選定的被淘汰資料,會根據其是乾淨資料還是髒資料,選擇直接刪除還是寫回資料庫。但是,在 Redis 中,被淘汰資料無論乾淨與否都會被刪除,所以,這是我們在使用 Redis 快取時要特別注意的:當資料修改成為髒資料時,需要在資料庫中也把資料修改過來。

所以不管替換策略是什麼,髒資料有可能在換入換出中丟失。那我們在產生髒資料就應該刪除快取,而不是更新快取,一切資料應該以資料庫為準。這也很好理解,快取寫入應該交給讀請求來完成;寫請求儘可能保證資料一致性。

至於替換策略有哪些,網上已經有很多文章歸納之間的優劣,這裡就不再贅述。

ShardCalls

併發場景下,可能會有多個執行緒(協程)同時請求同一份資源,如果每個請求都要走一遍資源的請求過程,除了比較低效之外,還會對資源服務造成併發的壓力。

go-zero 中的 ShardCalls 可以使得同時多個請求只需要發起一次拿結果的呼叫,其他請求"坐享其成",這種設計有效減少了資源服務的併發壓力,可以有效防止快取擊穿。

對於防止暴增的介面請求對下游服務造成瞬時高負載,可以在你的函式包裹:

fn = func() (interface{}, error) {
  // 業務查詢
}
data, err = g.Do(apiKey, fn)
// 就獲得到data,之後的方法或者邏輯就可以使用這個data

其實原理也很簡單:

func (g *sharedGroup) Do(key string, fn func() (interface{}, error)) (interface{}, error) {
  // done: false,才會去執行下面的業務邏輯;為 true,直接返回之前獲取的data
  c, done := g.createCall(key)
  if done {
    return c.val, c.err
  }

  // 執行呼叫者傳入的業務邏輯
  g.makeCall(c, key, fn)
  return c.val, c.err
}

func (g *sharedGroup) createCall(key string) (c *call, done bool) {
  // 只讓一個請求進來進行操作
  g.lock.Lock()
  // 如果攜帶標示一系列請求的key在 calls 這個map中已經存在,
  // 則解鎖並同時等待之前請求獲取資料,返回
  if c, ok := g.calls[key]; ok {
    g.lock.Unlock()
    c.wg.Wait()
    return c, true
  }

  // 說明本次請求是首次請求
  c = new(call)
  c.wg.Add(1)
  // 標註請求,因為持有鎖,不用擔心併發問題
  g.calls[key] = c
  g.lock.Unlock()

  return c, false
}

這種 map+lock 儲存並限制請求操作,和groupcache中的 singleflight 類似,都是防止快取擊穿的利器

原始碼地址:sharedcalls.go

快取和儲存更新順序

這是開發中常見糾結問題:到底是先刪除快取還是先更新儲存?

情況一:先刪除快取,再更新儲存;

  • A 刪除快取,更新儲存時網路延遲
  • B 讀請求,發現快取缺失,讀儲存 -> 此時讀到舊資料

這樣會產生兩個問題:

  • B 讀取舊值
  • B 同時讀請求會把舊值寫入快取,導致後續讀請求讀到舊值

既然是快取可能是舊值,那就不管刪除。有一個並不優雅的解決方案:在寫請求更新完儲存值以後,sleep() 一小段時間,再進行一次快取刪除操作

sleep 是為了確保讀請求結束,寫請求可以刪除讀請求造成的快取髒資料,當然也要考慮到 redis 主從同步的耗時。不過還是要根據實際業務而定。

這個方案會在第一次刪除快取值後,延遲一段時間再次進行刪除,被稱為:延遲雙刪

情況二:先更新資料庫值,再刪除快取值:

  • A 刪除儲存值,但是刪除快取網路延遲
  • B 讀請求時,快取擊中,就直接返回舊值

這種情況對業務的影響較小,而絕大多數快取元件都是採取此種更新順序,滿足最終一致性要求。

情況三:新使用者註冊,直接寫入資料庫,同時快取中肯定沒有。如果程式此時讀從庫,由於主從延遲,導致讀取不到使用者資料。

這種情況就需要針對 Insert 這種操作:插入新資料入資料庫同時寫快取。使得後續讀請求可以直接讀快取,同時因為是剛插入的新資料,在一段時間修改的可能性不大。

以上方案在複雜的情況或多或少都有潛在問題,需要貼合業務做具體的修改

如何設計好用的快取操作層?

上面說了這麼多,回到我們開發角度,如果我們需要考慮這麼多問題,顯然太麻煩了。所以如何把這些快取策略和替換策略封裝起來,簡化開發過程?

明確幾點:

  • 將業務邏輯和快取操作分離,留給開發這一個寫入邏輯的點
  • 快取操作需要考慮流量衝擊,快取策略等問題。。。

我們從讀和寫兩個角度去聊聊 go-zero是如何封裝。

QueryRow

// res: query result
// cacheKey: redis key
err := m.QueryRow(&res, cacheKey, func(conn sqlx.SqlConn, v interface{}) error {
  querySQL := `select * from your_table where campus_id = ? and student_id = ?`
  return conn.QueryRow(v, querySQL, campusId, studentId)
})

我們將開發查詢業務邏輯用 func(conn sqlx.SqlConn, v interface{}) 封裝。使用者無需考慮快取寫入,只需要傳入需要寫入的 cacheKey。同時把查詢結果 res 返回。

那快取操作是如何被封裝在內部呢?來看看函式內部:

func (c cacheNode) QueryRow(v interface{}, key string, query func(conn sqlx.SqlConn, v interface{}) error) error {
 cacheVal := func(v interface{}) error {
  return c.SetCache(key, v)
 }
 // 1. cache hit -> return
  // 2. cache miss -> err
 if err := c.doGetCache(key, v); err != nil {
    // 2.1 err defalut val {*}
  if err == errPlaceholder {
   return c.errNotFound
  } else if err != c.errNotFound {
   return err
  }
  // 2.2 cache miss -> query db
    // 2.2.1 query db return err {NotFound} -> return err defalut val「see 2.1」
  if err = query(c.db, v); err == c.errNotFound {
   if err = c.setCacheWithNotFound(key); err != nil {
    logx.Error(err)
   }

   return c.errNotFound
  } else if err != nil {
   c.stat.IncrementDbFails()
   return err
  }
  // 2.3 query db success -> set val to cache
  if err = cacheVal(v); err != nil {
   logx.Error(err)
   return err
  }
 }
 // 1.1 cache hit -> IncrementHit
 c.stat.IncrementHit()

 return nil
}

從流程上恰好對應快取策略中的:Read Through

原始碼地址:cachedsql.go

Exec

而寫請求,使用的就是之前快取策略中的 Cache Aside -> 先寫資料庫,再刪除快取。

_, err := m.Exec(func(conn sqlx.SqlConn) (result sql.Result, err error) {
  execSQL := fmt.Sprintf("update your_table set %s where 1=1", m.table, AuthRows)
  return conn.Exec(execSQL, data.RangeId, data.AuthContentId)
}, keys...)

func (cc CachedConn) Exec(exec ExecFn, keys ...string) (sql.Result, error) {
 res, err := exec(cc.db)
 if err != nil {
  return nil, err
 }

 if err := cc.DelCache(keys...); err != nil {
  return nil, err
 }

 return res, nil
}

QueryRow 一樣,呼叫者只需要負責業務邏輯,快取寫入和刪除對呼叫透明。

原始碼地址:cachedsql.go

線上的快取

開篇第一句話:脫離業務將技術都是耍流氓。以上都是在對快取模式分析,但是實際業務中快取是否起到應有的加速作用?最直觀就是快取擊中率,而如何觀測到服務的快取擊中?這就涉及到監控。

下圖是我們線上環境的某個服務的快取記錄情況:

還記得上面 QueryRow 中:查詢快取擊中,會呼叫 c.stat.IncrementHit()。其中的 stat 就是作為監控指標,不斷在計算擊中率和失敗率。

原始碼地址:cachestat.go

在其他的業務場景中:比如首頁資訊瀏覽業務中,大量請求不可避免。所以快取首頁的資訊在使用者體驗上尤其重要。但是又不像之前提到的一些單一的 key,這裡可能涉及大量訊息,這個時候就需要其他快取型別加入:

  1. 拆分快取:可以分 訊息id -> 由 訊息id 查詢訊息,並快取插入訊息list中。
  2. 訊息過期:設定訊息過期時間,做到不佔用過長時間快取。

這裡也就是涉及快取的最佳實踐:

  • 不允許不過期的快取「尤為重要」
  • 分散式快取,易伸縮
  • 自動生成,自帶統計

總結

本文從快取的引入,常見快取讀寫策略,如何保證資料的最終一致性,如何封裝一個好用的快取操作層,也展示了線上快取的情況以及監控。所有上面談到的這些快取細節都可以參考 go-zero 原始碼實現,見 go-zero 原始碼的 core/stores

專案地址

https://github.com/tal-tech/go-zero

歡迎使用 go-zero 並 star 鼓勵我們!??

9. 微信交流群

微服務快取原理與最佳實踐

更多原創文章乾貨分享,請關注公眾號
  • 微服務快取原理與最佳實踐
  • 加微信實戰群請加微信(註明:實戰群):gocnio

相關文章