快取原理與微服務快取自動管理

拋開業務談技術都是在耍流氓，—— 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

標籤：Go

上一篇：每年都說“世上最難就業季”，并不是作業難找，而是自滿的大學生越來越多。

下一篇：后端新手入職技能知識總結