掌握這套精編Java高階面試題解析，Java基礎知識題庫
正文
在實際的工作專案中， 快取成為高併發、高效能架構的關鍵元件 ，那麼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模式)， 讀操作都發生在快取中，資料不一致只會發生在刪改操作上（新增操作不會，因為新增只會在資料庫處理），當發生刪改操作時，快取將資料中標誌為無效和更新資料庫 。因此在更新資料庫和刪除快取值的過程中，無論這兩個操作的執行順序誰先誰後，只要有一個操作失敗了就會出現資料不一致的情況。
如何快速更新自己的技術積累？
- 在現有的專案裡，深挖技術，比如用到netty可以把相關底層程式碼和要點都看起來。
- 如果不知道目前的努力方向，就看自己的領導或公司裡技術強的人在學什麼。
- 知道努力方向後不知道該怎麼學，就到處去找相關資料然後練習。
- 學習以後不知道有沒有學成，則可以通過面試去檢驗。
我個人覺得面試也像是一場全新的征程，失敗和勝利都是平常之事。所以，勸各位不要因為面試失敗而灰心、喪失鬥志。也不要因為面試通過而沾沾自喜，等待你的將是更美好的未來，繼續加油！
以上面試專題的答小編案整理成面試文件了，文件裡有答案詳解，以及其他一些大廠面試題目