今天520，要及時「緩存」大家的珍貴時光。

文章源自公衆號：後端學長投稿
這是程序員cxuan的第 9 篇原創分享

1 緩存概述

在好久好久之前人類和洪水做鬥爭的過程當中，水庫發揮了相當重要的做用 : 在發洪水時能夠蓄水，緩解洪水對下游的衝擊；在乾旱時能夠把庫存的水釋放出來以供人們使用。這裏的水庫就起着緩存的做用。在現在互聯網的世界裏隨着互聯網的普及，內容信息愈來愈複雜，用戶數和訪問量愈來愈大，咱們的應用須要支撐更多的併發量，同時咱們的應用服務器和數據庫服務器所作的計算也愈來愈多。

可是每每咱們的應用服務器資源是有限的，且服務器技術變革是緩慢的，數據庫每秒能接受的請求次數也是有限的，那麼如何可以有效利用有限的資源來提供儘量大的吞吐量呢？一個有效的辦法就是引入緩存，打破標準流程，每一個環節中請求能夠從緩存中直接獲取目標數據並返回，從而減小計算量，有效提高響應速度，讓有限的資源服務更多的用戶。

2 緩存的定義

緩存就是數據交換的緩衝區（稱做Cache），這個概念最初是來自於內存和 CPU。當某一硬件要讀取數據時，會首先從緩存中查找須要的數據，若是找到了則直接使用執行，緩存找不到的話則從內存中找。因爲緩存的運行速度比內存快得多，故緩存的做用就是幫助硬件更快地運行。

3 緩存的分類

當用戶從鍵入一個地址到頁面的展現過程當中一般包含了不少種緩存。有前端緩存、本地緩存(協商緩存,強緩存等)到咱們的網關緩存(CDN 緩存)、最後到咱們服務端緩存。服務端緩存又區分爲進程緩存（本地緩存），還有比較火的分佈式緩存，最後到了數據庫層面的緩存。以下圖所示:

4 緩存是一把雙刃劍

在咱們一般的軟件設計中，有一些熱點數據須要展現到頁面，咱們一般當這些數據緩存到內存或者其餘讀寫速度優異的框架中。減小與數據庫進行 I/O 操做。提高數據的響應速度。這一切看起來就是這麼完美。
實際上，在緩存系統的設計架構中，還有不少坑。若是設計不當會致使不少嚴重的後果。設計不當，輕則請求變慢、性能下降，重則會數據不一致、系統可用性下降，甚至會致使緩存雪崩，整個系統沒法對外提供服務。

接下來咱們着重講述一下在緩存設計過程當中幾大經典的問題。

緩存失效

先解釋一下什麼叫作緩存失效

咱們在存放緩存的時候，能夠指定緩存 Key 的失效時間，當失效時間到了，此緩存就會失效，因爲在緩存中找不到該數據，因此這個時候若是用戶有請求該數據就繞過緩存直接到數據庫中請求數據。

看到這裏小夥伴們確定有不少問號？

這不是很正常的現象嘛？爲何要把這個問題拿出來講呢？莫急看下圖圖示

這裏咱們經過兩個場景來講明一下

• 場景一：這種狀況下通常不會對數據庫形成比較嚴重的影響，由於失效的 key 的數量比較少，即便同時請求到數據庫層面也是能夠接受的。

• 場景二：在這種場景中，當緩存裏面的大量 Key 同時失效，這個時候若是有請求過來，會穿過失效的 Key所有落到數據庫層面。致使數據庫的負荷瞬間添加。可能會出現數據庫宕機等特大事故。

解決方案

看到這裏不少聰明的小夥伴其實已經想到了。場景 2 的事故主要由於不少 key 一塊兒失效的緣由，跟咱們平常寫緩存的過時時間息息相關。若是咱們在平常的開發過程當中須要將一批 Key 設置到緩存中並制定失效時間。這個時候就要注意場景 2 發生的狀況。咱們能夠在失效時間 + 隨機時間。避免大量 Key 失效衝擊咱們的數據庫。

緩存擊穿

一般狀況下，咱們去查詢數據都是存在的。那麼若是請求去查詢一條壓根兒數據庫中根本就不存在的數據，也就是緩存和數據庫都查詢不到的這條數據會怎麼樣呢？這樣會致使每次訪問都會直接打到數據庫上面去。這種查詢不存在數據的現象咱們稱爲緩存穿透。

下面是緩存失效的場景

不少夥伴看到這裏確定又會以爲這是一件很正常的事情。試想一下，若是有***會對你的系統進行***，拿一個不存在的 key 不停的去查詢數據，會產生大量的請求到數據庫去查詢。可能會致使你的數據庫因爲壓力過大而宕掉。

解決方案一

• 首先咱們能想到的就是在網關參數進行過濾。校驗請求的 key 是不是咱們系統 key 的格式等

固然這網關層所能作到的只是一些簡單過濾。每一個後端的設計人員應該對服務的可用性和健壯性負責。接下來咱們看看服務端應該如何處理

• 服務端能夠將不存在的 key 暫時保存到咱們的緩存中，再次接收到一樣的請求後若是直接命中緩存而且值爲空那麼就會直接返回，不會穿透到數據庫層面，這樣就避免了緩存擊穿。

可是***/惡意***者是不會這麼輕易被打發的。每次請求都會傳不一樣的 key 來***咱們的服務。這個時候這個方案起不到做用了。

解決方案二

構建一個 BloomFilter(布隆過濾器) 緩存過濾器，記錄全量數據。這樣訪問數據時，能夠直接經過 BloomFilter 判斷這個 key 是否存在，若是不存在直接返回便可，根本無需查緩存和 DB。這樣在緩存以前加了一層校驗。若是key 值不存在，就不會請求到咱們的緩存更加不會到咱們的數據庫中。

布隆過濾器能夠理解爲一個不怎麼精確的 set結構，當你使用它的 contains 方法判斷某個對象是否存在時，它可能會誤判。可是布隆過濾器也不是特別不精確，只要參數設置的合理，它的精確度能夠控制的相對足夠精確，只會有小小的誤判機率。當布隆過濾器說某個值存在時，這個值可能不存在；當它說不存在時，那就確定不存在。即便誤判不存在走到緩存和後端服務也是能夠接受的。

緩存雪崩

緩存雪崩是指緩存的部分節點不可用致使整個緩存體系甚至整個服務系統不可用。

那麼你可能會有疑問，緩存雪崩和緩存擊穿有什麼關係呢？

從概念上來看，緩存擊穿是由於查詢不存在的 key 穿透緩存直接訪問咱們的數據庫。而緩存雪崩是由於咱們的緩存節點不可用，請求未通過緩存就直到了咱們的數據庫層面。然而二者都會影響咱們的服務穩定性。

緩存節點的不可用會致使緩存雪崩，那麼咱們緩存組件集羣部署是否是就解決了這個問題呢？

集羣部署有兩種狀況：

• 一種就是簡單的主從例如 redis 的哨兵之殤
• 採起一致性 hash 算法集羣部署例如 redis 的分片集羣

第一種狀況：發送雪崩的時候通常是多個節點同時不可用，例如咱們的節點服務器內容不足，雖然分主從節點都是存儲的數據都是同樣的。若是緩存中的數據過大致使節點不可用。那大部分節點也會存在這個問題。請求會大面積的落到數據庫層面致使後端系統崩潰。

第二種狀況: 首先看一下下圖雖然數據根據會根據取模算法分配到不一樣的節點中，假設節點 A 不可用，數據 A 會按照逆時針找到節點 B，會由於原本應該存放到節點 A 的數據存放到節點 B，以此類推會致使整個緩存節點不可用。請求也會大面積落到咱們後端的數據庫層面致使系統崩潰。

解決方案

• 對緩存體系進行實時監控，當請求訪問的慢速比超過閥值時，及時報警，經過機器替換、服務替換進行及時恢復。
• 對緩存增長多個副本，緩存異常或請求 miss 後，再讀取其餘緩存副本。
• ehcache 本地緩存 + Hystrix 限流&降級，避免 MySQL被打死
• 業務 DB 的訪問增長讀寫開關，當發現 DB 請求變慢、阻塞，慢請求超過閥值時，就會關閉讀開關，部分或全部讀 DB 的請求進行 failfast 當即返回，待 DB 恢復後再打開讀開關。

數據不一致

數據不一致的概念很簡單：就是緩存中的數據和數據庫中的數據不一致。

那爲何會不一致呢？咱們的數據被緩存以後，一旦數據被修改（修改時也是刪除緩存中的數據）或刪除，咱們就須要同時操做緩存和數據庫。這時就會存在一個數據不一致的問題。

如上圖所示當咱們先刪除數據庫再去操做緩存，緩存中未刪除數據庫其實已經不存在該數據了。這個時候就會出現緩存不一致的狀況。

聰明的小夥伴確定想到了咱們仍是須要先作緩存刪除操做，再去完成數據庫操做。則會去數據庫中查詢，若是緩存中沒有該數據，則會去數據庫中查詢，以後再放入到緩存中。這樣就完美了嘛？答案確定不會這麼簡單。請看下圖:

解決方案

這裏其實沒有什麼很完美的解決方法。能夠將變動的 key 添加到安全隊列中。當另外一個查詢請求 B 進來時，若是發現緩存中沒有該值，則會先去隊列中查看該數據是否正在被更新或刪除，若是隊列中有該數據，則阻塞等待，直到 A 操做數據庫成功以後，喚醒該阻塞線程，再去數據庫中查詢該數據。這裏其實也是有不少缺陷的。線程須要阻塞等待。

最好的解決方案就是若是數據更新比較頻繁且對數據有必定的一致性要求，我一般不建議使用緩存。看到這裏是否是發出了一句切！！！！

5 總結

緩存雖然能大幅度的提升服務器的性能以及用戶的體驗感。可是隨着而來的就是各類因爲緩存致使的一系列問題。因此當咱們使用緩存的過程當中須要注意以上的經典問題。

目錄

• 作了15年的技術開發後，我確實焦慮了。。。

• 40 個 Java 多線程問題總結

• 看完這篇操做系統，和麪試官扯皮就沒問題了。