Redis面試題彙總（附答案），面試突擊專用

本文的面試題以下：

• Redis 持久化機制
• 緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級等問題
• 熱點數據和冷數據是什麼
• Memcache與Redis的區別都有哪些？
• 單線程的redis爲何這麼快
• redis的數據類型，以及每種數據類型的使用場景，Redis 內部結構
• redis的過時策略以及內存淘汰機制
• Redis 爲何是單線程的，優勢
• 如何解決redis的併發競爭key問題
• Redis 集羣方案應該怎麼作？都有哪些方案？
• 有沒有嘗試進行多機redis 的部署？如何保證數據一致的？
• 對於大量的請求怎麼樣處理
• Redis 常見性能問題和解決方案？
• 講解下Redis線程模型
• 爲何Redis的操做是原子性的，怎麼保證原子性的？
• Redis事務
• Redis實現分佈式鎖
• 總結
  小編整理了一套大廠Redis高頻面試題，關注公衆號：程序員白楠楠獲取！

  Redis 持久化機制

Redis是一個支持持久化的內存數據庫，經過持久化機制把內存中的數據同步到硬盤文件來保證數據持久化。當Redis重啓後經過把硬盤文件從新加載到內存，就能達到恢復數據的目的。

實現：單首創建fork()一個子進程，將當前父進程的數據庫數據複製到子進程的內存中，而後由子進程寫入到臨時文件中，持久化的過程結束了，再用這個臨時文件替換上次的快照文件，而後子進程退出，內存釋放。

RDB是Redis默認的持久化方式。按照必定的時間週期策略把內存的數據以快照的形式保存到硬盤的二進制文件。即Snapshot快照存儲，對應產生的數據文件爲dump.rdb，經過配置文件中的save參數來定義快照的週期。（ 快照能夠是其所表示的數據的一個副本，也能夠是數據的一個複製品。） AOF：Redis會將每個收到的寫命令都經過Write函數追加到文件最後，相似於MySQL的binlog。當Redis重啓是會經過從新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。

當兩種方式同時開啓時，數據恢復Redis會優先選擇AOF恢復。

緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級等問題

緩存雪崩

緩存雪崩咱們能夠簡單的理解爲：因爲原有緩存失效，新緩存未到期間

(例如：咱們設置緩存時採用了相同的過時時間，在同一時刻出現大面積的緩存過時)，全部本來應該訪問緩存的請求都去查詢數據庫了，而對數據庫CPU和內存形成巨大壓力，嚴重的會形成數據庫宕機。從而造成一系列連鎖反應，形成整個系統崩潰。

解決辦法：

大多數系統設計者考慮用加鎖（ 最多的解決方案）或者隊列的方式保證來保證不會有大量的線程對數據庫一次性進行讀寫，從而避免失效時大量的併發請求落到底層存儲系統上。還有一個簡單方案就時講緩存失效時間分散開。

緩存穿透

緩存穿透是指用戶查詢數據，在數據庫沒有，天然在緩存中也不會有。這樣就致使用戶查詢的時候，在緩存中找不到，每次都要去數據庫再查詢一遍，而後返回空（至關於進行了兩次無用的查詢）。這樣請求就繞過緩存直接查數據庫，這也是常常提的緩存命中率問題。

解決辦法：

最多見的則是採用布隆過濾器，將全部可能存在的數據哈希到一個足夠大的bitmap中，一個必定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。

另外也有一個更爲簡單粗暴的方法，若是一個查詢返回的數據爲空（無論是數據不存在，仍是系統故障），咱們仍然把這個空結果進行緩存，但它的過時時間會很短，最長不超過五分鐘。經過這個直接設置的默認值存放到緩存，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問數據庫，這種辦法最簡單粗暴。

5TB的硬盤上放滿了數據，請寫一個算法將這些數據進行排重。若是這些數據是一些32bit大小的數據該如何解決？若是是64bit的呢？

對於空間的利用到達了一種極致，那就是Bitmap和布隆過濾器(Bloom Filter)。

Bitmap：典型的就是哈希表

缺點是，Bitmap對於每一個元素只能記錄1bit信息，若是還想完成額外的功能，恐怕只能靠犧牲更多的空間、時間來完成了。

布隆過濾器（推薦）

就是引入了k(k>1)k(k>1)個相互獨立的哈希函數，保證在給定的空間、誤判率下，完成元素判重的過程。

它的優勢是空間效率和查詢時間都遠遠超過通常的算法，缺點是有必定的誤識別率和刪除困難。

Bloom-Filter算法的核心思想就是利用多個不一樣的Hash函數來解決「衝突」。

Hash存在一個衝突（碰撞）的問題，用同一個Hash獲得的兩個URL的值有可能相同。爲了減小衝突，咱們能夠多引入幾個Hash，若是經過其中的一個Hash值咱們得出某元素不在集合中，那麼該元素確定不在集合中。只有在全部的Hash函數告訴咱們該元素在集合中時，才能肯定該元素存在於集合中。這即是Bloom-Filter的基本思想。

Bloom-Filter通常用於在大數據量的集合中斷定某元素是否存在。

緩存穿透與緩存擊穿的區別

緩存擊穿：是指一個key很是熱點，在不停的扛着大併發，大併發集中對這一個點進行訪問，當這個key在失效的瞬間，持續的大併發就穿破緩存，直接請求數據。

解決方案：在訪問key以前，採用SETNX（set if not exists）來設置另外一個短時間key來鎖住當前key的訪問，訪問結束再刪除該短時間key。

給一個我公司處理的案例：背景雙機拿token，token在存一份到redis，保證系統在token過時時都只有一個線程去獲取token;線上環境有兩臺機器，故使用分佈式鎖實現。

緩存預熱

緩存預熱這個應該是一個比較常見的概念，相信不少小夥伴都應該能夠很容易的理解，緩存預熱就是系統上線後，將相關的緩存數據直接加載到緩存系統。這樣就能夠避免在用戶請求的時候，先查詢數據庫，而後再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！

解決思路：

• 直接寫個緩存刷新頁面，上線時手工操做下；
• 數據量不大，能夠在項目啓動的時候自動進行加載；
• 定時刷新緩存；

緩存更新

除了緩存服務器自帶的緩存失效策略以外（Redis默認的有6中策略可供選擇），咱們還能夠根據具體的業務需求進行自定義的緩存淘汰，常見的策略有兩種：

• 定時去清理過時的緩存；
• 當有用戶請求過來時，再判斷這個請求所用到的緩存是否過時，過時的話就去底層系統獲得新數據並更新緩存。

二者各有優劣，第一種的缺點是維護大量緩存的key是比較麻煩的，第二種的缺點就是每次用戶請求過來都要判斷緩存失效，邏輯相對比較複雜！具體用哪一種方案，你們能夠根據本身的應用場景來權衡。

緩存降級

當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然須要保證服務仍是可用的，即便是有損服務。系統能夠根據一些關鍵數據進行自動降級，也能夠配置開關實現人工降級。

降級的最終目的是保證核心服務可用，即便是有損的。並且有些服務是沒法降級的（如加入購物車、結算）。

以參考日誌級別設置預案：

• 通常：好比有些服務偶爾由於網絡抖動或者服務正在上線而超時，能夠自動降級；
• 警告：有些服務在一段時間內成功率有波動（如在95~100%之間），能夠自動降級或人工降級，併發送告警；
• 錯誤：好比可用率低於90%，或者數據庫鏈接池被打爆了，或者訪問量忽然猛增到系統能承受的最大閥值，此時能夠根據狀況自動降級或者人工降級；
• 嚴重錯誤：好比由於特殊緣由數據錯誤了，此時須要緊急人工降級。

服務降級的目的，是爲了防止Redis服務故障，致使數據庫跟着一塊兒發生雪崩問題。所以，對於不重要的緩存數據，能夠採起服務降級策略，例如一個比較常見的作法就是，Redis出現問題，不去數據庫查詢，而是直接返回默認值給用戶。

熱點數據和冷數據是什麼

熱點數據，緩存纔有價值

對於冷數據而言，大部分數據可能尚未再次訪問到就已經被擠出內存，不只佔用內存，並且價值不大。頻繁修改的數據，看狀況考慮使用緩存

對於上面兩個例子，壽星列表、導航信息都存在一個特色，就是信息修改頻率不高，讀取一般很是高的場景。

對於熱點數據，好比咱們的某IM產品，生日祝福模塊，當天的壽星列表，緩存之後可能讀取數十萬次。再舉個例子，某導航產品，咱們將導航信息，緩存之後可能讀取數百萬次。

數據更新前至少讀取兩次， 緩存纔有意義。這個是最基本的策略，若是緩存尚未起做用就失效了，那就沒有太大價值了。

那存不存在，修改頻率很高，可是又不得不考慮緩存的場景呢？有！好比，這個讀取接口對數據庫的壓力很大，可是又是熱點數據，這個時候就須要考慮經過緩存手段，減小數據庫的壓力，好比咱們的某助手產品的，點贊數，收藏數，分享數等是很是典型的熱點數據，可是又不斷變化，此時就須要將數據同步保存到Redis緩存，減小數據庫壓力。

Memcache與Redis的區別都有哪些？

1)、存儲方式 Memecache把數據所有存在內存之中，斷電後會掛掉，數據不能超過內存大小。Redis有部份存在硬盤上，redis能夠持久化其數據

2)、數據支持類型 memcached全部的值均是簡單的字符串，redis做爲其替代者，支持更爲豐富的數據類型 ，提供list，set，zset，hash等數據結構的存儲

3)、使用底層模型不一樣 它們之間底層實現方式 以及與客戶端之間通訊的應用協議不同。Redis直接本身構建了VM 機制 ，由於通常的系統調用系統函數的話，會浪費必定的時間去移動和請求。

4). value 值大小不一樣：Redis 最大能夠達到 512M；memcache 只有 1mb。

5）redis的速度比memcached快不少

6）Redis支持數據的備份，即master-slave模式的數據備份。

單線程的redis爲何這麼快

(一)純內存操做

(二)單線程操做，避免了頻繁的上下文切換

(三)採用了非阻塞I/O多路複用機制

Redis的數據類型，以及每種數據類型的使用場景

回答：一共五種

(一)String

這個其實沒啥好說的，最常規的set/get操做，value能夠是String也能夠是數字。通常作一些複雜的計數功能的緩存。

(二)hash

這裏value存放的是結構化的對象，比較方便的就是操做其中的某個字段。博主在作單點登陸的時候，就是用這種數據結構存儲用戶信息，以cookieId做爲key，設置30分鐘爲緩存過時時間，能很好的模擬出相似session的效果。

(三)list

使用List的數據結構，能夠作簡單的消息隊列的功能。另外還有一個就是，能夠利用lrange命令，作基於redis的分頁功能，性能極佳，用戶體驗好。本人還用一個場景，很合適—取行情信息。就也是個生產者和消費者的場景。LIST能夠很好的完成排隊，先進先出的原則。

(四)set

由於set堆放的是一堆不重複值的集合。因此能夠作全局去重的功能。爲何不用JVM自帶的Set進行去重？由於咱們的系統通常都是集羣部署，使用JVM自帶的Set，比較麻煩，難道爲了一個作一個全局去重，再起一個公共服務，太麻煩了。

另外，就是利用交集、並集、差集等操做，能夠計算共同喜愛，所有的喜愛，本身獨有的喜愛等功能。

(五)sorted set

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

Redis 內部結構

• dict 本質上是爲了解決算法中的查找問題（Searching）是一個用於維護key和value映射關係的數據結構，與不少語言中的Map或dictionary相似。本質上是爲了解決算法中的查找問題（Searching）
• sds sds就等同於char * 它能夠存儲任意二進制數據，不能像C語言字符串那樣以字符’\0’來標識字符串的結 束，所以它必然有個長度字段。
• skiplist （跳躍表） 跳錶是一種實現起來很簡單，單層多指針的鏈表，它查找效率很高，堪比優化過的二叉平衡樹，且比平衡樹的實現，
• quicklist
• ziplist 壓縮表 ziplist是一個編碼後的列表，是由一系列特殊編碼的連續內存塊組成的順序型數據結構，

Redis的過時策略以及內存淘汰機制

redis採用的是按期刪除+惰性刪除策略。

爲何不用定時刪除策略?

定時刪除,用一個定時器來負責監視key,過時則自動刪除。雖然內存及時釋放，可是十分消耗CPU資源。在大併發請求下，CPU要將時間應用在處理請求，而不是刪除key,所以沒有采用這一策略.

按期刪除+惰性刪除是如何工做的呢?

按期刪除，redis默認每一個100ms檢查，是否有過時的key,有過時key則刪除。須要說明的是，redis不是每一個100ms將全部的key檢查一次，而是隨機抽取進行檢查(若是每隔100ms,所有key進行檢查，redis豈不是卡死)。所以，若是隻採用按期刪除策略，會致使不少key到時間沒有刪除。

因而，惰性刪除派上用場。也就是說在你獲取某個key的時候，redis會檢查一下，這個key若是設置了過時時間那麼是否過時了？若是過時了此時就會刪除。

採用按期刪除+惰性刪除就沒其餘問題了麼?

不是的，若是按期刪除沒刪除key。而後你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的內存會愈來愈高。那麼就應該採用內存淘汰機制。

在redis.conf中有一行配置

maxmemory-policy volatile-lru1

該配置就是配內存淘汰策略的(什麼，你沒配過？好好檢討一下本身)

• volatile-lru：從已設置過時時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰
• volatile-ttl：從已設置過時時間的數據集（server.db[i].expires）中挑選將要過時的數據淘汰
• volatile-random：從已設置過時時間的數據集（server.db[i].expires）中任意選擇數據淘汰
• allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰
• allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰
• no-enviction（驅逐）：禁止驅逐數據，新寫入操做會報錯

ps：若是沒有設置 expire 的key, 不知足先決條件(prerequisites); 那麼 volatile-lru, volatile-random 和 volatile-ttl 策略的行爲, 和 noeviction(不刪除) 基本上一致。

Redis 爲何是單線程的

官方FAQ表示，由於Redis是基於內存的操做，CPU不是Redis的瓶頸，Redis的瓶頸最有多是機器內存的大小或者網絡帶寬。

既然單線程容易實現，並且CPU不會成爲瓶頸，那就瓜熟蒂落地採用單線程的方案了（畢竟採用多線程會有不少麻煩！）Redis利用隊列技術將併發訪問變爲串行訪問

1）絕大部分請求是純粹的內存操做（很是快速）

2）採用單線程,避免了沒必要要的上下文切換和競爭條件

3）非阻塞IO優勢：

• 速度快，由於數據存在內存中，相似於HashMap，HashMap的優點就是查找和操做的時間複雜度都是O(1)
• 支持豐富數據類型，支持string，list，set，sorted set，hash
• 支持事務，操做都是原子性，所謂的原子性就是對數據的更改要麼所有執行，要麼所有不執行
• 豐富的特性：可用於緩存，消息，按key設置過時時間，過時後將會自動刪除如何解決redis的併發競爭key問題

同時有多個子系統去set一個key。這個時候要注意什麼呢？

不推薦使用redis的事務機制。由於咱們的生產環境，基本都是redis集羣環境，作了數據分片操做。你一個事務中有涉及到多個key操做的時候，這多個key不必定都存儲在同一個redis-server上。所以，redis的事務機制，十分雞肋。

• 若是對這個key操做，不要求順序：準備一個分佈式鎖，你們去搶鎖，搶到鎖就作set操做便可
• 若是對這個key操做，要求順序：分佈式鎖+時間戳。假設這會系統B先搶到鎖，將key1設置爲{valueB 3:05}。接下來系統A搶到鎖，發現本身的valueA的時間戳早於緩存中的時間戳，那就不作set操做了。以此類推。
• 利用隊列，將set方法變成串行訪問也能夠redis遇到高併發，若是保證讀寫key的一致性

對redis的操做都是具備原子性的,是線程安全的操做,你不用考慮併發問題,redis內部已經幫你處理好併發的問題了。

Redis 集羣方案應該怎麼作？都有哪些方案？

1.twemproxy，大概概念是，它相似於一個代理方式， 使用時在本須要鏈接 redis 的地方改成鏈接 twemproxy， 它會以一個代理的身份接收請求並使用一致性 hash 算法，將請求轉接到具體 redis，將結果再返回 twemproxy。

缺點：twemproxy 自身單端口實例的壓力，使用一致性 hash 後，對 redis 節點數量改變時候的計算值的改變，數據沒法自動移動到新的節點。

2.codis，目前用的最多的集羣方案，基本和 twemproxy 一致的效果，但它支持在 節點數量改變狀況下，舊節點數據可恢復到新 hash 節點

3.redis cluster3.0 自帶的集羣，特色在於他的分佈式算法不是一致性 hash，而是 hash 槽的概念，以及自身支持節點設置從節點。具體看官方文檔介紹。

有沒有嘗試進行多機redis 的部署？如何保證數據一致的？

主從複製，讀寫分離

一類是主數據庫（master）一類是從數據庫（slave），主數據庫能夠進行讀寫操做，當發生寫操做的時候自動將數據同步到從數據庫，而從數據庫通常是隻讀的，並接收主數據庫同步過來的數據，一個主數據庫能夠有多個從數據庫，而一個從數據庫只能有一個主數據庫。

對於大量的請求怎麼樣處理

redis是一個單線程程序，也就說同一時刻它只能處理一個客戶端請求；

redis是經過IO多路複用（select，epoll, kqueue，依據不一樣的平臺，採起不一樣的實現）來處理多個客戶端請求的

Redis 常見性能問題和解決方案？

(1) Master 最好不要作任何持久化工做，如 RDB 內存快照和 AOF 日誌文件

(2) 若是數據比較重要，某個 Slave 開啓 AOF 備份數據，策略設置爲每秒同步一次

(3) 爲了主從複製的速度和鏈接的穩定性， Master 和 Slave 最好在同一個局域網內

(4) 儘可能避免在壓力很大的主庫上增長從庫

(5) 主從複製不要用圖狀結構，用單向鏈表結構更爲穩定，即：Master <- Slave1 <- Slave2 <- Slave3…

講解下Redis線程模型

文件事件處理器包括分別是套接字、 I/O 多路複用程序、 文件事件分派器（dispatcher）、 以及事件處理器。使用 I/O 多路複用程序來同時監聽多個套接字， 並根據套接字目前執行的任務來爲套接字關聯不一樣的事件處理器。

當被監聽的套接字準備好執行鏈接應答（accept）、讀取（read）、寫入（write）、關閉（close）等操做時， 與操做相對應的文件事件就會產生， 這時文件事件處理器就會調用套接字以前關聯好的事件處理器來處理這些事件。

I/O 多路複用程序負責監聽多個套接字， 並向文件事件分派器傳送那些產生了事件的套接字。

工做原理：

I/O 多路複用程序負責監聽多個套接字， 並向文件事件分派器傳送那些產生了事件的套接字。

儘管多個文件事件可能會併發地出現， 但 I/O 多路複用程序老是會將全部產生事件的套接字都入隊到一個隊列裏面， 而後經過這個隊列， 以有序（sequentially）、同步（synchronously）、每次一個套接字的方式向文件事件分派器傳送套接字：

當上一個套接字產生的事件被處理完畢以後（該套接字爲事件所關聯的事件處理器執行完畢）， I/O 多路複用程序纔會繼續向文件事件分派器傳送下一個套接字。若是一個套接字又可讀又可寫的話， 那麼服務器將先讀套接字， 後寫套接字.

爲何Redis的操做是原子性的，怎麼保證原子性的？

對於Redis而言，命令的原子性指的是：一個操做的不能夠再分，操做要麼執行，要麼不執行。

Redis的操做之因此是原子性的，是由於Redis是單線程的。（Redis新版本已經引入多線程，這裏基於舊版本的Redis）

Redis自己提供的全部API都是原子操做，Redis中的事務實際上是要保證批量操做的原子性。

多個命令在併發中也是原子性的嗎？

不必定， 將get和set改爲單命令操做，incr 。使用Redis的事務，或者使用Redis+Lua==的方式實現.

Redis事務

Redis事務功能是經過MULTI、EXEC、DISCARD和WATCH 四個原語實現的

Redis會將一個事務中的全部命令序列化，而後按順序執行。

1. redis 不支持回滾「Redis 在事務失敗時不進行回滾，而是繼續執行餘下的命令」， 因此 Redis 的內部能夠保持簡單且快速。
2. 若是在一個事務中的命令出現錯誤，那麼全部的命令都不會執行；
3. 若是在一個事務中出現運行錯誤，那麼正確的命令會被執行。

注：redis的discard只是結束本次事務,正確命令形成的影響仍然存在.

1）MULTI命令用於開啓一個事務，它老是返回OK。MULTI執行以後，客戶端能夠繼續向服務器發送任意多條命令，這些命令不會當即被執行，而是被放到一個隊列中，當EXEC命令被調用時，全部隊列中的命令纔會被執行。

2）EXEC：執行全部事務塊內的命令。返回事務塊內全部命令的返回值，按命令執行的前後順序排列。當操做被打斷時，返回空值 nil 。

3）經過調用DISCARD，客戶端能夠清空事務隊列，並放棄執行事務， 而且客戶端會從事務狀態中退出。

4）WATCH 命令能夠爲 Redis 事務提供 check-and-set （CAS）行爲。能夠監控一個或多個鍵，一旦其中有一個鍵被修改（或刪除），以後的事務就不會執行，監控一直持續到EXEC命令。

Redis實現分佈式鎖

Redis爲單進程單線程模式，採用隊列模式將併發訪問變成串行訪問，且多客戶端對Redis的鏈接並不存在競爭關係Redis中可使用SETNX命令實現分佈式鎖。

將 key 的值設爲 value ，當且僅當 key 不存在。若給定的 key 已經存在，則 SETNX 不作任何動做

解鎖：使用 del key 命令就能釋放鎖

解決死鎖：

• 經過Redis中expire()給鎖設定最大持有時間，若是超過，則Redis來幫咱們釋放鎖。
• 使用 setnx key 「當前系統時間+鎖持有的時間」和getset key 「當前系統時間+鎖持有的時間」組合的命令就能夠實現。

  總結

  歡迎關注公衆號：程序員白楠楠 ，領取pdf文檔的Java核心知識點總結！

這些資料的內容都是面試時面試官必問的知識點，篇章包括了不少知識點，其中包括了有基礎知識、Java集合、JVM、多線程併發、spring原理、微服務、Netty 與RPC 、Kafka、日記、設計模式、Java算法、數據庫、Zookeeper、分佈式緩存、數據結構等等。

你們一塊兒交流，喜歡文章記得關注我點個贊喲，感謝支持！