1.什么是緩存穿透？怎么解決？

答：緩存穿透是指用戶請求的數據在緩存（如 Redis）和數據庫（如 MySQL）中都不存在，導致每次請求都必須繞過緩存直接查詢數據庫，最終大量無效請求集中沖擊數據庫的現象。

其核心問題在于：緩存的 “攔截” 作用失效（因為緩存中沒有該數據），而數據庫也無法返回有效結果，導致所有請求都直接打到數據庫，可能引發數據庫過載、響應延遲甚至宕機。

解決方案：針對緩存穿透的核心矛盾（“緩存和數據庫都無數據，導致請求直達數據庫”），解決方案的本質是在請求到達數據庫前，提前攔截無效請求，或減少無效請求對數據庫的直接沖擊。

1. 布隆過濾器（Bloom Filter）：提前攔截 “絕對不存在” 的請求

原理：
布隆過濾器是一種空間效率極高的概率性數據結構，它可以提前將數據庫中 “已存在的所有有效 key”（如所有合法的用戶 ID、商品 ID）存入其中。當有新請求來時，先通過布隆過濾器判斷該 key 是否 “可能存在”：

• 若布隆過濾器判斷 “不存在”，則直接返回空結果（無需查詢緩存和數據庫）；
• 若判斷 “可能存在”，再繼續查詢緩存和數據庫（因為布隆過濾器有極小的誤判率，即 “不存在的 key 可能被誤判為存在”）。

優勢：

• 內存占用小（相比緩存全量 key），查詢速度快（O (1)），適合攔截大量無效請求；
• 能從源頭過濾掉 “絕對不存在” 的 key，大幅減少數據庫壓力。

注意點：

• 存在誤判率（可通過調整哈希函數數量和位數組大小降低，但無法完全消除），可能導致少量不存在的 key 被誤判為 “可能存在”，仍需查詢數據庫；
• 數據更新時需同步更新布隆過濾器（如新增數據時添加 key，刪除數據時需謹慎，因為布隆過濾器不支持高效刪除）。

2. 緩存空值（Null Value）：避免重復查詢不存在的數據

原理：
當數據庫查詢結果為 “空”（即數據不存在）時，不直接返回空結果，而是將這個 “空值” 作為緩存值存入緩存，并設置一個較短的過期時間（如 1-5 分鐘）。后續相同的請求會直接從緩存獲取 “空值”，無需再查詢數據庫。

優勢：

• 實現簡單，無需額外組件，能快速攔截重復的無效請求；
• 適合應對短期集中的無效請求（如用戶輸入錯誤參數的場景）。

注意點：

• 需設置合理的過期時間：時間過長會導致緩存中積累大量空值，浪費內存；時間過短則無法有效攔截重復請求；
• 可能被惡意攻擊利用（如偽造大量不同的不存在 key，導致緩存中存入大量空值，占用內存），需配合其他策略（如限流）使用。

3. 業務層校驗與過濾：從源頭減少無效請求

原理：
在請求到達緩存或數據庫前，通過業務邏輯對請求參數進行合法性校驗，直接過濾掉明顯無效的請求。

常見手段：

• 參數格式校驗：比如用戶 ID 必須為正整數，過濾負數、字符串等非法格式；
• 范圍校驗：比如商品 ID 的有效范圍是 1-100 萬，直接攔截超出范圍的請求；
• 白名單機制：對于核心業務（如支付、用戶信息），僅允許白名單內的 key 通過查詢。

優勢：

• 成本低，無需依賴緩存或數據庫，直接在應用層攔截，效率高；
• 能針對性過濾業務場景中的無效請求。

4. 接口限流與熔斷：控制請求總量

原理：
通過限流算法（如令牌桶、漏桶）限制單位時間內的請求數量，或通過熔斷機制（如 Sentinel、Hystrix）在數據庫壓力過大時，暫時停止對無效請求的處理，避免數據庫被壓垮。

適用場景：

• 應對突發的惡意攻擊（如短時間內大量不同的無效請求）；
• 作為兜底策略，防止其他措施失效時數據庫過載。

5. 數據預熱：減少緩存未命中的概率

原理：
在系統啟動或低峰期，提前將數據庫中 “高頻訪問的有效數據” 加載到緩存中，減少緩存未命中的情況。雖然不能直接解決緩存穿透，但能降低無效請求的相對比例。

緩存穿透

定義：指查詢一個「不存在的數據」時，由于緩存和數據庫中都沒有該數據，導致每次請求都會直接穿透緩存，全部打到數據庫上。如果這類請求量很大，可能會壓垮數據庫。

緩存擊穿

定義：指一個「熱點 key」（被高頻訪問的 key）在緩存中突然失效（比如過期），此時大量請求同時訪問該 key，緩存未命中，導致所有請求瞬間打到數據庫，造成數據庫短期內壓力驟增。

緩存雪崩

定義：指「大量緩存 key 在同一時間集中過期」，或 Redis 服務本身宕機，導致緩存層整體失效，此時所有請求全部涌向數據庫，數據庫因無法承載高并發而崩潰。

緩存穿透保護：?

// 布隆過濾器實現
public class BloomFilter {private BitSet bitSet;private int size;private HashFunction[] hashFunctions;public BloomFilter(int size, int hashCount) {this.bitSet = new BitSet(size);this.size = size;this.hashFunctions = new HashFunction[hashCount];for (int i = 0; i < hashCount; i++) {hashFunctions[i] = new HashFunction(size, i);}}public void add(String key) {for (HashFunction f : hashFunctions) {bitSet.set(f.hash(key), true);}}public boolean contains(String key) {for (HashFunction f : hashFunctions) {if (!bitSet.get(f.hash(key))) {return false;}}return true;}private static class HashFunction {private int size;private int seed;public HashFunction(int size, int seed) {this.size = size;this.seed = seed;}public int hash(String key) {int result = 1;for (char c : key.toCharArray()) {result = seed * result + c;}return (size - 1) & result;}}
}

緩存擊穿保護：

// 互斥鎖實現
public class CacheBreakdownProtection {private RedisTemplate<String, Object> redisTemplate;private Map<String, Lock> lockMap = new ConcurrentHashMap<>();public Object getWithLock(String key, Callable<Object> loader) {Object value = redisTemplate.opsForValue().get(key);if (value != null) {return value;}Lock lock = lockMap.computeIfAbsent(key, k -> new ReentrantLock());try {lock.lock();// 雙重檢查value = redisTemplate.opsForValue().get(key);if (value == null) {value = loader.call();redisTemplate.opsForValue().set(key, value, 30, TimeUnit.MINUTES);}return value;} catch (Exception e) {throw new RuntimeException(e);} finally {lock.unlock();lockMap.remove(key);}}
}

緩存雪崩保護：

// 隨機過期時間實現
public class CacheAvalancheProtection {private RedisTemplate<String, Object> redisTemplate;private ThreadLocalRandom random = ThreadLocalRandom.current();public void setWithRandomExpire(String key, Object value, long baseExpire, long delta) {long expireTime = baseExpire + random.nextLong(delta);redisTemplate.opsForValue().set(key, value, expireTime, TimeUnit.SECONDS);}// 集群模式下使用多級緩存public Object getWithMultiLevelCache(String key, Callable<Object> loader) {Object value = redisTemplate.opsForValue().get(key);if (value != null) {return value;}value = localCache.get(key);if (value != null) {return value;}try {value = loader.call();setWithRandomExpire(key, value, 1800, 600); // 30分鐘±10分鐘localCache.put(key, value);return value;} catch (Exception e) {throw new RuntimeException(e);}}
}

綜合保護：?

// 綜合防護策略
public class CacheProtectionService {private BloomFilter bloomFilter;private CacheBreakdownProtection breakdownProtection;private CacheAvalancheProtection avalancheProtection;public Object safeGet(String key, Callable<Object> loader) {// 1. 檢查布隆過濾器if (!bloomFilter.contains(key)) {return null;}// 2. 嘗試獲取緩存Object value = breakdownProtection.getWithLock(key, () -> {// 3. 數據加載邏輯Object loadedValue = loader.call();// 4. 設置隨機過期時間avalancheProtection.setWithRandomExpire(key, loadedValue, 1800, 600);// 5. 更新布隆過濾器bloomFilter.add(key);return loadedValue;});return value;}
}

2.redis做為緩存，mysql的數據如何與redis進行同步呢？（雙寫一致性）

強一致性：需要讓數據庫與redis高度保持一致，因為要求時效性比較高。采用讀寫鎖保證的強一致性。使用Redisson實現的讀寫鎖。在讀的時候添加共享鎖，可以保證讀讀不互斥、讀寫互斥。當更新數據的時候，添加排他鎖。它是讀寫、讀讀都互斥，這樣就能保證在寫數據的同時，是不會讓其他線程讀數據的，避免了臟數據。這里面需要注意的是，讀方法和寫方法上需要使用同一把鎖才行。排他鎖底層使用的也是SETNX，它保證了同時只能有一個線程操作鎖住的方法。

最終一致性：數據同步可以有一定的延時（這符合大部分業務需求）。采用的阿里的Canal組件實現數據同步：不需要更改業務代碼，只需部署一個Canal服務。Canal服務把自己偽裝成mysql的一個從節點。當mysql數據更新以后，Canal會讀取binlog數據，然后再通過Canal的客戶端獲取到數據，并更新緩存即可。

3.為什么要優先保證數據庫一致性，先更新緩存會怎么樣？

在處理數據同步時優先保證數據庫一致性，核心是因為數據庫是數據的最終持久化存儲，是數據真實性的權威來源。從實際項目場景來看，若先更新緩存，可能出現 “緩存更新成功但數據庫更新失敗” 的情況：比如xxxx項目更新中，若先修改了 Redis 中的模板緩存，卻因網絡波動等導致 MySQL 中模板數據更新失敗，會使緩存中留存錯誤數據，后續所有依賴該緩存的請求都會獲取到不一致信息，且難以快速發現和修正。

而先更新數據庫再處理緩存，即使緩存更新失敗，后續請求查詢時會因緩存未命中而從數據庫加載最新數據并重建緩存，能通過 “數據庫的正確性” 兜底，保證數據最終一致。這也與項目中對 Redis 緩存的使用邏輯一致 —— 緩存本質是提升查詢效率的輔助存儲，其一致性需依賴數據庫這一核心載體來保障。

4.你聽說過延時雙刪嗎？為什么不用它呢？

延時雙刪是一種在高并發場景下解決數據庫與緩存雙寫一致性問題的策略，其核心思想是通過兩次刪除緩存操作，配合一定的延遲時間，盡量保證在數據庫更新完成后，舊數據不會因并發請求被錯誤地重新寫入緩存。以下是其實現原理和關鍵步驟：

基本流程

1. 先刪除緩存：在更新數據庫前，先刪除 Redis 中的對應緩存，防止后續請求讀取到舊數據。
2. 更新數據庫：執行 MySQL 等數據庫的更新操作。
3. 延時后再次刪除緩存：更新數據庫完成后，等待一段時間（如 1-3 秒），再次刪除 Redis 緩存。
   • 目的：確保在數據庫更新期間，若有請求讀取到舊數據并寫入緩存，通過第二次刪除操作清除該臟數據。

為什么需要延時？

在高并發場景下，可能存在以下時序問題：

• 步驟 1 刪除緩存后，若有新請求在數據庫更新前讀取數據，會從數據庫獲取舊值并重新寫入緩存。
• 步驟 2 更新數據庫，此時緩存中仍為舊值，導致后續請求讀取到不一致的數據。

通過延時，可以等待數據庫更新完成后，再執行第二次刪除，確保舊數據被徹底清除。

延時時間如何確定？

通常需要根據業務場景的數據庫更新耗時和請求處理耗時來估算，一般設置為1-3 秒。例如：

• 若數據庫更新操作平均耗時 200ms，可設置延時為 1 秒，確保大部分更新操作已完成。
• 對于更復雜的業務，可通過壓測或監控數據動態調整延時時間。

優缺點

• 優點：實現簡單，成本低，能解決大部分并發場景下的數據不一致問題。
• 缺點：
  • 無法保證強一致性：極端情況下（如第二次刪除失敗）仍可能存在短暫不一致。
  • 性能損耗：延時操作會增加請求響應時間，影響吞吐量。
  • 延時時間難精準控制：不同業務場景的最優延時時間差異較大。

適用場景

• 適用于讀多寫少、對一致性要求不是極致嚴格的場景（如商品價格、用戶信息等）。
• 不適用于金融交易等需要強一致性的場景（通常需借助分布式事務或中間件）。

實際項目中的替代方案

在實際項目中，更傾向于使用：

1. 異步消息隊列：通過 MQ 異步更新緩存，利用重試機制保證最終一致性。
2. 訂閱數據庫 binlog：如通過 Canal 監聽 MySQL 變更，自動同步到 Redis，減少人工干預。
3. 設置合理的緩存過期時間：作為兜底策略，即使出現不一致，過期后會自動刷新。

5.redis做為緩存，數據的持久化是怎么做的？這兩種持久化方式有什么區別呢，優缺點？分別介紹一下這兩種持久化方式那個恢復得更快？

Redis 的數據持久化主要通過兩種方式實現：RDB（Redis Database）和 AOF（Append Only File）。

RDB 是通過生成數據集的時間點快照來實現持久化的。它會在指定的時間間隔內，將內存中的所有數據以二進制的形式寫入磁盤的 RDB 文件中，比如可以配置 “每 5 分鐘內有 1000 次寫操作就觸發一次快照”。

AOF 則是通過記錄所有寫操作命令來實現持久化的。服務器在執行完一個寫命令后，會將該命令追加到 AOF 文件的末尾，當 Redis 重啟時，會通過重新執行 AOF 文件中的所有命令來恢復數據。

兩者的區別主要體現在以下方面：
從數據完整性來看，RDB 可能會丟失最后一次快照后的所有數據，因為它是定時快照；而 AOF 可以通過配置 “everysec”（每秒同步一次）等策略，最多丟失 1 秒內的數據，完整性更好。
從文件大小來看，RDB 是二進制壓縮存儲，文件體積較小；AOF 記錄的是命令文本，相同數據下文件體積更大，即使有重寫機制優化，通常也比 RDB 大。
從性能影響來看，RDB 在觸發快照時會通過 fork 子進程處理，主進程不阻塞，但 fork 操作在數據量大時可能有短暫阻塞；AOF 的追加操作是異步的，對主進程影響小，但 AOF 重寫時也可能有一定性能消耗。

在恢復速度上，RDB 更快。因為 RDB 是二進制文件，加載時直接解析還原數據即可；而 AOF 需要逐條執行命令，尤其是當 AOF 文件較大時，恢復速度會明顯慢于 RDB。

6.Redis的數據過期策略有哪些？ Redis的數據淘汰策略有哪些？?

一、數據過期策略（處理已過期的 Key）

Redis 采用 「定期刪除 + 惰性刪除」組合策略 ，平衡 CPU 性能與內存利用率。

1. 惰性刪除（Lazy Deletion）

   • 觸發時機：僅當訪問（讀 / 寫）已過期的 Key 時，才會檢查并刪除。
   • 優點：避免主動掃描帶來的 CPU 開銷，適合低頻訪問的過期 Key。
   • 缺點：若過期 Key 長期未被訪問，會導致內存泄漏（如用戶會話緩存長期未失效）。

2. 定期刪除（Periodic Deletion）

   • 執行邏輯：默認每 100ms 隨機抽取 20 個設置過期時間的 Key，刪除其中已過期的；若過期比例＞25%，重復抽取，單次掃描耗時不超過 25ms。
   • 優點：主動清理部分過期 Key，防止內存膨脹。
   • 缺點：隨機抽樣可能遺漏大量過期 Key（如集中過期的熱點數據）。

二、數據淘汰策略（內存不足時的兜底方案）

當 Redis 內存達到maxmemory閾值時，根據以下 8 種策略淘汰數據（區分「是否設置過期時間」）：

三、核心區別與選擇建議