如何分析緩存原理與微服務(wù)緩存自動管理

這篇文章給大家介紹如何分析緩存原理與微服務(wù)緩存自動管理 ，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

海滄網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)公司于2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)公司。

為什么需要緩存？

先從一個老生常談的問題開始談起：我們的程序是如何運(yùn)行起來的？

1. 程序存儲在 disk 中

2. 程序是運(yùn)行在 RAM 之中，也就是我們所說的 main memory

3. 程序的計(jì)算邏輯在 CPU 中執(zhí)行

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

1. load x:

2. x0 = x0 + 1

3. load x0 -> RAM

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

而在計(jì)算機(jī)系統(tǒng)中，有兩種默認(rèn)緩存：

• CPU 里面的末級緩存，即 LLC。緩存內(nèi)存中的數(shù)據(jù)

• 內(nèi)存中的高速頁緩存，即 page cache。緩存磁盤中的數(shù)據(jù)

緩存讀寫策略

引入 Cache 之后，我們繼續(xù)來看看操作緩存會發(fā)生什么。因?yàn)榇嬖诖嫒∷俣鹊牟町悺付也町惡艽蟆?，從而在操作?shù)據(jù)時，延遲或程序失敗等都會導(dǎo)致緩存和實(shí)際存儲層數(shù)據(jù)不一致。

我們就以標(biāo)準(zhǔn)的 Cache+DB 來看看經(jīng)典讀寫策略和應(yīng)用場景。

Cache Aside

先來考慮一種最簡單的業(yè)務(wù)場景，比如用戶表：userId:用戶id, phone:用戶電話token，avtoar:用戶頭像url，緩存中我們用 phone 作為key存儲用戶頭像。當(dāng)用戶修改頭像url該如何做？

1. 更新DB數(shù)據(jù)，再更新Cache 數(shù)據(jù)

2. 更新 DB 數(shù)據(jù)，再刪除 Cache 數(shù)據(jù)

首先 變更數(shù)據(jù)庫和 變更緩存是兩個獨(dú)立的操作，而我們并沒有對操作做任何的并發(fā)控制。那么當(dāng)兩個線程并發(fā)更新它們的時候，就會因?yàn)閷懭腠樞虻牟煌斐蓴?shù)據(jù)不一致。

所以更好的方案是 2：

• 更新數(shù)據(jù)時不更新緩存，而是直接刪除緩存

• 后續(xù)的請求發(fā)現(xiàn)緩存缺失，回去查詢 DB ，并將結(jié)果 load cache

這個策略就是我們使用緩存最常見的策略：Cache Aside。這個策略數(shù)據(jù)以數(shù)據(jù)庫中的數(shù)據(jù)為準(zhǔn)，緩存中的數(shù)據(jù)是按需加載的，分為讀策略和寫策略。

但是可見的問題也就出現(xiàn)了：頻繁的讀寫操作會導(dǎo)致 Cache 反復(fù)地替換，緩存命中率降低。當(dāng)然如果在業(yè)務(wù)中對命中率有監(jiān)控報警時，可以考慮以下方案：

1. 更新數(shù)據(jù)時同時更新緩存，但是在更新緩存前加一個 分布式鎖。這樣同一時間只有一個線程操作緩存，解決了并發(fā)問題。同時在后續(xù)讀請求中時讀到最新的緩存，解決了不一致的問題。

2. 更新數(shù)據(jù)時同時更新緩存，但是給緩存一個較短的 TTL。

當(dāng)然除了這個策略，在計(jì)算機(jī)體系還有其他幾種經(jīng)典的緩存策略，它們也有各自適用的使用場景。

Write Through

先查詢寫入數(shù)據(jù)key是否擊中緩存，如果在 -> 更新緩存，同時緩存組件同步數(shù)據(jù)至DB；不存在，則觸發(fā) Write Miss。

而一般 Write Miss 有兩種方式：

• Write Allocate：寫時直接分配 Cache line

• No-write allocate：寫時不寫入緩存，直接寫入DB，return

在 Write Through 中，一般采取 No-write allocate 。因?yàn)槠鋵?shí)無論哪種，最終數(shù)據(jù)都會持久化到DB中，省去一步緩存的寫入，提升寫性能。而緩存由 Read Through 寫入緩存。

這個策略的核心原則：用戶只與緩存打交道，由緩存組件和DB通信，寫入或者讀取數(shù)據(jù)。在一些本地進(jìn)程緩存組件可以考慮這種策略。

Write Back

相信你也看出上述方案的缺陷：寫數(shù)據(jù)時緩存和數(shù)據(jù)庫同步，但是我們知道這兩塊存儲介質(zhì)的速度差幾個數(shù)量級，對寫入性能是有很大影響。那我們是否異步更新數(shù)據(jù)庫？

Write back 就是在寫數(shù)據(jù)時只更新該 Cache Line 對應(yīng)的數(shù)據(jù)，并把該行標(biāo)記為 Dirty。在讀數(shù)據(jù)時或是在緩存滿時換出「緩存替換策略」時，將 Dirty 寫入存儲。

需要注意的是：在 Write Miss 情況下，采取的是 Write Allocate，即寫入存儲同時寫入緩存，這樣我們在之后的寫請求只需要更新緩存。

> async purge 此類概念其實(shí)存在計(jì)算機(jī)體系中。MySQL 中刷臟頁，本質(zhì)都是盡可能防止隨機(jī)寫，統(tǒng)一寫磁盤時機(jī)。

redis

Redis是一個獨(dú)立的系統(tǒng)軟件，和我們寫的業(yè)務(wù)程序是兩個軟件。當(dāng)我們部署了Redis 實(shí)例后，它只會被動地等待客戶端發(fā)送請求，然后再進(jìn)行處理。所以，如果應(yīng)用程序想要使用 Redis 緩存，我們就要在程序中增加相應(yīng)的緩存操作代碼。所以我們也把 Redis 稱為 旁路緩存，也就是說：讀取緩存、讀取數(shù)據(jù)庫和更新緩存的操作都需要在應(yīng)用程序中來完成。

而作為緩存的 Redis，同樣需要面臨常見的問題：

• 緩存的容量終究有限

• 上游并發(fā)請求沖擊

• 緩存與后端存儲數(shù)據(jù)一致性

替換策略

一般來說，緩存對于選定的被淘汰數(shù)據(jù)，會根據(jù)其是干凈數(shù)據(jù)還是臟數(shù)據(jù)，選擇直接刪除還是寫回?cái)?shù)據(jù)庫。但是，在 Redis 中，被淘汰數(shù)據(jù)無論干凈與否都會被刪除，所以，這是我們在使用 Redis 緩存時要特別注意的：當(dāng)數(shù)據(jù)修改成為臟數(shù)據(jù)時，需要在數(shù)據(jù)庫中也把數(shù)據(jù)修改過來。

所以不管替換策略是什么，臟數(shù)據(jù)有可能在換入換出中丟失。那我們在產(chǎn)生臟數(shù)據(jù)就應(yīng)該刪除緩存，而不是更新緩存，一切數(shù)據(jù)應(yīng)該以數(shù)據(jù)庫為準(zhǔn)。這也很好理解，緩存寫入應(yīng)該交給讀請求來完成；寫請求盡可能保證數(shù)據(jù)一致性。

至于替換策略有哪些，網(wǎng)上已經(jīng)有很多文章歸納之間的優(yōu)劣，這里就不再贅述。

ShardCalls

并發(fā)場景下，可能會有多個線程（協(xié)程）同時請求同一份資源，如果每個請求都要走一遍資源的請求過程，除了比較低效之外，還會對資源服務(wù)造成并發(fā)的壓力。

go-zero 中的 ShardCalls 可以使得同時多個請求只需要發(fā)起一次拿結(jié)果的調(diào)用，其他請求"坐享其成"，這種設(shè)計(jì)有效減少了資源服務(wù)的并發(fā)壓力，可以有效防止緩存擊穿。

對于防止暴增的接口請求對下游服務(wù)造成瞬時高負(fù)載，可以在你的函數(shù)包裹：

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

其實(shí)原理也很簡單：

func (g *sharedGroup) Do(key string, fn func() (interface{}, error)) (interface{}, error) {
  // done: false，才會去執(zhí)行下面的業(yè)務(wù)邏輯；為 true，直接返回之前獲取的data
  c, done := g.createCall(key)
  if done {
    return c.val, c.err
  }
  
  // 執(zhí)行調(diào)用者傳入的業(yè)務(wù)邏輯
  g.makeCall(c, key, fn)
  return c.val, c.err
}

func (g *sharedGroup) createCall(key string) (c *call, done bool) {
  // 只讓一個請求進(jìn)來進(jìn)行操作
  g.lock.Lock()
  // 如果攜帶標(biāo)示一系列請求的key在 calls 這個map中已經(jīng)存在，
  // 則解鎖并同時等待之前請求獲取數(shù)據(jù)，返回
  if c, ok := g.calls[key]; ok {
    g.lock.Unlock()
    c.wg.Wait()
    return c, true
  }
  
  // 說明本次請求是首次請求
  c = new(call)
  c.wg.Add(1)
  // 標(biāo)注請求，因?yàn)槌钟墟i，不用擔(dān)心并發(fā)問題
  g.calls[key] = c
  g.lock.Unlock()

  return c, false
}

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

> 源碼地址：sharedcalls.go

緩存和存儲更新順序

這是開發(fā)中常見糾結(jié)問題：到底是先刪除緩存還是先更新存儲？

> 情況一：先刪除緩存，再更新存儲； > > - A 刪除緩存，更新存儲時網(wǎng)絡(luò)延遲 > - B 讀請求，發(fā)現(xiàn)緩存缺失，讀存儲 -> 此時讀到舊數(shù)據(jù)

這樣會產(chǎn)生兩個問題：

• B 讀取舊值

• B 同時讀請求會把舊值寫入緩存，導(dǎo)致后續(xù)讀請求讀到舊值

既然是緩存可能是舊值，那就不管刪除。有一個并不優(yōu)雅的解決方案：在寫請求更新完存儲值以后，sleep() 一小段時間，再進(jìn)行一次緩存刪除操作。

sleep 是為了確保讀請求結(jié)束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)，當(dāng)然也要考慮到 redis 主從同步的耗時。不過還是要根據(jù)實(shí)際業(yè)務(wù)而定。

這個方案會在第一次刪除緩存值后，延遲一段時間再次進(jìn)行刪除，被稱為：延遲雙刪。

> 情況二：先更新數(shù)據(jù)庫值，再刪除緩存值： > > - A 刪除存儲值，但是刪除緩存網(wǎng)絡(luò)延遲 > - B 讀請求時，緩存擊中，就直接返回舊值

這種情況對業(yè)務(wù)的影響較小，而絕大多數(shù)緩存組件都是采取此種更新順序，滿足最終一致性要求。

> 情況三：新用戶注冊，直接寫入數(shù)據(jù)庫，同時緩存中肯定沒有。如果程序此時讀從庫，由于主從延遲，導(dǎo)致讀取不到用戶數(shù)據(jù)。

這種情況就需要針對 Insert 這種操作：插入新數(shù)據(jù)入數(shù)據(jù)庫同時寫緩存。使得后續(xù)讀請求可以直接讀緩存，同時因?yàn)槭莿偛迦氲男聰?shù)據(jù)，在一段時間修改的可能性不大。

以上方案在復(fù)雜的情況或多或少都有潛在問題，需要貼合業(yè)務(wù)做具體的修改。

如何設(shè)計(jì)好用的緩存操作層？

上面說了這么多，回到我們開發(fā)角度，如果我們需要考慮這么多問題，顯然太麻煩了。所以如何把這些緩存策略和替換策略封裝起來，簡化開發(fā)過程？

明確幾點(diǎn)：

• 將業(yè)務(wù)邏輯和緩存操作分離，留給開發(fā)這一個寫入邏輯的點(diǎn)

• 緩存操作需要考慮流量沖擊，緩存策略等問題。。。

我們從讀和寫兩個角度去聊聊 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)
})

我們將開發(fā)查詢業(yè)務(wù)邏輯用 func(conn sqlx.SqlConn, v interface{}) 封裝。用戶無需考慮緩存寫入，只需要傳入需要寫入的 cacheKey。同時把查詢結(jié)果 res 返回。

那緩存操作是如何被封裝在內(nèi)部呢？來看看函數(shù)內(nèi)部：

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
}

從流程上恰好對應(yīng)緩存策略中的：Read Through。

> 源碼地址：cachedsql.go

Exec

而寫請求，使用的就是之前緩存策略中的 Cache Aside -> 先寫數(shù)據(jù)庫，再刪除緩存。

_, 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 一樣，調(diào)用者只需要負(fù)責(zé)業(yè)務(wù)邏輯，緩存寫入和刪除對調(diào)用透明。

> 源碼地址：cachedsql.go

線上的緩存

開篇第一句話：脫離業(yè)務(wù)將技術(shù)都是耍流氓。以上都是在對緩存模式分析，但是實(shí)際業(yè)務(wù)中緩存是否起到應(yīng)有的加速作用？最直觀就是緩存擊中率，而如何觀測到服務(wù)的緩存擊中？這就涉及到監(jiān)控。

下圖是我們線上環(huán)境的某個服務(wù)的緩存記錄情況：

還記得上面 QueryRow 中：查詢緩存擊中，會調(diào)用 c.stat.IncrementHit()。其中的 stat 就是作為監(jiān)控指標(biāo)，不斷在計(jì)算擊中率和失敗率。

> 源碼地址：cachestat.go

在其他的業(yè)務(wù)場景中：比如首頁信息瀏覽業(yè)務(wù)中，大量請求不可避免。所以緩存首頁的信息在用戶體驗(yàn)上尤其重要。但是又不像之前提到的一些單一的key，這里可能涉及大量消息，這個時候就需要其他緩存類型加入：

1. 拆分緩存：可以分 消息id -> 由 消息id 查詢消息，并緩存插入消息list中。

2. 消息過期：設(shè)置消息過期時間，做到不占用過長時間緩存。

這里也就是涉及緩存的最佳實(shí)踐：

• 不允許不過期的緩存「尤為重要」

• 分布式緩存，易伸縮

• 自動生成，自帶統(tǒng)計(jì)

關(guān)于如何分析緩存原理與微服務(wù)緩存自動管理 就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

本文名稱：如何分析緩存原理與微服務(wù)緩存自動管理
文章路徑：http://muchs.cn/article32/ijccsc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、企業(yè)建站、、軟件開發(fā)、網(wǎng)站策劃、網(wǎng)站維護(hù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)