redis常見面試題

1. 快取穿透

特點: 使用者高併發環境下,訪問資料庫中根本不存在的資料.
影響:由於使用者高併發訪問,則資料庫可能存在宕機的風險.

2. 快取擊穿

說明: 由於使用者高併發的訪問. 訪問的資料剛開始有快取,但是由於特殊原有 導致快取失效.(資料’‘單個’’)

解決方案: 串聯redis伺服器, 並是redis快取失效時間相差幾秒至幾十秒, 保證不再同一時間刪除

3. 快取雪崩

說明: 由於高併發的環境下.大量的使用者訪問伺服器. redis中有大量的資料在同一時間超時(刪除).
解決方案: 串聯redis伺服器, 並是redis快取失效時間相差幾秒至幾十秒, 保證不再同一時間刪除 (根快取擊穿解決方案類似)

4. Redis持久化問題

問題說明:

Redis中的資料都儲存在記憶體中.如果服務關閉或者宕機則記憶體資源直接丟失.導致快取失效.

持久化原理說明

Redis中有自己的持久化策略.Redis啟動時根據配置檔案中指定的持久化方式進行持久化操作. Redis中預設的持久化的方式為RDB模式.

4.1 RDB模式

特點說明:

1. RDB模式採用定期持久化的方式. 風險:可能丟失資料.
2. RDB模式記錄的是當前Redis的記憶體記錄快照. 只記錄當前狀態. 持久化效率最高的 (快照檔案預設為redis目錄下的dump.rdb)
3. RDB模式是預設的持久化方式.

持久化命令:

• 命令1: save 同步操作. 要求記錄馬上持久化. 可能對現有的操作造成阻塞
• 名來2: bgsave 非同步操作. 開啟單獨的執行緒實現持久化任務.

持久化週期:

• save 900 1 在900秒內,如果執行一次更新操作,則持久化一次.
• save 300 10 在300秒內,如果執行10次更新操作,則持久化一次.
• save 60 10000 在60秒內,如果執行10000次更新操作,則持久化一次.
• save 1 1 不可以這樣配置, 容易阻塞 效能太低.不建議使用.

使用者操作越頻繁,則持久化週期越短.

4.2 AOF模式

特點:

1. AOF模式預設是關閉狀態 如果需要則手動開啟.
2. AOF能夠記錄程式的執行過程可以實現資料的實時持久化. AOF檔案佔用的空間較大.回覆資料的速度較慢.
3. AOF模式開啟之後.RDB模式將不生效.

AOF配置:

在redis配置檔案中修改如下 (檔案內容過多, 建議搜尋關鍵字找到此配置)

# 開啟AOF模式
appendonly=yes

# aof更新日誌檔案
appendfilename "appendonly.aof"

持久化週期配置:

• appendfsync always 實時持久化.

• appendfsync everysec 每秒持久化一次 略低於rdb模式

• appendfsync no 自己不主動持久化(被動:由作業系統解決)

  手動持久化命令: save 由主程序完成(可能會阻塞)，bgsave使用新的程序完成

4.3 如何選擇持久化方式

思路: 如果允許資料少量的丟失,則首選RDB.(快),如果不允許資料丟失則使用AOF模式.

情景題案例

小張在雙11前夜誤操作將Redis伺服器執行了flushAll命令. 問專案經理應該如何解決??

A: 痛批一頓 ,讓其提交離職申請.
B: 批評教育, 讓其深刻反省,並且請主管 捏腳.
C:專案經理快速解決.並且通知全部門注意.

解決方案:
修改aof檔案中的命令.刪除flushAll之後重啟redis即可.

5. Redis記憶體優化策略

修改Redis記憶體大小

修改redis.conf配置檔案 (大約566行), 以下為註釋內容, 預設是註釋掉的

# maxmemory <bytes>

修改bytes引數即可

# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes

場景說明

Redis執行的空間是記憶體.記憶體的資源比較緊缺.所以應該維護redis記憶體資料,將改讓redis保留熱點資料.

LRU演算法

以下為百度內容, 下面所說的頁面可以理解為redis中儲存的資料

LRU是Least Recently Used的縮寫，即最近最少使用，是一種常用的頁面置換演算法，選擇最近最久未使用的頁面予以淘汰。該演算法賦予每個頁面一個訪問欄位，用來記錄一個頁面自上次被訪問以來所經歷的時間 t，當須淘汰一個頁面時，選擇現有頁面中其 t 值最大的，即最近最少使用的頁面予以淘汰。
維度: 自上一次使用的時間T
最為理想的記憶體置換演算法.

LFU演算法

以下為百度內容, 下面所說的頁面可以理解為redis中儲存的資料

LFU（least frequently used (LFU) page-replacement algorithm）。即最不經常使用頁置換演算法，要求在頁置換時置換引用計數最小的頁，因為經常使用的頁應該有一個較大的引用次數。但是有些頁在開始時使用次數很多，但以後就不再使用，這類頁將會長時間留在記憶體中，因此可以將引用計數暫存器定時右移一位，形成指數衰減的平均使用次數。
least frequently used (LFU) page-replacement algorithm
即最不經常使用頁置換演算法，要求在頁置換時置換引用計數最小的頁，因為經常使用的頁應該有一個較大的引用次數。但是有些頁在開始時使用次數很多，但以後就不再使用，這類頁將會長時間留在記憶體中，因此可以將引用計數暫存器定時右移一位，形成指數衰減的平均使用次數。
維度: 引用次數

RANDOM演算法

隨機演算法, 即記憶體不足的時候隨機刪除一些已有的資料

記憶體策略優化配置

大約在配置檔案597行, 有以下被註釋的內容

# maxmemory-policy noeviction

解除註釋, 把noeviction改為以下配置即可, 預設為noeviction策略

1. volatile-lru 在設定了超時時間的資料, 採用lru演算法進行刪除.
2. allkeys-lru 所有資料採用lru演算法
3. volatile-lfu 在設定了超時時間的資料, 採用LFU演算法進行刪除.
4. allkeys-lfu 所有資料採用LFU演算法
5. volatile-random 設定超時時間資料採用隨機演算法
6. allkeys-random 所有資料採用隨機演算法
7. volatile-ttl 設定了超時時間的資料 根據ttl規則刪除. 將剩餘時間少的提前刪除
8. noeviction 記憶體滿了 不做任何操作.報錯返回.