《分享幾道高頻 Redis 高頻面試題，面試不用愁》

一、說說 Redis 都有哪些應用場景？

• 緩存：這應該是 Redis 最主要的功能了，也是大型網站必備機制，合理地使用緩存不只能夠加 快數據的訪問速度，並且可以有效地下降後端數據源的壓力。
• 共享Session：對於一些依賴 session 功能的服務來講，若是須要從單機變成集羣的話，能夠選擇 redis 來統一管理 session。
• 消息隊列系統：消息隊列系統能夠說是一個大型網站的必備基礎組件，由於其具備業務 解耦、非實時業務削峯等特性。Redis提供了發佈訂閱功能和阻塞隊列的功 能，雖然和專業的消息隊列比還不夠足夠強大，可是對於通常的消息隊列功 能基本能夠知足。好比在分佈式爬蟲系統中，使用 redis 來統一管理 url隊列。
• 分佈式鎖：在分佈式服務中。能夠利用Redis的setnx功能來編寫分佈式的鎖，雖然這個可能不是太經常使用。
• 加q羣：478052716 免費領取（Java架構資料，視頻資料，BATJ面試資料）

固然還有諸如排行榜、點贊功能均可以使用 Redis 來實現，可是 Redis 也不是什麼均可以作，好比數據量特別大時，不適合 Redis，咱們知道 Redis 是基於內存的，雖然內存很便宜，可是若是你天天的數據量特別大，好比幾億條的用戶行爲日誌數據，用 Redis 來存儲的話，成本至關的高。

二、單線程的 Redis 爲何這麼快？

Redis 有多快？官方給出的答案是讀寫速度 10萬/秒，若是說這是在單線程狀況下跑出來的成績，你會不會驚訝？爲何單線程的 Redis 速度這麼快？緣由有如下幾點：

• 純內存操做：Redis 是徹底基於內存的，因此讀寫效率很是的高，固然 Redis 存在持久化操做，在持久化操做是都是 fork 子進程和利用 Linux 系統的頁緩存技術來完成，並不會影響 Redis 的性能。
• 單線程操做：單線程並非壞事，單線程能夠避免了頻繁的上下文切換，頻繁的上下文切換也會影響性能的。
• 合理高效的數據結構
• 採用了非阻塞 I/O 多路複用機制：多路I/O複用模型是利用 select、poll、epoll 能夠同時監察多個流的 I/O 事件的能力，在空閒的時候，會把當前線程阻塞掉，當有一個或多個流有 I/O 事件時，就從阻塞態中喚醒，因而程序就會輪詢一遍全部的流（epoll 是隻輪詢那些真正發出了事件的流），而且只依次順序的處理就緒的流，這種作法就避免了大量的無用操做。
• 加q羣：478052716 免費領取（Java架構資料，視頻資料，BATJ面試資料）

三、說說 Redis 的數據結構及使用場景

Redis 提供了 5種數據結構，每一種數據結構有各類的使用場景。

一、String 字符串

字符串類型是 Redis 最基礎的數據結構，首先鍵都是字符串類型，並且 其餘幾種數據結構都是在字符串類型基礎上構建的，咱們常使用的 set key value 命令就是字符串。經常使用在緩存、計數、共享Session、限速等。

二、Hash 哈希

在Redis中，哈希類型是指鍵值自己又是一個鍵值對 結構，形如value={{field1，value1}，...{fieldN，valueN}}，添加命令：hset key field value。哈希能夠用來存放用戶信息，好比實現購物車

三、List 列表

列表（list）類型是用來存儲多個有序的字符串。能夠作簡單的消息隊列的功能。另外，能夠利用 lrange 命令，作基於 Redis的分頁功能，性能極佳，用戶體驗好。

四、Set 集合

集合（set）類型也是用來保存多個的字符串元素，但和列表類型不一 樣的是，集合中不容許有重複元素，而且集合中的元素是無序的，不能經過 索引下標獲取元素。利用 Set 的交集、並集、差集等操做，能夠計算共同喜愛，所有的喜愛，本身獨有的喜愛等功能。

五、Sorted Set 有序集合

Sorted Set 多了一個權重參數 Score，集合中的元素可以按 Score 進行排列。能夠作排行榜應用，取 TOP N 操做

四、說一說 Redis 的數據過時淘汰策略

先給你們一個結論，Redis 中數據過時策略採用按期刪除+惰性刪除策略。

一、按期刪除、惰性刪除策略是什麼？

• 按期刪除策略：Redis 啓用一個定時器定時監視全部的 key，判斷key是否過時，過時的話就刪除。這種策略能夠保證過時的 key 最終都會被刪除，可是也存在嚴重的缺點：每次都遍歷內存中全部的數據，很是消耗 CPU 資源，而且當 key 已過時，可是定時器還處於未喚起狀態，這段時間內 key 仍然能夠用。
• 惰性刪除策略：在獲取 key 時，先判斷 key 是否過時，若是過時則刪除。這種方式存在一個缺點：若是這個 key 一直未被使用，那麼它一直在內存中，其實它已通過期了，會浪費大量的空間。

二、按期刪除+惰性刪除策略是如何工做的？

這兩種策略自然的互補，結合起來以後，定時刪除策略就發生了一些改變，不在是每次掃描所有的 key 了，而是隨機抽取一部分 key 進行檢查，這樣就下降了對 CPU 資源的損耗，惰性刪除策略互補了爲檢查到的key，基本上知足了全部要求。可是有時候就是那麼的巧，既沒有被定時器抽取到，又沒有被使用，這些數據又如何從內存中消失？不要緊，還有內存淘汰機制，當內存不夠用時，內存淘汰機制就會上場。Redis 內存淘汰機制有如下幾種策略：

• noeviction：當內存不足以容納新寫入數據時，新寫入操做會報錯。（Redis 默認策略）
• allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的 Key。（推薦使用）
• allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個 Key。
• volatile-lru：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間中，移除最近最少使用的 Key。這種狀況通常是把 Redis 既當緩存，又作持久化存儲的時候才用。
• volatile-random：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間中，隨機移除某個 Key。
• volatile-ttl：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間中，有更早過時時間的 Key 優先移除。

修改內存淘汰機制只須要在 redis.conf 配置文件中配置 maxmemory-policy 參數便可。

五、如何解決 Redis 緩存穿透和緩存雪崩問題

緩存雪崩：因爲緩存層承載着大量請求，有效地 保護了存儲層，可是若是緩存層因爲某些緣由不能提供服務，好比 Redis 節點掛掉了，熱點 key 所有失效了，在這些狀況下，全部的請求都會直接請求到數據庫，可能會形成數據庫宕機的狀況。

預防和解決緩存雪崩問題，能夠從如下三個方面進行着手：

• 一、使用 Redis 高可用架構：使用 Redis 集羣來保證 Redis 服務不會掛掉
• 二、緩存時間不一致：給緩存的失效時間，加上一個隨機值，避免集體失效
• 三、限流降級策略：有必定的備案，好比個性推薦服務不可用了，換成熱點數據推薦服務

緩存穿透：緩存穿透是指查詢一個根本不存在的數據，這樣的數據確定不在緩存中，這會致使請求所有落到數據庫上，有可能出現數據庫宕機的狀況。

預防和解決緩存穿透問題，能夠考慮如下兩種方法：

• 一、緩存空對象：將空值緩存起來，可是這樣就有一個問題，大量無效的空值將佔用空間，很是浪費。
• 二、布隆過濾器攔截：將全部可能的查詢key 先映射到布隆過濾器中，查詢時先判斷key是否存在布隆過濾器中，存在才繼續向下執行，若是不存在，則直接返回。布隆過濾器有必定的誤判，因此須要你的業務容許必定的容錯性。