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

前言

現在大家的工作生活基本已經是迴歸正軌了,最近也是迎來了跳槽面試季,有些人已經拿到了一兩個offer了。

v2-d195026c75b6e186f2a2f6e4d061144c_720w.png

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

1、Redis持久化機制

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

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

4、Memcache與Redis的區別都有哪些?

5、單線程的redis爲什麼這麼快

6、redis的數據類型,以及每種數據類型的使用場景

7、redis的過期策略以及內存淘汰機制

8、Redis 爲什麼是單線程的

9、Redis 常見性能問題和解決方案?

10、爲什麼Redis的操作是原子性的,怎麼保證原子性的?

11、Redis事務

v2-195cd720ad6342520577761f85c68b7c_b.jpeg

Redis系列高頻面試題解析

Redis持久化機制

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

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

RDB是Redis默認的持久化方式。按照一定的時間週期策略把內存的數據以快照的形式保存到硬盤的二

進制文件。即Snapshot快照存儲,對應產生的數據文件爲dump.rdb,通過配置文件中的save參數來定義快照的週期。( 快照可以是其所表示的數據的一個副本,也可以是數據的一個複製品。)

AOF:Redis會將每一個收到的寫命令都通過Write函數追加到文件最後,類似於MySQL的binlog。當Redis重啓是會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。

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

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

1、緩存雪崩

我們可以簡單的理解爲:由於原有緩存失效,新緩存未到期間

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

解決辦法:

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

2、緩存穿透

緩存穿透是指用戶查詢數據,在數據庫沒有,自然在緩存中也不會有。這樣就導致用戶查詢的時候,在緩存中找不到,每次都要去數據庫再查詢一遍,然後返回空(相當於進行了兩次無用的查詢)。這樣請求就繞過緩存直接查數據庫,這也是經常提的緩存命中率問題。

解決辦法;

最常見的則是採用布隆過濾器,將所有可能存在的數據哈希到一個足夠大的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一般用於在大數據量的集合中判定某元素是否存在。

3、緩存預熱

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

解決思路:

1、直接寫個緩存刷新頁面,上線時手工操作下;

2、數據量不大,可以在項目啓動的時候自動進行加載;

3、定時刷新緩存;

4、緩存更新

除了緩存服務器自帶的緩存失效策略之外(Redis默認的有6中策略可供選擇),我們還可以根據具體的業務需求進行自定義的緩存淘汰,常見的策略有兩種:

(1)定時去清理過期的緩存;

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

兩者各有優劣,第一種的缺點是維護大量緩存的key是比較麻煩的,第二種的缺點就是每次用戶請求過來都要判斷緩存失效,邏輯相對比較複雜!具體用哪種方案,大家可以根據自己的應用場景來權衡。

5、緩存降級

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

降級的最終目的是保證核心服務可用,即使是有損的。而且有些服務是無法降級的(如加入購物車、結算)。

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

(1)一般:比如有些服務偶爾因爲網絡抖動或者服務正在上線而超時,可以自動降級;

(2)警告:有些服務在一段時間內成功率有波動(如在95~100%之間),可以自動降級或人工降級,併發送告警;

(3)錯誤:比如可用率低於90%,或者數據庫連接池被打爆了,或者訪問量突然猛增到系統能承受的最大閥值,此時可以根據情況自動降級或者人工降級;

(4)嚴重錯誤:比如因爲特殊原因數據錯誤了,此時需要緊急人工降級。

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

熱點數據和冷數據是什麼

熱點數據,緩存才有價值

對於冷數據而言,大部分數據可能還沒有再次訪問到就已經被擠出內存,不僅佔用內存,而且價值不場景。

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

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

數據更新前至少讀取兩次,緩存纔有意義。這個是最基本的策略,如果緩存還沒有起作用就失效了,那就沒有太大價值了。

那存不存在,修改頻率很高,但是又不得不考慮緩存的場景呢?有!比如,這個讀取接口對數據庫的壓力很大,但是又是熱點數據,這個時候就需要考慮通過緩存手段,減少數據庫的壓力,比如我們的某助手產品的,點贊數,收藏數,分享數等是非常典型的熱點數據,但是又不斷變化,此時就需要將數據同步保存到Redis緩存,減少數據庫壓力。

Memcache與Redis的區別都有哪些?

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

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

3、使用底層模型不同 它們之間底層實現方式 以及與客戶端之間通信的應用協議不一樣。 Redis直接自己構建了VM 機制 ,因爲一般的系統調用系統函數的話,會浪費一定的時間去移動和請求。

4、 value 值大小不同:Redis 最大可以達到 1gb;memcache 只有 1mb。

5、redis的速度比memcached快很多

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

單線程的redis爲什麼這麼快

1、純內存操作

2、單線程操作,避免了頻繁的上下文切換

3、採用了非阻塞I/O多路複用機制

v2-b2c0bae12db537d55a114d8ce200076f_720w.png

redis的數據類型,以及每種數據類型的使用場景

回答:一共五種

1、String

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

2、hash

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

3、list

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

4、set

因爲set堆放的是一堆不重複值的集合。所以可以做全局去重的功能。爲什麼不用JVM自帶的Set進行去重?因爲我們的系統一般都是集羣部署,使用JVM自帶的Set,比較麻煩,難道爲了一個做一個全局去重,再起一個公共服務,太麻煩了。

另外,就是利用交集、並集、差集等操作,可以計算共同喜好,全部的喜好,自己獨有的喜好等功能。

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

1、絕大部分請求是純粹的內存操作(非常快速)

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

3、非阻塞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 常見性能問題和解決方案?

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

2、 如果數據比較重要,某個 Slave 開啓 AOF 備份數據,策略設置爲每秒同步一次

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

4、儘量避免在壓力很大的主庫上增加從庫

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

爲什麼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、如果在一個事務中出現運行錯誤,那麼正確的命令會被執行。

(1)MULTI命令用於開啓一個事務,它總是返回OK。 MULTI執行之後,客戶端可以繼續向服務器發送任意多條命令,這些命令不會立即被執行,而是被放到一個隊列中,當EXEC命令被調用時,所有隊列中的命令纔會被執行。

(2)EXEC:執行所有事務塊內的命令。返回事務塊內所有命令的返回值,按命令執行的先後順序排列。當操作被打斷時,返回空值 nil 。

(3)通過調用DISCARD,客戶端可以清空事務隊列,並放棄執行事務, 並且客戶端會從事務狀態中退出。

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

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

v2-66e3ac816240d5e37736cc7394c9bf75_720w.jpeg


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

最後

歡迎大家一起交流,喜歡文章記得關注我點個贊喲,感謝支持!


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章