緩存穿透

現(xiàn)象

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

原因

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

解決方案

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

緩存擊穿

現(xiàn)象特點(diǎn)

1. 數(shù)據(jù)庫(kù)訪問(wèn)壓力瞬時(shí)增大
2. redis里面沒(méi)有出現(xiàn)大量key過(guò)期
3. redis正常運(yùn)行

原因

Redis某個(gè)key過(guò)期了，大量訪問(wèn)使用這個(gè)key

解決方案

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

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

緩存雪崩

現(xiàn)象

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

原因

在極少時(shí)間段，查詢大量key的集中過(guò)期情況

解決方案

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

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

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

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

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

Redis實(shí)現(xiàn)

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

setnx users name1
expire users 10

3. 上述2案例有個(gè)問(wèn)題，就是這個(gè)不是原子的，設(shè)置鎖后，突然故障，無(wú)法設(shè)置過(guò)期時(shí)間，也會(huì)導(dǎo)致問(wèn)題，因?yàn)镽edis的操作是原子的，可以使用指令，加鎖設(shè)置過(guò)期時(shí)間同時(shí)操作

set users name1 nx ex 5

分布式下鎖誤刪除

出現(xiàn)情形

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

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

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

解決方案

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

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

造成問(wèn)題

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

解決方案

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

總結(jié)

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

最新評(píng)論