幾種緩存更新的設計方法，值得一看

時間 2020-10-18

標籤 mysql nginx golang 面試 redis 算法 sql 數據庫後端設計模式欄目 MySQL 简体版

原文原文鏈接

前言

Hello，everybody，我是asong，上一篇文章咱們一塊兒聊一聊了面試中幾個常見的緩存問題，今天我依然聊一聊緩存，不過今天咱們聊的不是面試了，咱們一塊兒來看一看咱們在系統中緩存更新的設計，因本身經驗有限，因此這些緩存設計來源於網上，我只是在這裏總結一下，有什麼不對的歡迎指出～～～😊。

緩存預熱 To solve 緩存冷啓動

在上一篇文章中[常見面試題之緩存雪崩、緩存穿透、緩存擊穿]，忘記講了一個概念——緩存預熱，因此在這篇文章補充一下，開一個好頭，預熱嘛～～～。mysql

什麼是緩存預熱呢？咱們都知道日常在跑步前都要熱身，能夠預防肌肉拉傷等一系例的好處。因此緩存預熱具備一樣的道理，咱們的新系統上線後，咱們能夠將相關的緩存數據直接加載到緩存系統。這樣能夠避免在用戶請求的時候，先去查詢數據庫，而後再將數據緩存的問題。用戶能夠直接查詢事先已被預熱的緩存數據。其實緩存預熱是爲了解決緩存冷啓動問題，咱們新系統上線後，redis集羣啓動後，沒有任何的緩存數據，這就是redis的冷啓動。nginx

如上圖所示，若是不進行預熱，那麼Redis初識狀態數據爲空，系統上線初期，對於高併發的流量，都會訪問到數據庫中，對數據庫形成流量的壓力。golang

如何解決

如今咱們已經知道會有緩存預熱這個問題，那麼就要想一下對策咯。能夠分析出如下兩點：面試

須要統計訪問頻度較高的熱點數據
使用LRU數據刪除策略，構建數據留存隊列

因此咱們能夠設計一個以下方案：redis

首先，經過 nginx + lua 的方式，把訪問流量數據上報到 Kafka，也能夠是其它的 mq 隊列。
而後使用實時計算框架(如 storm 、spark streaming、flume)從 kafka 中消費訪問流量數據，實時計算出訪問頻率高的數據，這裏統計出來的可能只會有編號信息，如商品編號或博客編號等。
最後，根據編號從 mysql 數據庫中查詢出具體的信息，寫入 redis，開始提供服務。

緩存更新的幾種設計

1. 先刪除緩存，在更新數據庫

雖然這是一種錯誤方法，可是這種設計也是屬於緩存更新的一種方法，因此你們仍是要知道爲何不能夠這麼作。仍是那句話：知其因此然嘛。算法

這種方法就是在更新數據庫時，先刪除緩存，而後在更新數據庫，然後續的操做會把數據在裝載到緩存中，這種邏輯在併發時就會先髒數據，看以下圖：sql

咱們解釋一下上圖的操做，兩個併發操做，一個是更新操做，另外一個是查詢操做，更新操做刪除緩存後，查詢操做沒有命中緩存，先把老數據讀出來後放到緩存中，而後更新操做更新了數據庫。因而，在緩存中的數據仍是老的數據，致使緩存中的數據是髒的，並且還一直這樣髒下去了。因此這個設計是錯誤的，不建議使用。數據庫

2. Cache aside

這是咱們最經常使用的一種設計模式，其邏輯以下：後端

查詢：程序先從cache中獲取數據，有數據直接返回，沒有獲得，則去數據庫中取數據，成功後更新到緩存中。
更新：先把數據存到數據庫中，成功後，再讓緩存失效。

這種設計正好能解決上文出現髒數據的問題。咱們來理一下，一個是查詢操做，一個是更新操做的併發，沒有了刪除cache數據的操做了，而是先更新了數據庫中的數據，此時，緩存依舊有效，因此，併發的查詢操做拿的是沒有更新的數據，可是，更新操做立刻讓緩存的失效了，後續的查詢操做再把數據從數據庫中拉出來。而不會像文章開頭的那個邏輯產生的問題，後續的查詢操做一直都在取老的數據。設計模式

那麼是否是這種設計就不會存在併發問題了呢？不是的，好比，一個是讀操做，可是沒有命中緩存，而後就到數據庫中取數據，此時來了一個寫操做，寫完數據庫後，讓緩存失效，而後，以前的那個讀操做再把老的數據放進去，因此，會形成髒數據。但，這個case理論上會出現，不過，實際上出現的機率可能很是低，由於這個條件須要發生在讀緩存時緩存失效，並且併發着有一個寫操做。而實際上數據庫的寫操做會比讀操做慢得多，並且還要鎖表，而讀操做必需在寫操做前進入數據庫操做，而又要晚於寫操做更新緩存，全部的這些條件都具有的機率基本並不大。

咱們能夠爲緩存設置上過時時間，這樣能夠有效解決這個問題。

3. Read/Write Through

這個模式其實就是將緩存服務做爲主要的存儲，應用的全部讀寫請求都是直接與緩存服務打交道，而無論最後端的數據庫了，數據庫的數據由緩存服務來維護和更新。不過緩存中數據變動的時候是同步去更新數據庫的，在應用的眼中只有緩存服務。
流程以下：

Read Through

Read Through 套路就是在查詢操做中更新緩存，也就是說，當緩存失效的時候（過時或LRU換出），Cache Aside是由調用方負責把數據加載入緩存，而Read Through則用緩存服務本身來加載，從而對應用方是透明的。

Write Through

Write Through 套路和Read Through相仿，不過是在更新數據時發生。當有數據更新的時候，若是沒有命中緩存，直接更新數據庫，而後返回。若是命中了緩存，則更新緩存，而後再由Cache本身更新數據庫（這是一個同步操做）

這個模式的特色就是出現髒數據的機率就比較低，可是就強依賴緩存了，對緩存服務的穩定性有較大要求，另外，增長新緩存節點時還會有初始狀態空數據問題。

4. Write Behind Caching

Write Behind Caching又叫作Write Back，就是在更新數據的時候，只更新緩存，不更新數據庫，而緩存會異步地批量更新數據庫。這個設計的好處是讓數據的I/O操做能夠很快，異步的操做還能夠合併對同一個數據的屢次操做，性能上是很是可觀的。

可是，其帶來的問題是，數據不是強一致性的，並且可能會丟失。在軟件設計上，咱們基本上不可能作出一個沒有缺陷的設計，就像算法設計中的時間換空間，空間換時間一個道理，有時候，強一致性和高性能，高可用和高性性是有衝突的。軟件設計歷來都是取捨Trade-Off。另外，Write Back實現邏輯比較複雜，由於他須要track有哪數據是被更新了的，須要刷到持久層上。操做系統的write back會在僅當這個cache須要失效的時候，纔會被真正持久起來，好比，內存不夠了，或是進程退出了等狀況，這又叫lazy write。

這個模式的特色就是速度很快，效率會很是高，可是數據的一致性比較差，還可能會有數據的丟失狀況，實現邏輯也較爲複雜。

總結

上面講的這幾種緩存更新設計，都是一些前人使用的總結，這些設計也不是完美的，這個世界上沒有完美的設計，因此咱們的設計多多少少會有問題，好比咱們沒有考慮緩存（Cache）和持久層（Repository）的總體事務的問題。好比，更新Cache成功，更新數據庫失敗了怎麼嗎？或是反過來。關於這個事，若是你須要強一致性，就要好好考慮怎麼解決這個問題。在軟件開發或設計中，我很是建議在以前先去參考一下已有的設計和思路，看看相應的guideline，best practice或design pattern，吃透了已有的這些東西，再決定是否要從新發明輪子。千萬不要似是而非地，想固然的作軟件設計。

好啦，這一篇文章到這裏就結束了，但願對大家有用，又不對的地方歡迎指出，可添加個人golang交流羣，咱們一塊兒學習交流。

結尾給你們發一個小福利吧，最近我在看[微服務架構設計模式]這一本書，講的很好，本身也收集了一本PDF，有須要的小夥能夠到自行下載。獲取方式：關注公衆號：[Golang夢工廠]，後臺回覆：[微服務]，便可獲取。

我翻譯了一份GIN中文文檔，會按期進行維護，有須要的小夥伴後臺回覆[gin]便可下載。

我是asong，一名普普統統的程序猿，讓我一塊兒慢慢變強吧。我本身建了一個golang交流羣，有須要的小夥伴加我vx,我拉你入羣。歡迎各位的關注，咱們下期見~~~