高並發請求的緩存設計策略

https://www.cnblogs.com/bethunebtj/p/9159914.html

前幾天，我司出了個簍子。當時正值某喜聞樂見的關鍵比賽結束，一堆人打開我司app準備看點東西，結果從來沒有感受到過這麽多關註量的該功能瞬間幸福到眩暈，觸發了熔斷，結果就是大量興致沖沖打開app準備看該比賽結果的人被迫刷了十分鐘三天前的野外跑酷，負責內容的人火大到直接罵娘。

雖然這個業務不是我負責，但是也跟相關的人聊了下情況，感慨了一下，於是有了這一篇文章。

1.為何需要緩存？
在高並發請求時，為何我們頻繁提到緩存技術？最直接的原因是，目前磁盤IO和網絡IO相對於內存IO的成百上千倍的性能劣勢。

通過將高頻使用的數據存在離cpu更近的位置，以減少數據傳輸時間，從而提高處理效率，這就是緩存的意義。

2.在哪裏用緩存？
一切地方。例如：

我們從硬盤讀數據的時候，其實操作系統還額外把附近的數據都讀到了內存裏
例如，CPU在從內存裏讀數據的時候，也額外讀了許多數據到各級cache裏
各個輸入輸出之間用buffer保存一批數據統一發送和接受，而不是一個byte一個byte的處理

瀏覽器會緩存頁面的元素，這樣在重復訪問網頁時，就避開了要從互聯網上下載數據（例如大圖片）
web服務會把靜態的東西提前部署在CDN上，這也是一種緩存
數據庫會緩存查詢，所以同一條查詢第二次就是要比第一次快
內存數據庫（如redis）選擇把大量數據存在內存而非硬盤裏，這可以看作是一個大型緩存，只是把整個數據庫緩存了起來
應用程序把最近幾次計算的結果放在本地內存裏，如果下次到來的請求還是原請求，就跳過計算直接返回結果
3.本次事故分析
回到本文開始的問題上，該系統是怎麽設計的呢？底層是數據庫，中間放了一層redis，前面的業務系統所需的數據都直接從redis裏取，然後計算出結果返回給app；數據庫和redis的同步另外有程序保證，避免redis的穿透，防止了程序裏出現大量請求從redis裏找不到，於是又一窩蜂的去查數據庫，直接壓垮數據庫的情況。從這個角度講，其實這一步是做的還可以的。

但是這個系統有兩個問題：
1.業務系統需要的數據雖然都在redis裏，但是是分開存放的。什麽意思呢，比如我前臺發起一個請求，後臺先去redis裏取一下標題，然後再取一下作者，然後再取一下內容，再取一下評論，再取一下轉發數等等……結果前臺一次請求，後臺要請求redis十幾次。高並發的時候，壓力一下被放大十幾倍，redis響應、網絡響應必然會變慢。
2.其實做業務的那波人也意識到了這個情況可能發生，所以做了熔斷機制，另起了一個緩存池，裏面放了一些備用數據，如果主業務超時，直接從緩存池裏取數據返回。但是他們設計的時候沒想周全，這個備選池的數據過期時間設計的太長了，裏面居然還有三天前更新進去的數據，最終導致了一大波用戶刷出來三天前的野外生態小視頻……

說到這，不知道讀者有沒有意識到他們最致命的一個問題：這個業務系統完全沒有考慮本地緩存（也就是在業務服務器內存裏做緩存）。比如像我們這種app，一旦大量用戶同一時間湧進來，必定都是奔著少數幾個內容去的，這種特別集中的高頻次極少量數據訪問，又不需要對每個用戶做特化的，簡直就是在臉上寫上“請緩存我”。
這時候，如果能在業務端做一層本地緩存，直接把算好的數據本地存一份，那麽就會極大減少網絡和redis的壓力，不至於當場觸發熔斷了。

4.淺談緩存的那些坑
緩存很有用，但是緩存用不好也會埋很多坑：

緩存穿透
緩存穿透是說收到了一個請求，但是該請求緩存裏沒有，只能去數據庫裏查詢，然後放進緩存。這裏面有兩個風險，一個是同時有好多請求訪問同一個數據，然後業務系統把這些請求全發到了數據庫；第二個是有人惡意構造一個邏輯上不存在的數據，然後大量發送這個請求，這樣每次請求都會被發送到數據庫，可能導致數據掛掉。

怎麽應對這種情況呢？對於惡意訪問，一個思路是事先做校驗，對惡意數據直接過濾掉，不要發到數據庫層；第二個思路是緩存空結果，就是對查詢不存在的數據仍然記錄一條該數據不存在在緩存裏，這樣能有效的減少查詢數據庫的次數。

那麽非惡意訪問呢？這個要結合緩存擊穿來講。

緩存擊穿
上面提到的某個數據沒有，然後好多請求都被發到數據庫其實可以歸為緩存擊穿的範疇：對於熱點數據，當數據失效的一瞬間，所有請求都被下放到數據庫去請求更新緩存，數據庫被壓垮。

怎麽防範這種問題呢？一個思路是全局鎖，就是所有訪問某個數據的請求都共享一個鎖，獲得鎖的那個才有資格去訪問數據庫，其他線程必須等待。但是現在的業務都是分布式的，本地鎖沒法控制其他服務器也等待，所以要用到全局鎖，比如用redis的setnx實現全局鎖。

另一個思路是對即將過期的數據主動刷新，做法可以有很多，比如起一個線程輪詢數據，比如把所有數據劃分為不同的緩存區間，定期分區間刷新數據等等。這第二個思路又和我們接下來要講的緩存雪崩有關系。

緩存雪崩
緩存雪崩是指比如我們給所有的數據設置了同樣的過期時間，然後在某一個歷史性時刻，整個緩存的數據全部過期了，然後瞬間所有的請求都被打到了數據庫，數據庫就崩了。

解決思路要麽是分治，劃分更小的緩存區間，按區間過期；要麽是給每個key的過期時間加個隨機值，避免同時過期，達到錯峰刷新緩存的目的。

緩存刷新
說到刷新緩存，其實也有坑的。比如我之前的一份工作裏，有一次大活動，正是如火如荼的時候，所有的廣告位突然都變空白了。後來追查原因，所有的廣告素材都在緩存裏，然後起了個程序，專門負責刷新緩存，每次把當前的素材全量刷新。

壞就壞在這個全量上。因為大活動的時候流量極大，廣告更新壓力也很大，把負責提供更新素材的程序壓崩了。刷新緩存的程序在請求時，收到了一個返回結果Null。接下來就喜聞樂見了，刷新程序根據這個null，清空了整個緩存，所有廣告素材都失效了。

總之，想要做好高並發系統的緩存，就要考慮到各種邊角情況，小心設計，任何細小的疏忽都可能導致系統崩潰。

最後，歡迎關註我的公眾號，一起交流技術，或者職業生涯？

緩存設計策略