在實際的工作項目中， 緩存成爲高併發、高性能架構的關鍵組件 ，那麼Redis爲什麼可以作爲緩存使用呢？首先可以作爲緩存的兩個主要特徵：
- 在分層系統中處於內存/CPU具有訪問性能良好，
- 緩存數據飽和，有良好的數據淘汰機制
由於Redis 天然就具有這兩個特徵，Redis基於內存操作的，且其具有完善的數據淘汰機制，十分適合作爲緩存組件。
其中，基於內存操作，容量可以爲32-96GB，且操作時間平均爲100ns，操作效率高。而且數據淘汰機制衆多，在Redis 4.0 後就有8種了促使Redis作爲緩存可以適用很多場景。
那Redis緩存爲什麼需要數據淘汰機制呢？有哪8種數據淘汰機制呢？
數據淘汰機制
Redis緩存基於內存實現的，則其緩存其容量是有限的，當出現緩存被寫滿的情況，那麼這時Redis該如何處理呢？
Redis對於緩存被寫滿的情況，Redis就需要緩存數據淘汰機制，通過一定淘汰規則將一些數據刷選出來刪除，讓緩存服務可再使用。那麼Redis使用哪些淘汰策略進行刷選刪除數據？
在Redis 4.0 之後，Redis 緩存淘汰策略6+2種，包括分成三大類：
-
不淘汰數據
- noeviction ，不進行數據淘汰，當緩存被寫滿後，Redis不提供服務直接返回錯誤。
-
在設置過期時間的鍵值對中，
- volatile-random ，在設置過期時間的鍵值對中隨機刪除
- volatile-ttl ，在設置過期時間的鍵值對，基於過期時間的先後進行刪除，越早過期的越先被刪除。
- volatile-lru ， 基於LRU(Least Recently Used) 算法篩選設置了過期時間的鍵值對， 最近最少使用的原則來篩選數據
- volatile-lfu ，使用 LFU( Least Frequently Used ) 算法選擇設置了過期時間的鍵值對, 使用頻率最少的鍵值對,來篩選數據。
-
在所有的鍵值對中，
- allkeys-random， 從所有鍵值對中隨機選擇並刪除數據
- allkeys-lru， 使用 LRU 算法在所有數據中進行篩選
- allkeys-lfu， 使用 LFU 算法在所有數據中進行篩選
Note: LRU( 最近最少使用，Least Recently Used)算法， LRU維護一個雙向鏈表 ，鏈表的頭和尾分別表示 MRU 端和 LRU 端，分別代表最近最常使用的數據和最近最不常用的數據。
LRU 算法在實際實現時，需要用鏈表管理所有的緩存數據，這會帶來額外的空間開銷。而且，當有數據被訪問時，需要在鏈表上把該數據移動到 MRU 端，如果有大量數據被訪問，就會帶來很多鏈表移動操作，會很耗時，進而會降低 Redis 緩存性能。
其中，LRU和LFU 基於Redis的對象結構redisObject的lru和refcount屬性實現的:
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
// 引用計數 * and most significant 16 bits access time). */
int refcount;
void *ptr;
} robj;
Redis的LRU會使用redisObject的lru記錄最近一次被訪問的時間，隨機選取參數maxmemory-samples 配置的數量作爲候選集合，在其中選擇 lru 屬性值最小的數據淘汰出去。
在實際項目中，那麼該如何選擇數據淘汰機制呢？
- 優先選擇 allkeys-lru算法，將最近最常訪問的數據留在緩存中，提升應用的訪問性能。
- 有頂置數據使用 volatile-lru算法 ,頂置數據不設置緩存過期時間，其他數據設置過期時間，基於LRU 規則進行篩選 。
在理解了Redis緩存淘汰機制後，來看看Redis作爲緩存其有多少種模式呢？
Redis緩存模式
Redis緩存模式基於是否接收寫請求，可以分成只讀緩存和讀寫緩存：
只讀緩存：只處理讀操作，所有的更新操作都在數據庫中，這樣數據不會有丟失的風險。
- Cache Aside模式
讀寫緩存，讀寫操作都在緩存中執行，出現宕機故障，會導致數據丟失。緩存回寫數據到數據庫有分成兩種同步和異步：
-
同步：訪問性能偏低，其更加側重於保證數據可靠性
- Read-Throug模式
- Write-Through模式
-
異步：有數據丟失風險，其側重於提供低延遲訪問
- Write-Behind模式
Cache Aside模式
查詢數據先從緩存讀取數據，如果緩存中不存在，則再到數據庫中讀取數據，獲取到數據之後更新到緩存Cache中，但更新數據操作，會先去更新數據庫種的數據，然後將緩存種的數據失效。
而且Cache Aside模式會存在併發風險：執行讀操作未命中緩存，然後查詢數據庫中取數據，數據已經查詢到還沒放入緩存，同時一個更新寫操作讓緩存失效，然後讀操作再把查詢到數據加載緩存，導致緩存的髒數據。
Read/Write-Throug模式
查詢數據和更新數據都直接訪問緩存服務，緩存服務同步方式地將數據更新到數據庫。出現髒數據的概率較低，但是就強依賴緩存，對緩存服務的穩定性有較大要求，但同步更新會導致其性能不好。
Write Behind模式
查詢數據和更新數據都直接訪問緩存服務，但緩存服務使用異步方式地將數據更新到數據庫（通過異步任務） 速度快，效率會非常高，但是數據的一致性比較差，還可能會有數據的丟失情況，實現邏輯也較爲複雜。
在實際項目開發中根據實際的業務場景需求來進行選擇緩存模式。那瞭解上述後，我們的應用中爲什麼需要使用到redis緩存呢？
在應用使用Redis緩存可以提高系統性能和併發，主要體現在
- 高性能：基於內存查詢，KV結構，簡單邏輯運算
- 高併發： Mysql 每秒只能支持2000左右的請求，Redis輕鬆每秒1W以上。讓80%以上查詢走緩存，20%以下查詢走數據庫，能讓系統吞吐量有很大的提高
雖然使用Redis緩存可以大大提升系統的性能，但是使用了緩存，會出現一些問題，比如，緩存與數據庫雙向不一致、緩存雪崩等，對於出現的這些問題該怎麼解決呢？
使用緩存常見的問題
使用了緩存，會出現一些問題，主要體現在：
- 緩存與數據庫雙寫不一致
- 緩存雪崩: Redis 緩存無法處理大量的應用請求，轉移到數據庫層導致數據庫層的壓力激增;
- 緩存穿透：訪問數據不存在在Redis緩存中和數據庫中，導致大量訪問穿透緩存直接轉移到數據庫導致數據庫層的壓力激增;
- 緩存擊穿：緩存無法處理高頻熱點數據，導致直接高頻訪問數據庫導致數據庫層的壓力激增;
緩存與數據庫數據不一致
只讀緩存(Cache Aside模式)
對於只讀緩存(Cache Aside模式)， 讀操作都發生在緩存中，數據不一致只會發生在刪改操作上（新增操作不會，因爲新增只會在數據庫處理），當發生刪改操作時，緩存將數據中標誌爲無效和更新數據庫 。因此在更新數據庫和刪除緩存值的過程中，無論這兩個操作的執行順序誰先誰後，只要有一個操作失敗了就會出現數據不一致的情況。
總結出，當不存在併發的情況使用重試機制（消息隊列使用），當存在高併發的情況，使用延遲雙刪除(在第一次刪除後，睡眠一定時間後，再進行刪除)，具體如下：
| 操作順序 | 是否高併發 | 潛在問題 | 現象 | 應對方案 |
|---|---|---|---|---|
| 先刪除緩存，再更新數據庫 | 否 | 緩存刪除成功，數據庫更新失敗 | 讀到數據庫的舊值 | 重試機制（數據庫更新） |
| 先更新數據庫，再刪除緩存 | 否 | 數據庫更新成功，緩存刪除失敗 | 讀到緩存的舊值 | 重試機制（緩存刪除） |
| 先刪除緩存，再更新數據庫 | 是 | 緩存刪除後，尚未更新數據庫，有併發讀請求 | 併發讀請求讀到數據庫舊值，並更新到緩存，導致之後的讀請求讀到舊值 | 延遲雙刪（） |
| 先更新數據庫，再刪除緩存 | 是 | 數據庫更新成功，尚未刪除緩存 | 讀到緩存的舊值 | 不一致的情況短暫存在，對業務影響較小 |
NOTE:
延遲雙刪除僞代碼：
redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)
讀寫緩存（Read/Write-Throug、Write Behind模式 ）
對於讀寫緩存，寫操作都發生在緩存中，後再更新數據庫，只要有一個操作失敗了就會出現數據不一致的情況。
總結出，當不存在併發的情況使用重試機制（消息隊列使用），當存在高併發的情況，使用分佈鎖。具體如下：
| 操作順序 | 是否高 併發 | 潛在問題 | 現象 | 應對方案 |
|---|---|---|---|---|
| 先更新緩存，再更新數據庫 | 否 | 緩存更新成功，數據庫更新失敗 | 會從緩存中讀到最新值，短期影響不大 | 重試機制（數據庫更新） |
| 先更新數據庫，再更新緩存 | 否 | 數據庫更新成功，緩存更新失敗 | 會從緩存讀到舊值 | 重試機制（緩存刪除） |
| 先更新數據庫，再更新緩存 | 寫+讀併發 | 線程A先更新數據庫，之後線程B讀取數據，之後線程A更新緩存 | B會命中緩存，讀取到舊值 | A更新緩存前，對業務有短暫影響 |
| 先更新緩存，再更新數據庫 | 寫+讀併發 | 線程A先更新緩存成功，之後線程B讀取數據，此時線程B命中緩存，讀取到最新值後返回，之後線程A更新數據庫成功 | B會命中緩存，讀取到最新值 | 業務沒影響 |
| 先更新數據庫，再更新緩存 | 寫+寫併發 | 線程A和線程B同時更新同一條數據，更新數據庫的順序是先A後B，但更新緩存時順序是先B後A，這會導致數據庫和緩存的不一致 | 數據庫和緩存的不一致 | 寫操作加分佈式鎖 |
| 先更新緩存，再更新數據庫 | 寫+寫併發 | 線程A和線程B同時更新同一條數據，更新緩存的順序是先A後B，但是更新數據庫的順序是先B後A，這也會導致數據庫和緩存的不一致 | 數據庫和緩存的不一致 | 寫操作加分佈式鎖 |
緩存雪崩
緩存雪崩，由於緩存中有大量數據同時過期失效或者緩存出現宕機，大量的應用請求無法在 Redis 緩存中進行處理，進而發送到數據庫層導致數據庫層的壓力激增，嚴重的會造成數據庫宕機。
對於緩存中有大量數據同時過期，導致大量請求無法得到處理， 解決方式：
- 數據預熱，將發生大併發訪問前手動觸發加載緩存不同的key， 可以避免在用戶請求的時候，先查詢數據庫
- 設置不同的過期時間，讓緩存失效的時間點儘量均勻
- 雙層緩存策略， 在原始緩存上加上拷貝緩存，原始緩存失效時可以訪問拷貝緩存，且原始緩存失效時間設置爲短期，拷貝緩存設置爲長期
- 服務降級 ， 發生緩存雪崩時，針對不同的數據採取不同的降級方案 ，比如，非核心數據直接返回預定義信息、空值或是錯誤信息
對於緩存出現宕機，解決方式：
- 業務系統中實現服務熔斷或請求限流機制，防止大量訪問導致數據庫出現宕機
緩存穿透
緩存穿透，數據在數據庫和緩存中都不存在，這樣就導致查詢數據，在緩存中找不到對應key的value，都要去數據庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。
當有大量訪問請求，且其繞過緩存直接查數據庫，導致數據庫層的壓力激增，嚴重的會造成數據庫宕機。
對於緩存穿透，解決方式：
- 緩存空值或缺省值，當一個查詢返回的數據爲空時， 空結果也將進行緩存，並將它的過期時間設置比較短，下次訪問直接從緩存中取值，避免了把大量請求發送給數據庫處理，造成數據庫出問題。
- 布隆過濾器( BloomFilter )，將所有可能查詢數據key哈希到一個足夠大的bitmap中 , 在查詢的時候先去BloomFilter去查詢key是否存在，如果不存在就直接返回，存在再去查詢緩存，緩存中沒有再去查詢數據庫 ，從而避免了數據庫層的壓力激增出現宕機。
緩存擊穿
緩存擊穿，針對某個訪問非常頻繁的熱點數據過期失效，導致訪問無法在緩存中進行處理，進而會有導致大量的直接請求數據庫，從而使得數據庫層的壓力激增，嚴重的會造成數據庫宕機。
對於緩存擊穿，解決方式：
- 不設置過期時間，對於訪問特別頻繁的熱點數據，不設置過期時間。
總結
在大多數業務場景下，Redis緩存作爲只讀緩存使用。針對只讀緩存來說， 優先使用先更新數據庫再刪除緩存的方法保證數據一致性 。
其中，緩存雪崩，緩存穿透，緩存擊穿三大問題的原因和解決方式
