一、為什么用redis而不用memcached

redis數據結構比memcached更豐富，基本可以完全替換

redis社區比較活躍，性能也強大，也支持持久化等功能

要和業務結合，比如電商系統的熱銷商品，需要用到zset，所以使用redis

二、你用過Redis哪些數據結構？ 說下這些結構的使用場景有哪些

String

簡單的kv存儲

hash

存儲對象，一個key有多個值

list

列表型數據、消息隊列等

set

無序集合、去重，交集、并集等，比如查看共同好友，在社交關系方面、數據排重等可以使用

sroted set

有序集合，去重，做榜單

三、redis是單線程，為什么這么快?

基于內存，絕大部分請求是純粹的內存操作，CPU不是Redis的瓶頸

避免了不必要的CPU上下文切換和其他競爭條件，比如鎖操作等

底層是使用多路I/O復用模型，非阻塞IO

Redis6 后支持多線程，但是默認不開啟

四、redis有哪些持久化方式，分別說下他們的區別?

支持AOF和RDB持久化

AOF

以日志的形式記錄服務器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文本的方式記錄

支持秒級持久化、兼容性好，對于相同數量的數據集而言，AOF文件通常要大于RDB文件，所以恢復比RDB慢

RDB

在指定的時間間隔內將內存中的數據集快照寫入磁盤，可以指定時間歸檔數據，但不能做到實時持久化

文件緊湊，體積小，對于災難恢復而言，RDB是非常不錯的選擇，相比于AOF機制，如果數據集很大，RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。

五、緩存的淘汰策略

有沒看過緩存框架的源碼，緩存空間不夠怎么辦？

一般會使用淘汰策略

常見的淘汰策略有 FIFO、LRU、LFU

能分別說下FIFO、LRU、LFU這些策略不

FIFO

先進先出First In，First Out

新訪問的數據插入FIFO隊列尾部，數據在FIFO隊列中順序移動，淘汰FIFO隊列頭部的數據

最近最少使用 Least recently used

LRU

根據數據的歷史訪問記錄來進行數據淘汰，如果數據最近被訪問過，那么將來被訪問的幾率也更高

新數據插入到鏈表頭部，每當緩存數據被訪問，則將數據移到鏈表頭部，當鏈表滿的時候，將鏈表尾部的數據丟棄。

LFU

最近不經常使用 Least Frequently Used

根據數據的歷史訪問頻率來淘汰數據，如果數據過去被訪問多次，那么將來被訪問的頻率也更高

把數據加入到鏈表中，按頻次排序，一個數據被訪問過，把它的頻次+1，發生淘汰的時候，把頻次低的淘汰掉

六、緩存穿透-擊穿和雪崩

緩存擊穿 (某個熱點key緩存失效了)

緩存中沒有但數據庫中有的數據，假如是熱點數據，那key在緩存過期的一刻，同時有大量的請求，這些請求都會擊穿到DB，造成瞬時DB請求量大、壓力增大。

和緩存雪崩的區別在于這里針對某一key緩存，后者則是很多key。

預防：

設置熱點數據不過期，定時任務定時更新緩存，或者設置互斥鎖

緩存穿透（查詢不存在數據）

查詢一個不存在的數據，由于緩存是不命中的，并且出于容錯考慮，如發起為id為“-1”不存在的數據

如果從存儲層查不到數據則不寫入緩存這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。存在大量查詢不存在的數據，可能DB就掛掉了，這也是黑客利用不存在的key頻繁攻擊應用的一種方式。

預防：

接口層增加校驗，數據合理性校驗，緩存取不到的數據，在數據庫中也沒有取到，這時也可以將key-value對寫為key-null，設置短點的過期時間，防止同個key被一直攻擊

緩存雪崩 (多個熱點key都過期)

大量的key設置了相同的過期時間，導致在緩存在同一時刻全部失效，造成瞬時DB請求量大、壓力驟增，引起雪崩

預防：

存數據的過期時間設置隨機，防止同一時間大量數據過期現象發生，設置熱點數據永遠不過期，定時任務定時更新

————————————————

版權聲明：本文為CSDN博主「RobertTeacher」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。

原文鏈接：//blog.csdn.net/weixin_42397937/article/details/120462173