從阿里、騰訊的面試真題中總結了這11個Redis高頻面試題

前言

如今你們的工做生活基本已是迴歸正軌了，最近也是迎來了跳槽面試季，有些人已經拿到了一兩個offer了。

這段時間收集了阿里、騰訊、百度、京東、美團、字節跳動等公司的Java面試題，總結了Redis系列的高頻面試題：

一、Redis持久化機制

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

三、熱點數據和冷數據是什麼

四、Memcache與Redis的區別都有哪些？

五、單線程的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通常用於在大數據量的集合中斷定某元素是否存在。

三、緩存預熱

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

解決思路：

一、直接寫個緩存刷新頁面，上線時手工操做下；

二、數據量不大，能夠在項目啓動的時候自動進行加載；

三、定時刷新緩存；

四、緩存更新

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

（1）定時去清理過時的緩存；

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

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

五、緩存降級

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

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

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

（1）通常：好比有些服務偶爾由於網絡抖動或者服務正在上線而超時，能夠自動降級；

（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），能夠自動降級或人工降級，併發送告警；

（3）錯誤：好比可用率低於90%，或者數據庫鏈接池被打爆了，或者訪問量忽然猛增到系統能承受的最大閥值，此時能夠根據狀況自動降級或者人工降級；

（4）嚴重錯誤：好比由於特殊緣由數據錯誤了，此時須要緊急人工降級。

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

熱點數據和冷數據是什麼

熱點數據，緩存纔有價值

對於冷數據而言，大部分數據可能尚未再次訪問到就已經被擠出內存，不只佔用內存，並且價值不場景。

對於熱點數據，好比咱們的某IM產品，生日祝福模塊，當天的壽星列表，緩存之後可能讀取數十萬次。

再舉個例子，某導航產品，咱們將導航信息，緩存之後可能讀取數百萬次。

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

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

Memcache與Redis的區別都有哪些？

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

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

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

四、 value 值大小不一樣：Redis 最大能夠達到 1gb；memcache 只有 1mb。

五、redis的速度比memcached快不少

六、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

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-lru

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

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利用隊列技術將併發訪問變爲串行訪問

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

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

三、非阻塞IO優勢：

（1）速度快，由於數據存在內存中，相似於HashMap，HashMap的優點就是查找和操做的時間複雜度都是O(1)

（2）支持豐富數據類型，支持string，list，set，sorted set，hash

（3）支持事務，操做都是原子性，所謂的原子性就是對數據的更改要麼所有執行，要麼所有不執行

（4）豐富的特性：可用於緩存，消息，按key設置過時時間，過時後將會自動刪除如何解決redis的併發競爭key問題同時有多個子系統去set一個key。這個時候要注意什麼呢？ 不推薦使用redis的事務機制。由於咱們的生產環境，基本都是redis集羣環境，作了數據分片操做。你一個事務中有涉及到多個key操做的時候，這多個key不必定都存儲在同一個redis-server上。所以，redis的事務機制，十分難搞。

(1)若是對這個key操做，不要求順序： 準備一個分佈式鎖，你們去搶鎖，搶到鎖就作set操做便可做了。以此類推。

(2) 利用隊列，將set方法變成串行訪問也能夠redis遇到高併發，若是保證讀寫key的一致性對redis的操做都是具備原子性的,是線程安全的操做,你不用考慮併發問題,redis內部已經幫你處理好併發的問題了。

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

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

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

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

四、儘可能避免在壓力很大的主庫上增長從庫

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

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

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

Redis的操做之因此是原子性的，是由於Redis是單線程的。

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

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

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

Redis事務

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

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

一、redis 不支持回滾「Redis 在事務失敗時不進行回滾，而是繼續執行餘下的命令」， 因此 Redis 的內部能夠保持簡單且快速。

二、若是在一個事務中的命令出現錯誤，那麼全部的命令都不會執行；

三、若是在一個事務中出現運行錯誤，那麼正確的命令會被執行。

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

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

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

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

歡迎關注公種浩：程序員追風，回覆66  ，領取一份300頁pdf文檔的Java核心知識點總結！

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

最後

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