建站
咨詢
售后
建站咨詢
新聞中心
https://github.com/Ccww-lx/JavaCommunity
目前成都創(chuàng)新互聯(lián)公司已為上千余家的企業(yè)提供了網(wǎng)站建設、域名、網(wǎng)頁空間、綿陽服務器托管、企業(yè)網(wǎng)站設計、疏勒網(wǎng)站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
在實際的工作項目中， 緩存成為高并發(fā)、高性能架構(gòu)的關鍵組件 ，那么Redis為什么可以作為緩存使用呢？首先可以作為緩存的兩個主要特征：
-
在分層系統(tǒng)中處于內(nèi)存/CPU具有訪問性能良好，
-
緩存數(shù)據(jù)飽和，有良好的數(shù)據(jù)淘汰機制
由于Redis 天然就具有這兩個特征，Redis基于內(nèi)存操作的，且其具有完善的數(shù)據(jù)淘汰機制，十分適合作為緩存組件。
其中，基于內(nèi)存操作，容量可以為32-96GB，且操作時間平均為100ns，操作效率高。而且數(shù)據(jù)淘汰機制眾多，在Redis 4.0 后就有8種了促使Redis作為緩存可以適用很多場景。
那Redis緩存為什么需要數(shù)據(jù)淘汰機制呢？有哪8種數(shù)據(jù)淘汰機制呢？
數(shù)據(jù)淘汰機制
Redis緩存基于內(nèi)存實現(xiàn)的，則其緩存其容量是有限的，當出現(xiàn)緩存被寫滿的情況，那么這時Redis該如何處理呢？
Redis對于緩存被寫滿的情況，Redis就需要緩存數(shù)據(jù)淘汰機制，通過一定淘汰規(guī)則將一些數(shù)據(jù)刷選出來刪除，讓緩存服務可再使用。那么Redis使用哪些淘汰策略進行刷選刪除數(shù)據(jù)？
在Redis 4.0 之后，Redis 緩存淘汰策略6+2種，包括分成三大類：
-
不淘汰數(shù)據(jù)
-
noeviction ，不進行數(shù)據(jù)淘汰，當緩存被寫滿后，Redis不提供服務直接返回錯誤。
-
-
在設置過期時間的鍵值對中，
-
volatile-random ，在設置過期時間的鍵值對中隨機刪除
-
volatile-ttl ，在設置過期時間的鍵值對，基于過期時間的先后進行刪除，越早過期的越先被刪除。
-
volatile-lru ， 基于LRU(Least Recently Used) 算法篩選設置了過期時間的鍵值對， 最近最少使用的原則來篩選數(shù)據(jù)
-
volatile-lfu ，使用 LFU( Least Frequently Used ) 算法選擇設置了過期時間的鍵值對, 使用頻率最少的鍵值對,來篩選數(shù)據(jù)。
-
-
在所有的鍵值對中，
-
allkeys-random， 從所有鍵值對中隨機選擇并刪除數(shù)據(jù)
-
allkeys-lru， 使用 LRU 算法在所有數(shù)據(jù)中進行篩選
-
allkeys-lfu， 使用 LFU 算法在所有數(shù)據(jù)中進行篩選
-
Note: LRU( 最近最少使用，Least Recently Used)算法， LRU維護一個雙向鏈表 ，鏈表的頭和尾分別表示 MRU 端和 LRU 端，分別代表最近最常使用的數(shù)據(jù)和最近最不常用的數(shù)據(jù)。
LRU 算法在實際實現(xiàn)時，需要用鏈表管理所有的緩存數(shù)據(jù)，這會帶來額外的空間開銷。而且，當有數(shù)據(jù)被訪問時，需要在鏈表上把該數(shù)據(jù)移動到 MRU 端，如果有大量數(shù)據(jù)被訪問，就會帶來很多鏈表移動操作，會很耗時，進而會降低 Redis 緩存性能。
其中，LRU和LFU 基于Redis的對象結(jié)構(gòu) redisObject 的 lru 和 refcount 屬性實現(xiàn)的:
- typedef struct redisObject {
- unsigned type:4;
- unsigned encoding:4;
- // 對象最后一次被訪問的時間
- unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
- * LFU data (least significant 8 bits frequency
- // 引用計數(shù) * and most significant 16 bits access time). */
- int refcount;
- void *ptr;
- } robj;
Redis 的 LRU 會使用 redisObject 的 lru 記錄最近一次被訪問的時間，隨機選取參數(shù) maxmemory-samples 配置的數(shù)量作為候選集合，在其中選擇 lru 屬性值最小的數(shù)據(jù)淘汰出去。
在實際項目中，那么該如何選擇數(shù)據(jù)淘汰機制呢？
-
優(yōu)先選擇
allkeys-lru算法，將最近最常訪問的數(shù)據(jù)留在緩存中，提升應用的訪問性能。 -
有頂置數(shù)據(jù)使用
volatile-lru算法 ,頂置數(shù)據(jù)不設置緩存過期時間，其他數(shù)據(jù)設置過期時間，基于LRU 規(guī)則進行篩選 。
在理解了Redis緩存淘汰機制后，來看看Redis作為緩存其有多少種模式呢？
Redis緩存模式
Redis緩存模式基于是否接收寫請求，可以分成只讀緩存和讀寫緩存：
只讀緩存：只處理讀操作，所有的更新操作都在數(shù)據(jù)庫中，這樣數(shù)據(jù)不會有丟失的風險。
-
Cache Aside模式
讀寫緩存，讀寫操作都在緩存中執(zhí)行，出現(xiàn)宕機故障，會導致數(shù)據(jù)丟失。緩存寫回數(shù)據(jù)到數(shù)據(jù)庫有分成兩種同步和異步：
-
同步：訪問性能偏低，其更加側(cè)重于保證數(shù)據(jù)可靠性
-
Read-Throug模式
-
Write-Through模式
-
異步：有數(shù)據(jù)丟失風險，其側(cè)重于提供低延遲訪問
-
Write-Behind模式
Cache Aside模式
查詢數(shù)據(jù)先從緩存讀取數(shù)據(jù)，如果緩存中不存在，則再到數(shù)據(jù)庫中讀取數(shù)據(jù)，獲取到數(shù)據(jù)之后更新到緩存Cache中， 但更新數(shù)據(jù)操作，會先去更新數(shù)據(jù)庫種的數(shù)據(jù)，然后將緩存種的數(shù)據(jù)失效。
而且Cache Aside模式會存在并發(fā)風險：執(zhí)行讀操作未命中緩存，然后查詢數(shù)據(jù)庫中取數(shù)據(jù)，數(shù)據(jù)已經(jīng)查詢到還沒放入緩存，同時一個更新寫操作讓緩存失效，然后讀操作再把查詢到數(shù)據(jù)加載緩存，導致緩存的臟數(shù)據(jù)。
Read/Write-Throug模式
查詢數(shù)據(jù)和更新數(shù)據(jù)都直接訪問緩存服務， 緩存服務同步方式地將數(shù)據(jù)更新到數(shù)據(jù)庫 。出現(xiàn)臟數(shù)據(jù)的概率較低，但是就強依賴緩存，對緩存服務的穩(wěn)定性有較大要求，但同步更新會導致其性能不好。
Write Behind模式
查詢數(shù)據(jù)和更新數(shù)據(jù)都直接訪問緩存服務， 但緩存服務使用異步方式地將數(shù)據(jù)更新到數(shù)據(jù)庫（通過異步任務） 速度快，效率會非常高，但是數(shù)據(jù)的一致性比較差，還可能會有數(shù)據(jù)的丟失情況，實現(xiàn)邏輯也較為復雜。
在實際項目開發(fā)中根據(jù)實際的業(yè)務場景需求來進行選擇緩存模式。那了解上述后，我們的應用中為什么需要使用到 redis 緩存呢？
在應用使用 Redis 緩存可以提高系統(tǒng)性能和并發(fā)，主要體現(xiàn)在
-
高性能：基于內(nèi)存查詢，KV結(jié)構(gòu)，簡單邏輯運算
-
高并發(fā)：
Mysql每秒只能支持2000左右的請求，Redis輕松每秒1W以上。讓80%以上查詢走緩存，20%以下查詢走數(shù)據(jù)庫，能讓系統(tǒng)吞吐量有很大的提高
雖然使用Redis緩存可以大大提升系統(tǒng)的性能，但是使用了緩存，會出現(xiàn)一些問題，比如，緩存與數(shù)據(jù)庫雙向不一致、緩存雪崩等，對于出現(xiàn)的這些問題該怎么解決呢？
使用緩存常見的問題
使用了緩存，會出現(xiàn)一些問題，主要體現(xiàn)在：
-
緩存與數(shù)據(jù)庫雙寫不一致
-
緩存雪崩: Redis 緩存無法處理大量的應用請求，轉(zhuǎn)移到數(shù)據(jù)庫層導致數(shù)據(jù)庫層的壓力激增;
-
緩存穿透：訪問數(shù)據(jù)不存在在Redis緩存中和數(shù)據(jù)庫中，導致大量訪問穿透緩存直接轉(zhuǎn)移到數(shù)據(jù)庫導致數(shù)據(jù)庫層的壓力激增;
-
緩存擊穿：緩存無法處理高頻熱點數(shù)據(jù)，導致直接高頻訪問數(shù)據(jù)庫導致數(shù)據(jù)庫層的壓力激增;
緩存與數(shù)據(jù)庫數(shù)據(jù)不一致
只讀緩存( Cache Aside 模式)
對于 只讀緩存( Cache Aside 模式) ，讀 操作都發(fā)生在緩存中 ，數(shù)據(jù)不一致只會發(fā)生在 刪改操作 上（新增操作不會，因為新增只會在數(shù)據(jù)庫處理），當發(fā)生刪改操作時，緩存將數(shù)據(jù)中標志為無效和更新數(shù)據(jù)庫。因此在更新數(shù)據(jù)庫和刪除緩存值的過程中，無論這兩個操作的執(zhí)行順序誰先誰后，只要有一個操作失敗了就會出現(xiàn)數(shù)據(jù)不一致的情況。
總結(jié)出， 當不存在并發(fā)的情況使用重試機制（消息隊列使用），當存在高并發(fā)的情況，使用延遲雙刪除(在第一次刪除后，睡眠一定時間后，再進行刪除) ，具體如下：
| 操作順序 | 是否高并發(fā) | 潛在問題 | 現(xiàn)象 | 應對方案 |
|---|---|---|---|---|
| 先刪除緩存，再更新數(shù)據(jù)庫 | 否 | 緩存刪除成功，數(shù)據(jù)庫更新失敗 | 讀到數(shù)據(jù)庫的舊值 | 重試機制（數(shù)據(jù)庫更新） |
| 先更新數(shù)據(jù)庫，再刪除緩存 | 否 | 數(shù)據(jù)庫更新成功，緩存刪除失敗 | 讀到緩存的舊值 | 重試機制（緩存刪除） |
| 先刪除緩存，再更新數(shù)據(jù)庫 | 是 | 緩存刪除后，尚未更新數(shù)據(jù)庫，有并發(fā)讀請求 | 并發(fā)讀請求讀到數(shù)據(jù)庫舊值，并更新到緩存，導致之后的讀請求讀到舊值 | 延遲雙刪（） |
| 先更新數(shù)據(jù)庫，再刪除緩存 | 是 | 數(shù)據(jù)庫更新成功，尚未刪除緩存 | 讀到緩存的舊值 | 不一致的情況短暫存在，對業(yè)務影響較小 |
NOTE:
延遲雙刪除偽代碼：
- redis.delKey(X)
- db.update(X)
- Thread.sleep(N)
- redis.delKey(X)
讀寫緩存（Read/Write-Throug、Write Behind模式 ）
對于讀寫緩存，寫操作都發(fā)生在緩存中，后再更新數(shù)據(jù)庫，只要有一個操作失敗了就會出現(xiàn)數(shù)據(jù)不一致的情況。
總結(jié)出，當不存在并發(fā)的情況使用重試機制（消息隊列使用），當存在高并發(fā)的情況，使用分布鎖。具體如下：
| 操作順序 | 是否高 并發(fā) | 潛在問題 | 現(xiàn)象 | 應對方案 |
|---|---|---|---|---|
| 先更新緩存，再更新數(shù)據(jù)庫 | 否 | 緩存更新成功，數(shù)據(jù)庫更新失敗 | 會從緩存中讀到最新值，短期影響不大 | 重試機制（數(shù)據(jù)庫更新） |
| 先更新數(shù)據(jù)庫，再更新緩存 | 否 | 數(shù)據(jù)庫更新成功，緩存更新失敗 | 會從緩存讀到舊值 | 重試機制（緩存刪除） |
| 先更新數(shù)據(jù)庫，再更新緩存 | 寫+讀并發(fā) | 線程A先更新數(shù)據(jù)庫，之后線程B讀取數(shù)據(jù)，之后線程A更新緩存 | B會命中緩存，讀取到舊值 | A更新緩存前，對業(yè)務有短暫影響 |
| 先更新緩存，再更新數(shù)據(jù)庫 | 寫+讀并發(fā) | 線程A先更新緩存成功，之后線程B讀取數(shù)據(jù)，此時線程B命中緩存，讀取到最新值后返回，之后線程A更新數(shù)據(jù)庫成功 | B會命中緩存，讀取到最新值 | 業(yè)務沒影響 |
| 先更新數(shù)據(jù)庫，再更新緩存 | 寫+寫并發(fā) | 線程A和線程B同時更新同一條數(shù)據(jù)，更新數(shù)據(jù)庫的順序是先A后B，但更新緩存時順序是先B后A，這會導致數(shù)據(jù)庫和緩存的不一致 | 數(shù)據(jù)庫和緩存的不一致 | 寫操作加分布式鎖 |
| 先更新緩存，再更新數(shù)據(jù)庫 | 寫+寫并發(fā) | 線程A和線程B同時更新同一條數(shù)據(jù)，更新緩存的順序是先A后B，但是更新數(shù)據(jù)庫的順序是先B后A，這也會導致數(shù)據(jù)庫和緩存的不一致 | 數(shù)據(jù)庫和緩存的不一致 | 寫操作加分布式鎖 |
緩存雪崩
緩存雪崩，由于緩存中有大量數(shù)據(jù)同時過期失效或者緩存出現(xiàn)宕機，大量的應用請求無法在 Redis 緩存中進行處理，進而發(fā)送到數(shù)據(jù)庫層導致數(shù)據(jù)庫層的壓力激增，嚴重的會造成數(shù)據(jù)庫宕機。
對于緩存中有大量數(shù)據(jù)同時過期，導致大量請求無法得到處理， 解決方式：
-
數(shù)據(jù)預熱， 將發(fā)生大并發(fā)訪問前手動觸發(fā)加載緩存不同的key， 可以避免在用戶請求的時候，先查詢數(shù)據(jù)庫
-
設置不同的過期時間，讓緩存失效的時間點盡量均勻
-
雙層緩存策略， 在原始緩存上加上拷貝緩存，原始緩存失效時可以訪問拷貝緩存，且原始緩存失效時間設置為短期，拷貝緩存設置為長期
-
服務降級 ， 發(fā)生緩存雪崩時，針對不同的數(shù)據(jù)采取不同的降級方案，比如，非核心數(shù)據(jù)直接返回預定義信息、空值或是錯誤信息
對于緩存出現(xiàn)宕機，解決方式：
-
業(yè)務系統(tǒng)中實現(xiàn)服務熔斷或請求限流機制，防止大量訪問導致數(shù)據(jù)庫出現(xiàn)宕機
緩存穿透
緩存穿透，數(shù)據(jù)在數(shù)據(jù)庫和緩存中都不存在，這樣就導致查詢數(shù)據(jù)，在緩存中找不到對應 key 的 value ，都要去數(shù)據(jù)庫再查詢一遍，然后返回空（相當于進行了兩次無用的查詢）。
當有大量訪問請求，且其繞過緩存直接查數(shù)據(jù)庫，導致數(shù)據(jù)庫層的壓力激增，嚴重的會造成數(shù)據(jù)庫宕機。
對于緩存穿透，解決方式：
-
緩存空值或缺省值，當一個查詢返回的數(shù)據(jù)為空時， 空結(jié)果也將進行緩存，并將它的過期時間設置比較短，下次訪問直接從緩存中取值，避免了把大量請求發(fā)送給數(shù)據(jù)庫處理，造成數(shù)據(jù)庫出問題。
-
布隆過濾器( BloomFilter )，將所有可能查詢數(shù)據(jù)
key哈希到一個足夠大的bitmap中 , 在查詢的時候先去BloomFilter去查詢key是否存在，如果不存在就直接返回，存在再去查詢緩存，緩存中沒有再去查詢數(shù)據(jù)庫 ，從而避免了數(shù)據(jù)庫層的壓力激增出現(xiàn)宕機。
緩存擊穿
緩存擊穿，針對某個訪問非常頻繁的熱點數(shù)據(jù)過期失效，導致訪問無法在緩存中進行處理，進而會有導致大量的直接請求數(shù)據(jù)庫，從而使得數(shù)據(jù)庫層的壓力激增，嚴重的會造成數(shù)據(jù)庫宕機。
對于緩存擊穿，解決方式：
-
不設置過期時間，對于訪問特別頻繁的熱點數(shù)據(jù)，不設置過期時間。
總結(jié)
在大多數(shù)業(yè)務場景下，Redis緩存作為只讀緩存使用。針對只讀緩存來說， 優(yōu)先使用先更新數(shù)據(jù)庫再刪除緩存的方法保證數(shù)據(jù)一致性 。
其中，緩存雪崩，緩存穿透，緩存擊穿三大問題的原因和解決方式
| 問題 | 原因 | 解決方式 |
|---|---|---|
| 緩存雪崩 | 大量數(shù)據(jù)同時過期失 效緩存出現(xiàn)宕機 | 數(shù)據(jù)預熱 設置不同的過期時間 雙層緩存策略 服務降級 服務熔斷 限流機制 |
| 緩存穿透 | 數(shù)據(jù)在數(shù)據(jù)庫和緩存中都不存在 | 緩存空值或缺省 值布隆過濾器( BloomFilter ) |
| 緩存擊穿 | 訪問非常頻繁的熱點數(shù)據(jù)過期失效 | 對于訪問特別頻繁的熱點數(shù)據(jù)，不設置過期時間 |
網(wǎng)站題目：Redis緩存總結(jié)：淘汰機制、緩存雪崩、數(shù)據(jù)不一致....
URL分享：http://www.5511xx.com/article/dhhdchg.html
