> 拋開業務談技術都是在耍流氓。—— 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` 可以使得同時多個請求只需要發起一次拿結果的呼叫，其他請求"坐享其成"，這種設計有效減少了資源服務的併發壓力，可以有效防止快取擊穿。 對於防止暴增的介面請求對下游服務造成瞬時高負載，可以在你的函式包裹： ```go fn = func() (interface{}, error) { // 業務查詢 } data, err = g.Do(apiKey, fn) // 就獲得到data，之後的方法或者邏輯就可以使用這個data ``` 其實原理也很簡單： ```go 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](https://github.com/golang/groupcache/tree/master/singleflight)中的 `singleflight` 類似，都是防止快取擊穿的利器 > 原始碼地址：[sharedcalls.go](https://github.com/tal-tech/go-zero/blob/master/core/syncx/sharedcalls.go#L45) ### 快取和儲存更新順序 這是開發中常見糾結問題：**到底是先刪除快取還是先更新儲存？** > 情況一：先刪除快取，再更新儲存； > > - `A` 刪除快取，更新儲存時網路延遲 > - `B` 讀請求，發現快取缺失，讀儲存 -> 此時讀到舊資料 這樣會產生兩個問題： - `B` 讀取舊值 - `B` 同時讀請求會把舊值寫入快取，導致後續讀請求讀到舊值 既然是快取可能是舊值，那就不管刪除。有一個並不優雅的解決方案：**在寫請求更新完儲存值以後，`sleep()` 一小段時間，再進行一次快取刪除操作**。 `sleep` 是為了確保讀請求結束，寫請求可以刪除讀請求造成的快取髒資料，當然也要考慮到 redis 主從同步的耗時。不過還是要根據實際業務而定。 這個方案會在第一次刪除快取值後，延遲一段時間再次進行刪除，被稱為：**延遲雙刪**。 > 情況二：先更新資料庫值，再刪除快取值： > > - `A` 刪除儲存值，但是刪除快取網路延遲 > - `B` 讀請求時，快取擊中，就直接返回舊值 這種情況對業務的影響較小，而絕大多數快取元件都是採取此種更新順序，滿足最終一致性要求。 > 情況三：新使用者註冊，直接寫入資料庫，同時快取中肯定沒有。如果程式此時讀從庫，由於主從延遲，導致讀取不到使用者資料。 這種情況就需要針對 `Insert` 這種操作：插入新資料入資料庫同時寫快取。使得後續讀請求可以直接讀快取，同時因為是剛插入的新資料，在一段時間修改的可能性不大。 **以上方案在複雜的情況或多或少都有潛在問題，需要貼合業務做具體的修改**。 ## 如何設計好用的快取操作層？ 上面說了這麼多，回到我們開發角度，如果我們需要考慮這麼多問題，顯然太麻煩了。所以如何把這些快取策略和替換策略封裝起來，簡化開發過程？ 明確幾點： - 將業務邏輯和快取操作分離，留給開發這一個寫入邏輯的點 - 快取操作需要考慮流量衝擊，快取策略等問題。。。 我們從讀和寫兩個角度去聊聊 `go-zero `是如何封裝。 ### QueryRow ```go // 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` 返回。 那快取操作是如何被封裝在內部呢？來看看函式內部： ```go 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](https://github.com/tal-tech/go-zero/blob/master/core/stores/sqlc/cachedsql.go#L75) ### Exec 而寫請求，使用的就是之前快取策略中的 `Cache Aside` -> 先寫資料庫，再刪除快取。 ```go _, 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](https://github.com/tal-tech/go-zero/blob/master/core/stores/sqlc/cachedsql.go#L58) ## 線上的快取 開篇第一句話：脫離業務將技術都是耍流氓。以上都是在對快取模式分析，但是實際業務中快取是否起到應有的加速作用？最直觀就是快取擊中率，而如何觀測到服務的快取擊中？這就涉及到監控。 下圖是我們線上環境的某個服務的快取記錄情況：  還記得上面 `QueryRow` 中：查詢快取擊中，會呼叫 `c.stat.IncrementHit()`。其中的 `stat` 就是作為監控指標，不斷在計算擊中率和失敗率。  > 原始碼地址：[cachestat.go](https://github.com/tal-tech/go-zero/blob/master/core/stores/cache/cachestat.go#L47) 在其他的業務場景中：比如首頁資訊瀏覽業務中，大量請求不可避免。所以快取首頁的資訊在使用者體驗上尤其重要。但是又不像之前提到的一些單一的key，這裡可能涉及大量訊息，這個時候就需要其他快取型別加入： 1. 拆分快取：可以分 `訊息id` -> 由 `訊息id` 查詢訊息，並快取插入`訊息list`中。 2. 訊息過期：設定訊息過期時間，做到不佔用過長時間快取。 這裡也就是涉及快取的最佳實踐： - 不允許不過期的快取「尤為重要」 - 分散式快取，易伸縮 - 自動生成，自帶統計 ## 總結 本文從快取的引入，常見快取讀寫策略，如何保證資料的最終一致性，如何封裝一個好用的快取操作層，也展示了線上快取的情況以及監控。所有上面談到的這些快取細節都可以參考 `go-zero` 原始碼實現，見 `go-zero` 原始碼的 `core/stores`。 ## 專案地址 [https://github.com/tal-tech/go-zero](https://github.com/tal-tech/go-zero) 歡迎使用 go-zero 並 **star** 鼓勵我們！