https://github.com/Ccww-lx/JavaCommunity

在實(shí)際的工作項(xiàng)目中， 緩存成為高并發(fā)、高性能架構(gòu)的關(guān)鍵組件 ，那么Redis為什么可以作為緩存使用呢？首先可以作為緩存的兩個(gè)主要特征：

• 在分層系統(tǒng)中處于內(nèi)存/CPU具有訪(fǎng)問(wèn)性能良好，

• 緩存數(shù)據(jù)飽和，有良好的數(shù)據(jù)淘汰機(jī)制

由于Redis 天然就具有這兩個(gè)特征，Redis基于內(nèi)存操作的，且其具有完善的數(shù)據(jù)淘汰機(jī)制，十分適合作為緩存組件。

其中，基于內(nèi)存操作，容量可以為32-96GB，且操作時(shí)間平均為100ns，操作效率高。而且數(shù)據(jù)淘汰機(jī)制眾多，在Redis 4.0 后就有8種了促使Redis作為緩存可以適用很多場(chǎng)景。

那Redis緩存為什么需要數(shù)據(jù)淘汰機(jī)制呢？有哪8種數(shù)據(jù)淘汰機(jī)制呢？

數(shù)據(jù)淘汰機(jī)制

Redis緩存基于內(nèi)存實(shí)現(xiàn)的，則其緩存其容量是有限的，當(dāng)出現(xiàn)緩存被寫(xiě)滿(mǎn)的情況，那么這時(shí)Redis該如何處理呢？

Redis對(duì)于緩存被寫(xiě)滿(mǎn)的情況，Redis就需要緩存數(shù)據(jù)淘汰機(jī)制，通過(guò)一定淘汰規(guī)則將一些數(shù)據(jù)刷選出來(lái)刪除，讓緩存服務(wù)可再使用。那么Redis使用哪些淘汰策略進(jìn)行刷選刪除數(shù)據(jù)？

在Redis 4.0 之后，Redis 緩存淘汰策略6+2種，包括分成三大類(lèi)：

• 不淘汰數(shù)據(jù)

  • noeviction ，不進(jìn)行數(shù)據(jù)淘汰，當(dāng)緩存被寫(xiě)滿(mǎn)后，Redis不提供服務(wù)直接返回錯(cuò)誤。

• 在設(shè)置過(guò)期時(shí)間的鍵值對(duì)中，

  • volatile-random ，在設(shè)置過(guò)期時(shí)間的鍵值對(duì)中隨機(jī)刪除

  • volatile-ttl ，在設(shè)置過(guò)期時(shí)間的鍵值對(duì)，基于過(guò)期時(shí)間的先后進(jìn)行刪除，越早過(guò)期的越先被刪除。

  • volatile-lru ， 基于LRU(Least Recently Used) 算法篩選設(shè)置了過(guò)期時(shí)間的鍵值對(duì)， 最近最少使用的原則來(lái)篩選數(shù)據(jù)

  • volatile-lfu ，使用 LFU( Least Frequently Used ) 算法選擇設(shè)置了過(guò)期時(shí)間的鍵值對(duì), 使用頻率最少的鍵值對(duì),來(lái)篩選數(shù)據(jù)。

• 在所有的鍵值對(duì)中，

  • allkeys-random， 從所有鍵值對(duì)中隨機(jī)選擇并刪除數(shù)據(jù)

  • allkeys-lru， 使用 LRU 算法在所有數(shù)據(jù)中進(jìn)行篩選

  • allkeys-lfu， 使用 LFU 算法在所有數(shù)據(jù)中進(jìn)行篩選

Note: LRU( 最近最少使用，Least Recently Used)算法， LRU維護(hù)一個(gè)雙向鏈表 ，鏈表的頭和尾分別表示 MRU 端和 LRU 端，分別代表最近最常使用的數(shù)據(jù)和最近最不常用的數(shù)據(jù)。

LRU 算法在實(shí)際實(shí)現(xiàn)時(shí)，需要用鏈表管理所有的緩存數(shù)據(jù)，這會(huì)帶來(lái)額外的空間開(kāi)銷(xiāo)。而且，當(dāng)有數(shù)據(jù)被訪(fǎng)問(wèn)時(shí)，需要在鏈表上把該數(shù)據(jù)移動(dòng)到 MRU 端，如果有大量數(shù)據(jù)被訪(fǎng)問(wèn)，就會(huì)帶來(lái)很多鏈表移動(dòng)操作，會(huì)很耗時(shí)，進(jìn)而會(huì)降低 Redis 緩存性能。

其中，LRU和LFU 基于Redis的對(duì)象結(jié)構(gòu) redisObject 的 lru 和 refcount 屬性實(shí)現(xiàn)的:

typedef struct redisObject { 
unsigned type:4; 
unsigned encoding:4; 
// 對(duì)象最后一次被訪(fǎng)問(wèn)的時(shí)間 
unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or 
                          * LFU data (least significant 8 bits frequency 
// 引用計(jì)數(shù)               * and most significant 16 bits access time). */ 
int refcount; 
void *ptr; 
} robj; 

Redis 的 LRU 會(huì)使用 redisObject 的 lru 記錄最近一次被訪(fǎng)問(wèn)的時(shí)間，隨機(jī)選取參數(shù) maxmemory-samples 配置的數(shù)量作為候選集合，在其中選擇 lru 屬性值最小的數(shù)據(jù)淘汰出去。

在實(shí)際項(xiàng)目中，那么該如何選擇數(shù)據(jù)淘汰機(jī)制呢？

• 優(yōu)先選擇 allkeys-lru 算法，將最近最常訪(fǎng)問(wèn)的數(shù)據(jù)留在緩存中，提升應(yīng)用的訪(fǎng)問(wèn)性能。

• 有頂置數(shù)據(jù)使用 volatile-lru 算法 ,頂置數(shù)據(jù)不設(shè)置緩存過(guò)期時(shí)間，其他數(shù)據(jù)設(shè)置過(guò)期時(shí)間，基于LRU 規(guī)則進(jìn)行篩選 。

在理解了Redis緩存淘汰機(jī)制后，來(lái)看看Redis作為緩存其有多少種模式呢？

Redis緩存模式

Redis緩存模式基于是否接收寫(xiě)請(qǐng)求，可以分成只讀緩存和讀寫(xiě)緩存：

只讀緩存：只處理讀操作，所有的更新操作都在數(shù)據(jù)庫(kù)中，這樣數(shù)據(jù)不會(huì)有丟失的風(fēng)險(xiǎn)。

• Cache Aside模式

  

讀寫(xiě)緩存，讀寫(xiě)操作都在緩存中執(zhí)行，出現(xiàn)宕機(jī)故障，會(huì)導(dǎo)致數(shù)據(jù)丟失。緩存寫(xiě)回?cái)?shù)據(jù)到數(shù)據(jù)庫(kù)有分成兩種同步和異步：

Cache Aside模式

查詢(xún)數(shù)據(jù)先從緩存讀取數(shù)據(jù)，如果緩存中不存在，則再到數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)，獲取到數(shù)據(jù)之后更新到緩存Cache中， 但更新數(shù)據(jù)操作，會(huì)先去更新數(shù)據(jù)庫(kù)種的數(shù)據(jù)，然后將緩存種的數(shù)據(jù)失效。

而且Cache Aside模式會(huì)存在并發(fā)風(fēng)險(xiǎn)：執(zhí)行讀操作未命中緩存，然后查詢(xún)數(shù)據(jù)庫(kù)中取數(shù)據(jù)，數(shù)據(jù)已經(jīng)查詢(xún)到還沒(méi)放入緩存，同時(shí)一個(gè)更新寫(xiě)操作讓緩存失效，然后讀操作再把查詢(xún)到數(shù)據(jù)加載緩存，導(dǎo)致緩存的臟數(shù)據(jù)。

Read/Write-Throug模式

查詢(xún)數(shù)據(jù)和更新數(shù)據(jù)都直接訪(fǎng)問(wèn)緩存服務(wù)， 緩存服務(wù)同步方式地將數(shù)據(jù)更新到數(shù)據(jù)庫(kù) 。出現(xiàn)臟數(shù)據(jù)的概率較低，但是就強(qiáng)依賴(lài)緩存，對(duì)緩存服務(wù)的穩(wěn)定性有較大要求，但同步更新會(huì)導(dǎo)致其性能不好。

Write Behind模式

查詢(xún)數(shù)據(jù)和更新數(shù)據(jù)都直接訪(fǎng)問(wèn)緩存服務(wù)， 但緩存服務(wù)使用異步方式地將數(shù)據(jù)更新到數(shù)據(jù)庫(kù)（通過(guò)異步任務(wù)） 速度快，效率會(huì)非常高，但是數(shù)據(jù)的一致性比較差，還可能會(huì)有數(shù)據(jù)的丟失情況，實(shí)現(xiàn)邏輯也較為復(fù)雜。

在實(shí)際項(xiàng)目開(kāi)發(fā)中根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景需求來(lái)進(jìn)行選擇緩存模式。那了解上述后，我們的應(yīng)用中為什么需要使用到 redis 緩存呢？

在應(yīng)用使用 Redis 緩存可以提高系統(tǒng)性能和并發(fā)，主要體現(xiàn)在

• 高性能：基于內(nèi)存查詢(xún)，KV結(jié)構(gòu)，簡(jiǎn)單邏輯運(yùn)算

• 高并發(fā)： Mysql 每秒只能支持2000左右的請(qǐng)求， Redis 輕松每秒1W以上。讓80%以上查詢(xún)走緩存，20%以下查詢(xún)走數(shù)據(jù)庫(kù)，能讓系統(tǒng)吞吐量有很大的提高

雖然使用Redis緩存可以大大提升系統(tǒng)的性能，但是使用了緩存，會(huì)出現(xiàn)一些問(wèn)題，比如，緩存與數(shù)據(jù)庫(kù)雙向不一致、緩存雪崩等，對(duì)于出現(xiàn)的這些問(wèn)題該怎么解決呢？

使用緩存常見(jiàn)的問(wèn)題

使用了緩存，會(huì)出現(xiàn)一些問(wèn)題，主要體現(xiàn)在：

• 緩存與數(shù)據(jù)庫(kù)雙寫(xiě)不一致

• 緩存雪崩:  Redis 緩存無(wú)法處理大量的應(yīng)用請(qǐng)求，轉(zhuǎn)移到數(shù)據(jù)庫(kù)層導(dǎo)致數(shù)據(jù)庫(kù)層的壓力激增;

• 緩存穿透：訪(fǎng)問(wèn)數(shù)據(jù)不存在在Redis緩存中和數(shù)據(jù)庫(kù)中，導(dǎo)致大量訪(fǎng)問(wèn)穿透緩存直接轉(zhuǎn)移到數(shù)據(jù)庫(kù)導(dǎo)致數(shù)據(jù)庫(kù)層的壓力激增;

• 緩存擊穿：緩存無(wú)法處理高頻熱點(diǎn)數(shù)據(jù)，導(dǎo)致直接高頻訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)導(dǎo)致數(shù)據(jù)庫(kù)層的壓力激增;

緩存與數(shù)據(jù)庫(kù)數(shù)據(jù)不一致

只讀緩存( Cache Aside 模式)

對(duì)于 只讀緩存( Cache Aside 模式) ，讀 操作都發(fā)生在緩存中 ，數(shù)據(jù)不一致只會(huì)發(fā)生在 刪改操作 上（新增操作不會(huì)，因?yàn)樾略鲋粫?huì)在數(shù)據(jù)庫(kù)處理），當(dāng)發(fā)生刪改操作時(shí)，緩存將數(shù)據(jù)中標(biāo)志為無(wú)效和更新數(shù)據(jù)庫(kù)。因此在更新數(shù)據(jù)庫(kù)和刪除緩存值的過(guò)程中，無(wú)論這兩個(gè)操作的執(zhí)行順序誰(shuí)先誰(shuí)后，只要有一個(gè)操作失敗了就會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。

總結(jié)出， 當(dāng)不存在并發(fā)的情況使用重試機(jī)制（消息隊(duì)列使用），當(dāng)存在高并發(fā)的情況，使用延遲雙刪除(在第一次刪除后，睡眠一定時(shí)間后，再進(jìn)行刪除) ，具體如下：

redis.delKey(X) 
db.update(X) 
Thread.sleep(N) 
redis.delKey(X) 

讀寫(xiě)緩存（Read/Write-Throug、Write Behind模式 ）

對(duì)于讀寫(xiě)緩存，寫(xiě)操作都發(fā)生在緩存中，后再更新數(shù)據(jù)庫(kù)，只要有一個(gè)操作失敗了就會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。

總結(jié)出，當(dāng)不存在并發(fā)的情況使用重試機(jī)制（消息隊(duì)列使用），當(dāng)存在高并發(fā)的情況，使用分布鎖。具體如下：

緩存雪崩

緩存雪崩，由于緩存中有大量數(shù)據(jù)同時(shí)過(guò)期失效或者緩存出現(xiàn)宕機(jī)，大量的應(yīng)用請(qǐng)求無(wú)法在 Redis 緩存中進(jìn)行處理，進(jìn)而發(fā)送到數(shù)據(jù)庫(kù)層導(dǎo)致數(shù)據(jù)庫(kù)層的壓力激增，嚴(yán)重的會(huì)造成數(shù)據(jù)庫(kù)宕機(jī)。

對(duì)于緩存中有大量數(shù)據(jù)同時(shí)過(guò)期，導(dǎo)致大量請(qǐng)求無(wú)法得到處理， 解決方式：

• 數(shù)據(jù)預(yù)熱， 將發(fā)生大并發(fā)訪(fǎng)問(wèn)前手動(dòng)觸發(fā)加載緩存不同的key， 可以避免在用戶(hù)請(qǐng)求的時(shí)候，先查詢(xún)數(shù)據(jù)庫(kù)

• 設(shè)置不同的過(guò)期時(shí)間，讓緩存失效的時(shí)間點(diǎn)盡量均勻

• 雙層緩存策略， 在原始緩存上加上拷貝緩存，原始緩存失效時(shí)可以訪(fǎng)問(wèn)拷貝緩存，且原始緩存失效時(shí)間設(shè)置為短期，拷貝緩存設(shè)置為長(zhǎng)期

• 服務(wù)降級(jí) ， 發(fā)生緩存雪崩時(shí)，針對(duì)不同的數(shù)據(jù)采取不同的降級(jí)方案，比如，非核心數(shù)據(jù)直接返回預(yù)定義信息、空值或是錯(cuò)誤信息

對(duì)于緩存出現(xiàn)宕機(jī)，解決方式：

• 業(yè)務(wù)系統(tǒng)中實(shí)現(xiàn)服務(wù)熔斷或請(qǐng)求限流機(jī)制，防止大量訪(fǎng)問(wèn)導(dǎo)致數(shù)據(jù)庫(kù)出現(xiàn)宕機(jī)

緩存穿透

緩存穿透，數(shù)據(jù)在數(shù)據(jù)庫(kù)和緩存中都不存在，這樣就導(dǎo)致查詢(xún)數(shù)據(jù)，在緩存中找不到對(duì)應(yīng) key 的 value ，都要去數(shù)據(jù)庫(kù)再查詢(xún)一遍，然后返回空（相當(dāng)于進(jìn)行了兩次無(wú)用的查詢(xún)）。

當(dāng)有大量訪(fǎng)問(wèn)請(qǐng)求，且其繞過(guò)緩存直接查數(shù)據(jù)庫(kù)，導(dǎo)致數(shù)據(jù)庫(kù)層的壓力激增，嚴(yán)重的會(huì)造成數(shù)據(jù)庫(kù)宕機(jī)。

對(duì)于緩存穿透，解決方式：

• 緩存空值或缺省值，當(dāng)一個(gè)查詢(xún)返回的數(shù)據(jù)為空時(shí)， 空結(jié)果也將進(jìn)行緩存，并將它的過(guò)期時(shí)間設(shè)置比較短，下次訪(fǎng)問(wèn)直接從緩存中取值，避免了把大量請(qǐng)求發(fā)送給數(shù)據(jù)庫(kù)處理，造成數(shù)據(jù)庫(kù)出問(wèn)題。

• 布隆過(guò)濾器( BloomFilter )，將所有可能查詢(xún)數(shù)據(jù) key 哈希到一個(gè)足夠大的 bitmap 中 , 在查詢(xún)的時(shí)候先去 BloomFilter 去查詢(xún) key 是否存在，如果不存在就直接返回，存在再去查詢(xún)緩存，緩存中沒(méi)有再去查詢(xún)數(shù)據(jù)庫(kù) ，從而避免了數(shù)據(jù)庫(kù)層的壓力激增出現(xiàn)宕機(jī)。

緩存擊穿

緩存擊穿，針對(duì)某個(gè)訪(fǎng)問(wèn)非常頻繁的熱點(diǎn)數(shù)據(jù)過(guò)期失效，導(dǎo)致訪(fǎng)問(wèn)無(wú)法在緩存中進(jìn)行處理，進(jìn)而會(huì)有導(dǎo)致大量的直接請(qǐng)求數(shù)據(jù)庫(kù)，從而使得數(shù)據(jù)庫(kù)層的壓力激增，嚴(yán)重的會(huì)造成數(shù)據(jù)庫(kù)宕機(jī)。

對(duì)于緩存擊穿，解決方式：

• 不設(shè)置過(guò)期時(shí)間，對(duì)于訪(fǎng)問(wèn)特別頻繁的熱點(diǎn)數(shù)據(jù)，不設(shè)置過(guò)期時(shí)間。

總結(jié)

在大多數(shù)業(yè)務(wù)場(chǎng)景下，Redis緩存作為只讀緩存使用。針對(duì)只讀緩存來(lái)說(shuō)， 優(yōu)先使用先更新數(shù)據(jù)庫(kù)再刪除緩存的方法保證數(shù)據(jù)一致性 。

其中，緩存雪崩，緩存穿透，緩存擊穿三大問(wèn)題的原因和解決方式