緩存實戰

緩存更新方式

不少研發同窗是這麼用緩存的：在查詢數據的時候，先去緩存中查詢，若是命中緩存那就直接返回數據。若是沒有命中，那就去數據庫中查詢，獲得查詢結果以後把數據寫入緩存，而後返回。在更新數據的時候，先去更新數據庫中的表，若是更新成功，再去更新緩存中的數據。流程以下圖

這樣使用緩存的方式有沒有問題？絕大多數狀況下都沒問題。可是，在併發的狀況下，有必定的機率會出現「髒數據」問題，緩存中的數據可能會被錯誤地更新成了舊數據。好比1，對同一條記錄，同時產生了一個讀請求和一個寫請求，這兩個請求被分配到兩個不一樣的線程並行執行，讀線程嘗試讀緩存沒命中，去數據庫讀到了數據，這時候可能另一個寫線程搶先更新了緩存，在處理寫請求的線程中，前後更新了數據和緩存，而後，拿着舊數據的第一個讀線程又把緩存更新成了舊數據（機率低）。好比2兩個線程對同一個條訂單數據併發寫，也有可能形成緩存中的「髒數據」（機率高）
一、故咱們常用Cache Aside 模式，它們處理讀請求的邏輯是徹底同樣的，惟一的一個小差異就是，Cache Aside 模式在更新數據的時候，並不去嘗試更新緩存，而是去刪除緩存。流程以下：

這種方式能夠解決如上例子2中的髒數據的問題。在寫策略中，可否先刪除緩存，後更新數據庫呢？答案是不行的，由於這樣會大大提升如上事例1出現的機率。另外咱們通常會配合添加一個比較短的過時時間，即便示例1的狀況出現了，也只有比較短期的髒數據。
但也要學會依狀況而變。好比說新註冊用戶，按照這個更新策略，要寫數據庫，而後清理緩存。可當註冊完用戶後，當使用讀寫分離時，會出現由於主從延遲因此讀不到用戶信息的狀況（一致性要求比較高的話，寫後讀在必定時間閾值裏面通常去master讀，此時就不會有這個問題，我會在一致性淺談的文章裏介紹）。而解決這個問題的辦法偏偏是在插入新數據到數據庫以後寫入緩存，這樣後續的讀請求就會從緩存中讀到數據了，由於是新註冊的用戶，因此不會出現併發更新狀況。
二、另外一種常用的策略是模擬MySQL的從機，經過訂閱binlog的方式更新緩存，此時MySQL必須設置爲row格式。通常流程圖以下：

緩存穿透

若是咱們的緩存命中率比較低，就會出現大量「緩存穿透」的狀況。緩存穿透指的是，在讀數據的時候，沒有命中緩存，請求「穿透」了緩存，直接訪問後端數據庫的狀況。少許的緩存穿透是正常的，咱們須要預防的是，短期內大量的請求沒法命中緩存，請求穿透到數據庫，致使數據庫繁忙，請求超時。大量的請求超時還會引起更多的重試請求，更多的重試請求讓數據庫更加繁忙，這樣惡性循環最終致使系統雪崩。
一、當系統初始化的時候，好比說系統升級重啓或者是緩存剛上線，這個時候緩存是空的，若是大量的請求直接打過來，很容易引起大量緩存穿透致使雪崩。爲了不這種狀況，能夠採用灰度發佈的方式，先接入少許請求，再逐步增長系統的請求數量，直到所有請求都切換完成。若是系統不能採用灰度發佈的方式，那就須要在系統啓動的時候對緩存進行預熱：在系統初始化階段，接收外部請求以前，先把最常常訪問的數據填充到緩存裏面，這樣大量請求打過來的時候，就不會出現大量的緩存穿透了。
二、當有大量的請求訪問不存在的數據時，好比在券商系統的用戶表中，咱們須要經過用戶 ID 查詢用戶的信息。若是要讀取一個用戶表中未註冊的用戶，按照這個策略，咱們會先讀緩存再穿透讀數據庫。因爲用戶並不存在，因此緩存和數據庫中都沒有查詢到數據，所以也就不會向緩存中回種數據，這樣當再次請求這個用戶數據的時候仍是會再次穿透到數據庫。在這種場景下緩存並不能有效地阻擋請求穿透到數據庫上，它的做用就微乎其微了。通常來講咱們會有兩種解決方案：回種空值以及使用布隆過濾器
第一種解決方案回種空值。當咱們從數據庫中查詢到空值或者發生異常時，咱們能夠向緩存中回種一個空值。可是由於空值並非準確的業務數據，而且會佔用緩存的空間，因此咱們會給這個空值加一個比較短的過時時間，讓空值在短期以內可以快速過時淘汰。回種空值雖然可以阻擋大量穿透的請求，但若是有大量獲取未註冊用戶信息的請求，緩存內就會有有大量的空值緩存，也就會浪費緩存的存儲空間，若是緩存空間被佔滿了，還會剔除掉一些已經被緩存的用戶信息反而會形成緩存命中率的降低。因此這個方案，在使用的時候應該評估一下緩存容量是否可以支撐。
第二種解決方案布隆過濾器。布隆過濾器有一個特色是：布隆過濾器若是返回不存在的那麼必定是不存在的，可是若是返回存在，未必存在。若是布隆過濾器的屢次hash函數選擇的比較合理，空間預估的比較合理，那邊布隆過濾器返回存在，可是不存在的機率是很小的。故咱們可使用這一特性。如新註冊的用戶除了須要寫入到數據庫中以外，同時更新用戶ID到布隆過濾器。那麼當咱們須要查詢某一個用戶的信息時，先查詢這個 ID 在布隆過濾器中是否存在，若是不存在就直接返回空值，而不須要繼續查詢數據庫和緩存，這樣就能夠極大地減小異常查詢帶來的緩存穿透。
三、熱點KEY問題，按照上文介紹的緩存更新方式（緩存+過時時間），當前KEY是一個熱點KEY，有大量的併發請求而且重建緩存不能再很短期內完成。那麼在緩存失效的瞬間，有大量請求來重建緩存，形成後端負載加大，甚至雪崩。這個問題的根本緣由是有大量的請求訪問了後端存儲，故咱們能夠從減小訪問後端請求的角度解決問題：
第一種方法是互斥鎖方案：此方法只容許同一時刻只有一個線程更新緩存，具體的是在更新的時候申請互斥鎖，獲取到鎖的線程更新緩存，其餘線程等待更新完成。這種方法思路比較簡單，可是可能存在死鎖的風險，而且線程池可能會堵塞。
第二種方法是永遠不過時：從緩存層面，不設置過時時間，從而不會出現熱點KEY過時後產生的問題；從功能層面，爲每一個value設置邏輯過時時間，當發現超過邏輯過時時間後使用單獨的線程重建緩存。邏輯過時時間增長了代碼複雜度和內存成本。
四、大量KEY同時訪問的問題，按照上文介紹的緩存更新方式（緩存+過時時間），當有大量的KEY同時訪問，那麼他們的過時時間也是同樣的，這個會致使不少緩存項同時過時，從而可能致使緩存的機器資源佔用高（緩存在同一時間淘汰大量的緩存項），另外下次大量併發請求過來的時，就須要重建大量的緩存，從而致使緩存穿透甚至雪崩。解決辦法也很簡單，就是更新緩存的時候添加一個隨機的過時時間（緩存+過時時間+隨機時間）