一、什么是緩存

緩存（cache）是計算機中的一個經典的概念，在很多場景中都會涉及到。核心思路就是把一些常用的數據放到觸手可及（訪問速度更快）的地方，方便隨時讀取。

舉例：我需要去高鐵站坐高鐵，坐高鐵是需要反復刷身份證的（進入高鐵站、檢票、上車、乘車過程中、出站...）。正常來說，我的身份證是放在行李箱里的（行李箱的存儲空間大，足夠能裝），但是每次刷身份證都需要開一次行李箱找身份證就非常不方便。因此我就可以把身份證先放到口袋里，雖然口袋空間小，但是訪問速度比行李箱快很多。這樣的話每次刷身份證我只需要從口袋里掏身份證就行了，就不必打開行李箱了。此時 “口袋” 就是 “皮箱” 的緩存，使用緩存能夠大大提高訪問效率。

這里所說的 “觸手可及” 是個相對的概念。對于硬件的訪問速度來說，通常情況下：CPU 寄存器 > 內存 > 硬盤 > 網絡。那么硬盤相對于網絡來說是 “觸手可及的”，就可以使用硬盤作為網絡的緩存。內存相對于硬盤是 “觸手可及的”，就可以使用內存作為硬盤的緩存。CPU 寄存器相對于內存是 “觸手可及的”，就可以使用 CPU 寄存器作為內存的緩存。

對于計算機硬件來說，往往訪問速度越快的設備成本越高，存儲空間越小。緩存是更快，但是空間上往往是不足的，因此大部分的時候，緩存只放一些熱點數據（訪問頻繁的數據），就非常有用

關于 “二八定律”：20% 的熱點數據能夠應對 80% 的訪問場景。因此只需要把這少量的熱點數據緩存起來，就可以應對大多數場景，從而在整體上有明顯的性能提升。

二、使用?Redis 作為緩存

在一個網站中，經常會使用關系型數據庫（比如 MySQL）來存儲數據。關系型數據庫雖然功能強大，但是有一個很大的缺陷：性能不高（換而言之，進行一次查詢操作消耗的系統資源較多）。

為什么說關系型數據庫性能不高？

1. 數據庫把數據存儲在硬盤上，硬盤的 IO 速度并不快，尤其是隨機訪問。
2. 如果查詢不能命中索引，就需要進行表的遍歷，這就會大大增加硬盤 IO 次數。
3. 關系型數據庫對于 SQL 的執行會做一系列的解析、校驗、優化工作。
4. 如果是?些復雜查詢，比如聯合查詢，需要進行笛卡爾積操作，效率更是降低很多。

因此，如果訪問數據庫的并發量比較高，對于數據庫的壓力是很大的，很容易就會使數據庫服務器宕機。

為什么并發量高了就會宕機？

服務器每次處理一個請求，都是需要消耗一定的硬件資源的。所謂的硬件資源包括不限于 CPU、內存、硬盤、網絡帶寬... ... ?個服務器的硬件資源本身是有限的，一個請求消耗一份資源，請求多了自然把資源就耗盡了。后續的請求沒有資源可用，自然就無法正確處理，更嚴重的還會導致服務器程序的代碼出現崩潰。

如何讓數據庫能夠承擔更大的并發量呢?

核心思路主要是兩個：

• 開源：引入更多的機器，部署更多的數據庫實例，構成數據庫集群（主從復制、分庫分表等...）。
• 節流：引入緩存，使用其他的方式保存經常訪問的熱點數據，從而降低直接訪問數據庫的請求數量。

實際開發中，這兩種方案往往是會搭配使用的。

Redis 就是一個用來作為數據庫緩存的常見方案

Redis 訪問速度比 MySQL 快很多，或者說處理同?個訪問請求，Redis 消耗的系統資源比 MySQL 少很多，因此 Redis 能支持的并發量更大。

• Redis 數據在內存中，訪問內存比硬盤快很多。
• Redis 只是支持簡單的 key-value 存儲，不涉及復雜查詢的那么多限制規則。

• 客戶端訪問業務服務器，發起查詢請求。
• 業務服務器先查詢 Redis，看想要的數據是否在 Redis 中存在。

1. 如果已經在 Redis 中存在了就直接返回，此時不必訪問 MySQL 了。
2. 如果在 Redis 中不存在，再查詢 MySQL。

注意：緩存是用來加快 “讀操作”?的速度的，如果是 “寫操作”，還是要老老實實寫數據庫，緩存并不能提高性能。

三、緩存的更新策略

到底哪些數據才是 “熱點數據”?呢？

1、定期生成

每隔一定的周期（比如一天 / 一周 / 一個月），對于訪問的數據頻次進行統計，挑選出訪問頻次最高的前 N% 的數據。

以搜索引擎為例：用戶在搜索引擎中會輸入一個 “查詢詞”，有些詞是屬于高頻的，大家都愛搜（鮮花、蛋糕、交友...），有些詞就屬于低頻的，大家很少搜。

搜索引擎的服務器會把哪個用戶在什么時間搜了什么詞，都通過日志的方式記錄的明明白白，然后每隔一段時間對這期間的搜索結果進行統計

上面這種做法實時性較低，對于一些突然情況應對的并不好。比如春節期間，“春晚”?這樣的詞就會成為非常高頻的詞，而平時則很少會有人搜索 “春晚”。

2、實時生成

先給緩存設定容量上限（可以通過 Redis 配置文件的?maxmemory?參數設定），接下來把用戶每次查詢：

• 如果在 Redis 查到了，就直接返回。
• 如果 Redis 中不存在，就從數據庫查，把查到的結果同時也寫入?Redis。（經過一段時間的 “動態平衡”，redis 中的 key 就逐漸成了熱點數據）

如果緩存已經滿了（達到上限），就觸發緩存淘汰策略，把?些 “相對不那么熱門”?的數據淘汰掉。按照上述過程持續一段時間之后 Redis 內部的數據自然就是 “熱門數據”?了。

通用的淘汰策略主要有以下幾種：

下列策略并非局限于 Redis，其他緩存也可以按這些策略展開。

1. 把緩存中存在時間最久的（也就是先來的數據）淘汰掉。
2. 記錄每個 key 的最近訪問時間，把最近訪問時間最?的 key 淘汰掉。
3. 記錄每個 key 最近?段時間的訪問次數，把訪問次數最少的淘汰掉。
4. 從所有的 key 中抽取幸運兒被隨機淘汰掉。

四、緩存預熱、緩存穿透、緩存雪崩和緩存擊穿

1、關于緩存預熱（Cache preheating）

（1）什么是緩存預熱

使用 Redis 作為 MySQL 的緩存的時候，當 Redis 剛剛啟動或者 Redis 大批 key 失效之后，此時由于 Redis 服務器是沒有什么緩存數據的，那么所有的請求就會打給 MySQL，MySQL 就可能直接被訪問到，從而造成較大的壓力。隨著時間的推移，redis 上的數據積累的越來越多，MySQL 承擔的壓力也就越來越小。因此就需要提前把熱點數據準備好，直接寫入到 Redis 中，使 Redis 可以盡快為 MySQL 撐起保護傘。

熱點數據可以基于之前介紹的統計的方式生成即可。這份熱點數據不一定非得那么 “準確”，只要能幫助 MySQL 抵擋大部分請求即可。隨著程序運行的推移，緩存的熱點數據會逐漸自動調整，來更適應當前情況。?

2、關于緩存穿透（Cache penetration）

（1）什么是緩存穿透

訪問的 key 在 Redis 和 數據庫中都不存在，此時這樣的 key 不會被放到緩存上，后續如果仍然在訪問該 key，依然會訪問到數據庫，這就會導致數據庫承擔的請求太多，壓力很大。這種情況稱為緩存穿透。

（2）為什么會產生緩存穿透

• 業務設計不合理。比如缺少必要的參數校驗環節，導致非法的 key 也被進行查詢了。
• 開發 / 運維誤操作。不小新把部分數據從數據庫上誤刪了。
• 黑客惡意攻擊。

（3）如何解決緩存穿透

1. 針對要查詢的參數進行嚴格的合法性校驗，比如要查詢的 key 是用戶的手機號，那么就需要校驗當前 key 是否滿足?個合法的手機號的格式。
2. 針對數據庫上也不存在的 key , 也存儲到 Redis 中，比如 value 就隨便設成?個 ""，避免后續頻繁訪問數據庫。
3. 使用布隆過濾器先判定 key 是否存在，再真正查詢。?

3、關于緩存雪崩（Cache avalanche）

（1）什么是緩存雪崩

短時間內大量的 key 在緩存上失效，導致數據庫壓力驟增，甚至直接宕機。本來 Redis 是 MySQL 的一個護盾，幫 MySQL 抵擋了很多外部的壓力。一旦護盾突然失效了，MySQL 自身承擔的壓力驟增，就可能直接崩潰。

（2）為什么會產生緩存雪崩

大規模 key 失效，其可能性主要有兩種：

1. Redis 掛了。
2. Redis 上的大量的 key 同時過期。

為什么會出現大量的 key 同時過期?

這種和可能是短時間內在 Redis 上緩存了大量的 key，并且設定了相同的過期時間。

（3）如何解決緩存雪崩

• 部署高可用的 Redis 集群，并且完善監控報警體系。
• 不給 key 設置過期時間或者設置過期時間的時候添加隨機時間因子。?

4、關于緩存擊穿（Cache breakdown）

（1）什么是緩存擊穿

此處把 breakdown 翻譯成 “擊穿”，我以為并非是?個好的選擇，容易和緩存穿透混淆，翻譯成 “癱瘓”?/?“崩潰”?也許更合適一些。

相當于緩存雪崩的特殊情況，針對熱點 key，突然過期了，導致大量的請求直接訪問到數據庫上，甚至引起數據庫宕機。

（2）如何解決緩存擊穿

• 基于統計的方式發現熱點 key，并設置永不過期。
• 進行必要的服務降級。例如訪問數據庫的時候使用分布式鎖，限制同時請求數據庫的并發數。