緩存原理與微服務緩存自動管理

拋開業務談技術都是在耍流氓。—— Kevin Wan

爲何須要緩存？

先從一個老生常談的問題開始談起：咱們的程序是如何運行起來的？

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 鼓勵咱們！👏🏻

項目地址：
https://github.com/tal-tech/go-zero