緩存穿透

現(xiàn)象

1. 應(yīng)用服務(wù)器壓力變大了，很多請求過來
2. redis命中率降低
3. 一直查詢數(shù)據(jù)庫（緩存中很多數(shù)據(jù)查詢到，就查數(shù)據(jù)庫，導(dǎo)致數(shù)據(jù)庫壓力增加）

原因

• Redis查詢緩存中不存在的數(shù)據(jù)
• 出現(xiàn)很多非正常的url訪問，一般出現(xiàn)在收到惡意攻擊的時候，根據(jù)正常的url來改變值來惡意攻擊服務(wù)器

解決方案

• 對空值緩存：對查不到的數(shù)據(jù)做空值緩存，并設(shè)置空結(jié)果的過期時間，最長不超過五分鐘
• 設(shè)置可訪問的名單(白名單)：使用Redis的bitmaps類型定義一個可訪問的名單，名單id作為bitmaps的偏移量，每次訪問和bitmaps里面的id進行比較，不在的話，做攔截處理
• 采用布隆過濾器
• 進行實時監(jiān)控：人為的排查分析

緩存擊穿

現(xiàn)象特點

1. 數(shù)據(jù)庫訪問壓力瞬時增大
2. redis里面沒有出現(xiàn)大量key過期
3. redis正常運行

原因

Redis某個key過期了，大量訪問使用這個key

解決方案

1. 預(yù)先設(shè)置熱門數(shù)據(jù)：在redis高峰訪問之前，把一些熱門數(shù)據(jù)提前存入到redis里面，加大key的時長
2. 實時調(diào)整：現(xiàn)場監(jiān)控?zé)衢T數(shù)據(jù)，實時調(diào)整key的過期時長
3. 使用鎖（能避免這種情況，但是去點在于效率低下）

• 在緩存失效的時候（判斷拿出來的值為空），不是立即去load db
• 先使用緩存工具的某些帶成功的操作返回值的操作（比如setnx）去set一個mutex key
• 當(dāng)操作返回成功時，在進行l(wèi)oad db的操作，并設(shè)緩存，最后刪除mutex key
• 當(dāng)操作返回失敗時，證明有現(xiàn)成在load db操作，當(dāng)前線程睡眠一段時間再重試整個get緩存的方法

緩存雪崩

現(xiàn)象

1. 數(shù)據(jù)庫壓力變大，服務(wù)器崩潰

原因

在極少時間段，查詢大量key的集中過期情況

解決方案

• 構(gòu)建多級緩存架構(gòu)：nginx緩存+redis緩存+其他緩存
• 使用鎖或者隊列：用加鎖或者隊列的方式保證不會有大量的線程對數(shù)據(jù)庫一次性進行讀寫，從而避免失效時大量的并發(fā)請求落到底層存儲系統(tǒng)上。不適合高并發(fā)的情形
• 設(shè)置過期標志更新緩存，通過緩存reload機制，預(yù)先更新緩存，在即將發(fā)生大并發(fā)前手動觸發(fā)加載緩存
• 將緩存失效時間分散開

Redis實現(xiàn)分布式鎖

分布式鎖實現(xiàn)方案

• 基于數(shù)據(jù)庫實現(xiàn)分布式鎖
• 基于緩存實現(xiàn)（Redis等）
• 基于Zookeeper

上述實現(xiàn)方式Redis性能最高，Zookeeper最可靠

Redis實現(xiàn)

1. 最簡單的使用setnx上鎖，del解鎖，但是此時有問題，若設(shè)置鎖了，長時間不釋放鎖又會導(dǎo)致后續(xù)資源拿不到鎖的情形
2. 上述1中鎖一直不釋放的話，可以設(shè)置過期時間來解決這個問題，時間到了自動釋放

setnx users name1
expire users 10

3. 上述2案例有個問題，就是這個不是原子的，設(shè)置鎖后，突然故障，無法設(shè)置過期時間，也會導(dǎo)致問題，因為Redis的操作是原子的，可以使用指令，加鎖設(shè)置過期時間同時操作

set users name1 nx ex 5

分布式下鎖誤刪除

出現(xiàn)情形

假設(shè)a和b兩個線程，a線程先獲取分布式鎖，然后由于業(yè)務(wù)操作或者服務(wù)器卡頓等一系列操作造成a線程的鎖過期自動失效釋放了（而a線程還沒有數(shù)據(jù)處理完）

a釋放鎖后，b線程獲取了鎖執(zhí)行具體操作，此時a突然操作完了，然后釋放了鎖，而不是b主動釋放的

這種情形就造成了鎖誤刪除的情形

解決方案

1. 將鎖的值設(shè)置成uuid，唯一標識，set lock uuid nx ex 10，
2. 釋放鎖的時候首先判斷當(dāng)前uuid是否和要釋放鎖的uuid一樣，一樣釋放，不一樣不釋放

Redis分布式鎖——加鎖釋放鎖的原子性優(yōu)化

造成問題

在上述案例中的當(dāng)a上鎖，執(zhí)行具體操作的時候，然后釋放鎖步驟，也遇到了比較鎖的uuid值一樣，恰巧在del操作要執(zhí)行之前（也就是比較完成之后，刪除操作之前）鎖過期自動釋放了，然后b線程獲取了鎖，還在執(zhí)行具體的操作，a刪除的是b的鎖，這就造成的分布式下安全隱患

解決方案

在比較刪除步驟嵌入原子性的LUA腳本在釋放鎖的比較釋放進行做原子化操作

總結(jié)

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

最新評論