Redis應?-緩存與分布式鎖

🌈 個人主頁：Zfox_
🔥 系列專欄：Redis

🔥 什么是緩存

緩存(cache)是計算機中的?個經典的概念.在很多場景中都會涉及到

核?思路就是把?些常?的數據放到觸?可及 (訪問速度更快) 的地?,?便隨時讀取

對于計算機硬件來說,往往訪問速度越快的設備,成本越?,存儲空間越?.

緩存是更快,但是空間上往往是不?的.因此?部分的時候,緩存只放?些熱點數據(訪問頻繁的數據), 就?常有?了.

在這里插入圖片描述

🔥 使?Redis作為緩存

在?個?站中,我們經常會使?關系型數據庫(?如MySQL)來存儲數據.

關系型數據庫雖然功能強?,但是有?個很?的缺陷,就是性能不?.(換??之,進??次查詢操作消耗的系統資源較多).
在這里插入圖片描述
因此,如果訪問數據庫的并發量?較?,對于數據庫的壓?是很?的,很容易就會使數據庫服務器宕機.

在這里插入圖片描述
如何讓數據庫能夠承擔更?的并發量呢?核?思路主要是兩個:

開源:引?更多的機器,部署更多的數據庫實例,構成數據庫集群.(主從復制,分庫分表等…)
節流:引?緩存,使?其他的?式保存經常訪問的熱點數據,從?降低直接訪問數據庫的請求數量.

實際開發中,這兩種?案往往是會搭配使?的.

Redis就是?個?來作為數據庫緩存的常??案.

在這里插入圖片描述
就像?個"護盾"?樣,把MySQL給罩住了.

在這里插入圖片描述

客戶端訪問業務服務器,發起查詢請求.
業務服務器先查詢Redis,看想要的數據是否在Redis中存在.
- 如果已經在Redis中存在了,就直接返回.此時不必訪問MySQL了.
- 如果在Redis中不存在,再查詢MySQL.

按照上述討論的"??定律",只需要在Redis中放20%的熱點數據,就可以使80%的請求不再真正查詢數據庫了.

當然,實踐中究竟是"??",還是"?九",還是"三七",這個情況可能會根據業務場景的不同,存在差異.但是?少絕?多數情況下,使?緩存都能夠??提升整體的訪問效率,降低數據庫的壓?.

🔥 緩存的更新策略

接下來還有?個重要的問題,到底哪些數據才是"熱點數據"呢?

🦋 定期?成

每隔?定的周期 (?如 ?天/?周/?個? ),對于訪問的數據頻次進?統計.挑選出訪問頻次最?的前N%的數據.

在這里插入圖片描述
這種做法實時性較低.對于?些突然情況應對的并不好.

?如春節期間,"春晚"這樣的詞就會成為?常?頻的詞.?平時則很少會有?搜索"春晚".

🦋 實時?成

先給緩存設定容量上限 (可以通過Redis配置?件的 maxmemory 參數設定)

接下來把?戶每次查詢:

如果在Redis查到了,就直接返回.
如果Redis中不存在,就從數據庫查,把查到的結果同時也寫?Redis.

如果緩存已經滿了(達到上限),就觸發緩存淘汰策略,把?些"相對不那么熱?"的數據淘汰掉.

按照上述過程,持續?段時間之后Redis內部的數據?然就是"熱?數據"了.

通?的淘汰策略主要有以下?種:

下列策略并?局限于Redis,其他緩存也可以按這些策略展開.

FIFO(FirstInFirstOut)先進先出

把緩存中存在時間最久的(也就是先來的數據)淘汰掉.

LRU(LeastRecentlyUsed)淘汰最久未使?的

記錄每個key的最近訪問時間.把最近訪問時間最?的key淘汰掉.

LFU(LeastFrequentlyUsed)淘汰訪問次數最少的

記錄每個key最近?段時間的訪問次數.把訪問次數最少的淘汰掉.

Random隨機淘汰

從所有的key中抽取幸運?被隨機淘汰掉.
在這里插入圖片描述
這?的淘汰策略,我們可以??實現.當然Redis也提供了內置的淘汰策略,也可以供我們直接使?.

Redis內置的淘汰策略如下:

volatile-lru 當內存不?以容納新寫?數據時，從設置了過期時間的 key 中使? LRU（最近最少使?）算法進?淘汰
allkeys-lru 當內存不?以容納新寫?數據時，從所有 key 中使? LRU（最近最少使?）算法進?淘汰
volatile-lfu 4.0 版本新增，當內存不?以容納新寫?數據時，在過期的 key 中，使? LFU 算法進?刪除key
allkeys-lfu 4.0 版本新增，當內存不?以容納新寫?數據時，從所有 key 中使? LFU 算法進?淘汰
volatile-random 當內存不?以容納新寫?數據時，從設置了過期時間的 key 中，隨機淘汰數據.
allkeys-random 當內存不?以容納新寫?數據時，從所有 key 中隨機淘汰數據.
olatile-ttl 在設置了過期時間的 key 中，根據過期時間進?淘汰，越早過期的優先被淘汰. (相當于FIFO,只不過是局限于過期的key)
noeviction 默認策略，當內存不?以容納新寫?數據時，新寫?操作會報錯

整體來說Redis提供的策略和我們上述介紹的通?策略是基本?致的.只不過Redis這?會針對"過期 “key"和"全部key"做分別處理.

🔥 緩存預熱,緩存穿透,緩存雪崩和緩存擊穿

🦋 什么是緩存預熱(Cachepreheating)

使?Redis作為MySQL的緩存的時候,當Redis剛剛啟動,或者Redis?批key失效之后,此時由于Redis??相當于是空著的,沒啥緩存數據,那么MySQL就可能直接被訪問到,從?造成較?的壓?.

因此就需要提前把熱點數據準備好,直接寫?到Redis中.使Redis可以盡快為MySQL撐起保護傘.

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

🦋 什么是緩存穿透?(Cachepenetration)

訪問的key在Redis和數據庫中都不存在.此時這樣的key不會被放到緩存上,后續如果仍然在訪問該key,依然會訪問到數據庫.

這就會導致數據庫承擔的請求太多,壓?很?.

這種情況稱為緩存穿透.

🎀 為何產??

原因可能有?種:

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

如何解決?

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

在這里插入圖片描述

🦋 什么是緩存雪崩(Cacheavalanche)

短時間內?量的key在緩存上失效,導致數據庫壓?驟增,甚?直接宕機.

本來Redis是MySQL的?個護盾,幫MySQL抵擋了很多外部的壓?.?旦護盾突然失效了,MySQL??承擔的壓?驟增,就可能直接崩潰.

為何產??

?規模key失效,可能性主要有兩種:

Redis掛了.
Redis上的?量的key同時過期.

為啥會出現?量的key同時過期?
這種和可能是短時間內在Redis上緩存了?量的key,并且設定了相同的過期時間.

如何解決?

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

🦋 什么是緩存擊穿?(Cachebreakdown)

在這里插入圖片描述

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

如何解決?

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

🔥 什么是分布式鎖?

在?個分布式的系統中,也會涉及到多個節點訪問同?個公共資源的情況.此時就需要通過鎖來做互斥控制,避免出現類似于"線程安全"的問題.

?java的synchronized或者C++的std::mutex,這樣的鎖都是只能在當前進程中?效,在分布式的這種多個進程多個主機的場景下就?能為?了.

此時就需要使?到分布式鎖.
在這里插入圖片描述

🦋 分布式鎖的基礎實現

思路?常簡單.本質上就是通過?個鍵值對來標識鎖的狀態.

舉個例?:考慮買票的場景,現在?站提供了若?個?次,每個?次的票數都是固定的.

現在存在多個服務器節點,都可能需要處理這個買票的邏輯:先查詢指定?次的余票,如果余票>0,則設置余票值-=1

在這里插入圖片描述

顯然上述的場景是存在"線程安全"問題的,需要使?鎖來控制.

否則就可能出現"超賣"的情況.

此時如何進?加鎖呢?我們可以在上述架構中引??個Redis,作為分布式鎖的管理器.
在這里插入圖片描述
此時,如果買票服務器1嘗試買票,就需要先訪問Redis,在Redis上設置?個鍵值對.?如key就是?次,value隨便設置個值(?如1)

如果這個操作設置成功,就視為當前沒有節點對該001?次加鎖,就可以進?數據庫的讀寫操作.操作完成之后,再把Redis上剛才的這個鍵值對給刪除掉

如果在買票服務器1操作數據庫的過程中,買票服務器2也想買票,也會嘗試給Redis上寫?個鍵值對, key同樣是?次.但是此時設置的時候發現該?次的key已經存在了,則認為已經有其他服務器正在持有鎖,此時服務器2就需要等待或者暫時放棄
在這里插入圖片描述
但是上述?案并不完整

🦋 引?過期時間

當服務器1加鎖之后,開始處理買票的過程中,如果服務器1意外宕機了,就會導致解鎖操作(刪除該key)不能執?.就可能引起其他服務器始終?法獲取到鎖的情況

為了解決這個問題,可以在設置key的同時引?過期時間.即這個鎖最多持有多久,就應該被釋放

在這里插入圖片描述

注意!此處的過期時間只能使??個命令的?式設置

如果分開多個操作,?如setnx之后,再來?個單獨的expire,由于Redis的多個指令之間不存在關聯,并且即使使?了事務也不能保證這兩個操作都?定成功,因此就可能出現setnx成功,但是expire失敗的情況

此時仍然會出現?法正確釋放鎖的問題

🦋 引?校驗id

對于Redis中寫?的加鎖鍵值對,其他的節點也是可以刪除的.

?如服務器1寫??個"001":1這樣的鍵值對,服務器2是完全可以把"001"給刪除掉的.

當然,服務器2不會進?這樣的"惡意刪除"操作,不過不能保證因為?些bug導致服務器2把鎖誤刪除.

為了解決上述問題,我們可以引??個校驗id.

?如可以把設置的鍵值對的值,不再是簡單的設為?個1,?是設成服務器的編號.形如"001":"服務器1"

這樣就可以在刪除key(解鎖)的時候,先校驗當前刪除key的服務器是否是當初加鎖的服務器,如果是,才能真正刪除;不是,則不能刪除.

邏輯?偽代碼描述如下:

String key = [要加鎖的資源 id];
String serverId = [服務器的編號];// 加鎖, 設置過期時間為 10s
redis.set(key, serverId, "NX", "EX", "10s");// 執?各種業務邏輯, ?如修改數據庫數據.
doSomeThing();// 解鎖, 刪除 key. 但是刪除前要檢驗下 serverId 是否匹配.
if (redis.get(key) == serverId) {redis.del(key);
}

但是很明顯,解鎖邏輯是兩步操作"get"和"del",這樣做并?是原?的

如果一個服務器中的兩個線程都去解鎖，（由于不是原子的）可能會 del 兩次，這個時候又來了一個服務器set 鎖，然后就被第二個線程刪了

🦋引?lua

為了使解鎖操作原?,可以使?Redis的Lua腳本功能
https://www.lua.org/about.html
在這里插入圖片描述

使?Lua腳本完成上述解鎖功能（事物的替換方案）

if redis.call('get',KEYS[1]) == ARGV[1] then
return redis.call('del',KEYS[1])
else
return 0
end;

上述代碼可以編寫成?個.lua后綴的?件,由 redis-cli 或者 redis-plus-plus 或者jedis 等客戶端加載,并發送給Redis服務器,由Redis服務器來執?這段邏輯.

?個lua腳本會被Redis服務器以原?的?式來執?

redis-plus-plus 和 jedis 如何調?lua,咱們此處不做過多介紹.具體api的寫法?家可以??研究.

🦋引?watchdog(看?狗)

上述?案仍然存在?個重要問題.當我們設置了key過期時間之后(?如10s),仍然存在?定的可能性,當任務還沒執?完,key就先過期了.這就導致鎖提前失效.

把這個過期時間設置的?夠?,?如30s,是否能解決這個問題呢?很明顯,設置多?時間合適,是??境的.即使設置再?,也不能完全保證就沒有提前失效的情況.

?且如果設置的太?了,萬?對應的服務器掛了,此時其他服務器也不能及時的獲取到鎖.

因此相?于設置?個固定的?時間,不如動態的調整時間更合適.

所謂watchdog,本質上是加鎖的服務器上的?個單獨的線程,通過這個線程來對鎖過期時間進?"續
約".

注意,這個線程是業務服務器上的,不是Redis服務器的

在這里插入圖片描述

這樣就不擔?鎖提前失效的問題了.?且另???,如果該服務器掛了,看?狗線程也就隨之掛了,此時??續約,這個key?然就可以迅速過期,讓其他服務器能夠獲取到鎖了.

🦋 引?Redlock算法

實踐中的Redis?般是以集群的?式部署的(?少是主從的形式,?不是單機).那么就可能出現以下?較極端的?冤種情況:

🍰 服務器1向master節點進?加鎖操作.這個寫?key的過程剛剛完成,master掛了;slave節點升級成了新的master節點.但是由于剛才寫?的這個key尚未來得及同步給slave呢,此時就相當于服務器1的加鎖操作形同虛設了,服務器2仍然可以進?加鎖(即給新的master寫?key.因為新的master不包含剛才的key).

為了解決這個問題,Redis的作者提出了Redlock算法.

我們引??組Redis節點.其中每?組Redis節點都包含?個主節點和若?從節點.并且組和組之間存儲的數據都是?致的,相互之間是"備份"關系(?并?是數據集合的?部分,這點有別于Rediscluster).

加鎖的時候,按照?定的順序,寫多個master節點.在寫鎖的時候需要設定操作的"超時時間".?如 50ms.即如果setnx操作超過了50ms還沒有成功,就視為加鎖失敗.
在這里插入圖片描述