緩存

在業(yè)務(wù)開發(fā)中，必然會存在需要頻繁訪問的數(shù)據(jù)即熱點數(shù)據(jù)，如果通過訪問數(shù)據(jù)庫訪問這些數(shù)據(jù)，由于數(shù)據(jù)存儲在磁盤上，在頻繁訪問下會進行頻繁的IO操作，會導致數(shù)據(jù)庫壓力過大，響應(yīng)速度變慢。

那么我們可以在添加一層中間緩存層，將熱點數(shù)據(jù)緩存在內(nèi)存中，在訪問數(shù)據(jù)時我們不在直接查詢數(shù)據(jù)庫，而是先訪問緩存，如果數(shù)據(jù)存在（命中），直接返回即可。如果數(shù)據(jù)不存在（未命中），再訪問數(shù)據(jù)庫。

redis 將數(shù)據(jù)存儲在內(nèi)存中，因此可以提供接近于內(nèi)存的訪問速度。所以 redis 天然適合作為緩存層。

緩存并不是萬能的，實際上緩存更使用于讀密集場景，在寫密集場景中由于需要保證緩存于數(shù)據(jù)庫的一致性，在修改緩存時還需要修改數(shù)據(jù)庫，反而加重了后端壓力。

緩存優(yōu)缺點

優(yōu)點：

• 降低后端負載
• 提高讀寫效率，降低響應(yīng)時間

缺點：

• 增加數(shù)據(jù)一致性成本
• 增加代碼維護成本

緩存更新策略

為了保證緩存數(shù)據(jù)有效，我們需要更新緩存。這里主要有六種緩存更新策略：

超時剔除

在 redis 中我們可以設(shè)置數(shù)據(jù)的生存時間（TTL），在超時后，redis會自動刪除緩存，在下次查詢該數(shù)據(jù)時，由于緩存不存在，會重新寫入緩存，完成更新。

這種方法實現(xiàn)簡單，但一致性一般，在緩存未過期之前，對數(shù)據(jù)庫的數(shù)據(jù)進行增刪查改都不會影響緩存，用戶查到的數(shù)據(jù)始終是舊數(shù)據(jù)。

先刪緩存再更新數(shù)據(jù)庫

在對數(shù)據(jù)庫進行更新時，先刪除緩存，然后更新數(shù)據(jù)，在下次查詢該數(shù)據(jù)時，由于緩存不存在，會重新將新數(shù)據(jù)寫入緩存，完成更新。

這種方法也無法保證數(shù)據(jù)的一致性。假設(shè)有兩個線程，線程A 與 線程B ， 在線程 A 更新緩存時，線程 B 發(fā)起查詢，可能出現(xiàn)這種情況：

在這種情況下，一直到下次數(shù)據(jù)更新之前，緩存始終不一致，因此不推薦使用這種方法。

旁路緩存(先更新數(shù)據(jù)庫，再刪緩存）

在更新數(shù)據(jù)時，先更新數(shù)據(jù)庫，再刪除緩存，在下次查詢該數(shù)據(jù)時，由于緩存不存在，會重新將新數(shù)據(jù)寫入緩存，完成更新。

這種方法同樣無法完全保證數(shù)據(jù)的一致性，但他是最常用的更新策略。因為它發(fā)生問題的概況較小，假設(shè)有兩個線程，線程A 與 線程B ， 在線程 B 更新數(shù)據(jù)庫時，線程 A 發(fā)起查詢，可能出現(xiàn)這種情況：

同樣這種情況會出現(xiàn)數(shù)據(jù)不一致問題，但這種情況出現(xiàn)概率非常小，出現(xiàn)這種情況需要至少滿足四個條件：

• 讀操作所讀數(shù)據(jù)緩存失效
• 有個并發(fā)的寫操作
• 寫操作比讀操作更快
• 讀操作早于寫操作進入數(shù)據(jù)庫，晚于寫操作更新緩存

這樣的條件是十分苛刻的，即使發(fā)生也是小概率事件，即使出現(xiàn)也可以通過緩存生存時間兜底。

這種方法最大的問題是刪除緩存后的并發(fā)問題即緩存擊穿問題，在緩存常見問題我們會介紹。

先更新數(shù)據(jù)庫，再更新緩存

在更新數(shù)據(jù)時，先更新數(shù)據(jù)庫，再更新緩存。

理論上這種方式比先更新數(shù)據(jù)庫再刪緩存有著更高的讀性能，因為它事先準備好數(shù)據(jù)。但由于要更新數(shù)據(jù)庫和緩存兩塊數(shù)據(jù)，所以它的寫性能就比較低，同時他也不能完全保證數(shù)據(jù)的一致性。

假設(shè)有兩個線程，線程A 與 線程B ， 在線程 A B 同時更新，可能出現(xiàn)這種情況：

讀寫穿透

客戶端只與緩存交互，緩存負責與數(shù)據(jù)庫的交互。

讀操作先查詢緩存，如果緩存未命中，則緩存從數(shù)據(jù)庫加載數(shù)據(jù)并寫入緩存。寫操作是直接寫緩存，然后緩存同步更新數(shù)據(jù)庫。這種模式下，緩存和數(shù)據(jù)庫的一致性由緩存中間件維護。

異步緩存寫入模式

客戶端只與緩存交互，緩存異步地將數(shù)據(jù)更新到數(shù)據(jù)庫，實現(xiàn)最終一致性。

這種模式適用于寫操作頻繁的場景，但可能會導致數(shù)據(jù)一致性問題。

緩存常見問題

使用緩存比較常見的問題有下面三種問題：緩存擊穿，緩存雪崩，緩存穿透。

緩存穿透

在我們的業(yè)務(wù)邏輯中，如果客戶端訪問的數(shù)據(jù)不存在于緩存我們會訪問數(shù)據(jù)庫，如果數(shù)據(jù)庫存在數(shù)據(jù)就寫入緩存，如果不存在就返回，那么如果客戶端不懷好意，頻繁發(fā)起對不存在數(shù)據(jù)的請求會發(fā)生什么呢？大量請求會直接打入數(shù)據(jù)庫，增大后端壓力，實現(xiàn)對服務(wù)器的攻擊。

解決方案有很多種，最常見的有兩種方法：緩存空對象，布隆過濾器。

緩存空對象：當請求的數(shù)據(jù)在數(shù)據(jù)庫中不存在時，我們將這個“不存在”的結(jié)果緩存起來，設(shè)置一個較短的過期時間。 這樣，相同的請求在緩存失效之前會直接命中緩存，減輕數(shù)據(jù)庫的壓力。

布隆過濾器：使用布隆過濾器存儲所有可能查詢的鍵，當請求到達時，先通過布隆過濾器判斷鍵是否存在。如果布隆過濾器認為鍵不存在，則直接返回，不進行數(shù)據(jù)庫查詢和緩存操作。

緩存雪崩

緩存雪崩是指在高并發(fā)系統(tǒng)中，大量的緩存數(shù)據(jù)在同一時間過期或被清除，導致大量請求同時涌向數(shù)據(jù)庫，從而對數(shù)據(jù)庫造成巨大壓力，甚至可能導致數(shù)據(jù)庫宕機。類似于“雪崩”。

常見的解決方法有以下幾種：

設(shè)置不同的過期時間： 對于緩存中的每個數(shù)據(jù)項，設(shè)置不同的過期時間，這樣可以避免大量數(shù)據(jù)同時過期。例如，可以為每個數(shù)據(jù)項的過期時間加上一個隨機值。

使用互斥鎖： 當緩存數(shù)據(jù)過期時，如果多個請求同時到達，使用互斥鎖確保只有一個請求去查詢數(shù)據(jù)庫并更新緩存，其他請求等待或重試。

熱點數(shù)據(jù)永不過期： 對于訪問非常頻繁的熱點數(shù)據(jù)，可以考慮設(shè)置為永不過期，或者設(shè)置一個非常長的過期時間。

緩存擊穿

在高并發(fā)的訪問下，當某個熱點數(shù)據(jù)緩存處于過期失效的時間點時，極有可能出現(xiàn)多個線程同時查詢該緩存。而查詢數(shù)據(jù)庫更新緩存又需要消耗一定時間，在同一時間會有大量并發(fā)請求直接訪問數(shù)據(jù)庫而導致數(shù)據(jù)庫服務(wù)器的CPU或者內(nèi)存負載過高，服務(wù)能力下降甚至宕機。

那么如何解決這個問題呢？有三種解決方案。

• 加鎖：在緩存失效后，通過加鎖的方式只允許一個線程查詢數(shù)據(jù)和寫緩存，其他線程阻塞等待。這個方法會造成部分請求等待。
• 二級緩存：A1為原始緩存，A2為拷貝緩存。A1失效時，可以訪問A2，其中A1的緩存失效時間設(shè)置為短期（比如5min），A2的緩存失效時間設(shè)置為長期（比如1天）。如果緩存value很大，此方案的緩存空間利用率低。
• 雙key：思路和方案2類似，不同的是雙key分別緩存過期時間（key-time)和緩存數(shù)據(jù)（key-data），其中(key-time)的緩存失效時間設(shè)置為短期（比如5min），(key-data)的緩存失效時間設(shè)置為長期（比如1天）。當?shù)谝粋€線程發(fā)現(xiàn) key-time 過期不存在時，則先更新key-time，然后去查詢數(shù)據(jù)庫并更新key-data 的值；當其他線程來獲取數(shù)據(jù)時，雖然第一個線程還沒有從數(shù)據(jù)庫查詢完畢并更新緩存，但發(fā)現(xiàn)key-time存在，會直接讀取緩存的舊數(shù)據(jù)返回。和二級緩存的方案對比，該方案的緩存空間利用率高。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論