面試官:咱們來聊一下Redis吧

面試開始

1

小伙子你好,看你簡歷上寫了你項(xiàng)目里面用到了Redis,你們?yōu)樯队肦edis?

心里忍不住暗罵,這叫啥問題,大家不都是用的這個(gè)嘛,但是你不能說出來。

認(rèn)真回答道:你好,因?yàn)閭鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫如Mysql已經(jīng)不能適用所有的場景了,比如秒殺的庫存扣減,APP首頁的訪問流量高峰等等,都很容易把數(shù)據(jù)庫打崩,所以引入了緩存中間件,目前市面上比較常用的緩存中間件有Redis 和 Memcached 不過中和考慮了他們的優(yōu)缺點(diǎn),最后選擇了Redis。

ps:至于更詳細(xì)的對(duì)比朋友們記得查閱Redis 和 Memcached 的區(qū)別,比如兩者的優(yōu)缺點(diǎn)對(duì)比和各自的場景。

那小伙子,我再問你,Redis有哪些數(shù)據(jù)結(jié)構(gòu)呀?

字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。

這里我相信99%的讀者都能回答上來Redis的5個(gè)基本數(shù)據(jù)類型。如果回答不出來的小伙伴就要加油補(bǔ)課了喲(可以私聊我要學(xué)習(xí)資料哦),大家知道五種類型最適合的場景更好。

但是,如果你是Redis中高級(jí)用戶,而且你要在這次面試中突出你和其他候選人的不同,還需要加上下面幾種數(shù)據(jù)結(jié)構(gòu)HyperLogLog、Geo、Pub/Sub。

如果你還想加分,那你說還玩過Redis Module,像BloomFilter,RedisSearch,Redis-ML,這個(gè)時(shí)候面試官得眼睛就開始發(fā)亮了,心想這個(gè)小伙子有點(diǎn)東西啊。

注:本人在面試回答到Redis相關(guān)的問題的時(shí)候,經(jīng)常提到BloomFilter(布隆過濾器)這玩意的使用場景是真的多,而且用起來是真的香,原理也好理解,看一下文章就可以在面試官面前侃侃而談了,不香么?

如果有大量的key需要設(shè)置同一時(shí)間過期,一般需要注意什么?

如果大量的key過期時(shí)間設(shè)置的過于集中,到過期的那個(gè)時(shí)間點(diǎn),redis可能會(huì)出現(xiàn)短暫的卡頓現(xiàn)象。嚴(yán)重的話會(huì)出現(xiàn)緩存雪崩,我們一般需要在時(shí)間上加一個(gè)隨機(jī)值,使得過期時(shí)間分散一些。

電商首頁經(jīng)常會(huì)使用定時(shí)任務(wù)刷新緩存,可能大量的數(shù)據(jù)失效時(shí)間都十分集中,如果失效時(shí)間一樣,又剛好在失效的時(shí)間點(diǎn)大量用戶涌入,就有可能造成緩存雪崩

那你使用過Redis分布式鎖么,它是什么回事?

先拿setnx來爭搶鎖,搶到之后,再用expire給鎖加一個(gè)過期時(shí)間防止鎖忘記了釋放。

這時(shí)候?qū)Ψ綍?huì)告訴你說你回答得不錯(cuò),然后接著問如果在setnx之后執(zhí)行expire之前進(jìn)程意外crash或者要重啟維護(hù)了,那會(huì)怎么樣?

這時(shí)候你要給予驚訝的反饋:唉,是喔,這個(gè)鎖就永遠(yuǎn)得不到釋放了。緊接著你需要抓一抓自己得腦袋,故作思考片刻,好像接下來的結(jié)果是你主動(dòng)思考出來的,然后回答:我記得set指令有非常復(fù)雜的參數(shù),這個(gè)應(yīng)該是可以同時(shí)把setnx和expire合成一條指令來用的!

對(duì)方這時(shí)會(huì)顯露笑容,心里開始默念:嗯,這小子還不錯(cuò),開始有點(diǎn)意思了。

假如Redis里面有1億個(gè)key,其中有10w個(gè)key是以某個(gè)固定的已知的前綴開頭的,如何將它們?nèi)空页鰜恚?/strong>

使用keys指令可以掃出指定模式的key列表。

對(duì)方接著追問:如果這個(gè)redis正在給線上的業(yè)務(wù)提供服務(wù),那使用keys指令會(huì)有什么問題?

這個(gè)時(shí)候你要回答redis關(guān)鍵的一個(gè)特性:redis的單線程的。keys指令會(huì)導(dǎo)致線程阻塞一段時(shí)間,線上服務(wù)會(huì)停頓,直到指令執(zhí)行完畢,服務(wù)才能恢復(fù)。這個(gè)時(shí)候可以使用scan指令,scan指令可以無阻塞的提取出指定模式的key列表,但是會(huì)有一定的重復(fù)概率,在客戶端做一次去重就可以了,但是整體所花費(fèi)的時(shí)間會(huì)比直接用keys指令長。

不過,增量式迭代命令也不是沒有缺點(diǎn)的: 舉個(gè)例子, 使用 SMEMBERS 命令可以返回集合鍵當(dāng)前包含的所有元素, 但是對(duì)于 SCAN 這類增量式迭代命令來說, 因?yàn)樵趯?duì)鍵進(jìn)行增量式迭代的過程中, 鍵可能會(huì)被修改, 所以增量式迭代命令只能對(duì)被返回的元素提供有限的保證 。

使用過Redis做異步隊(duì)列么,你是怎么用的?

一般使用list結(jié)構(gòu)作為隊(duì)列,rpush生產(chǎn)消息,lpop消費(fèi)消息。當(dāng)lpop沒有消息的時(shí)候,要適當(dāng)sleep一會(huì)再重試。

如果對(duì)方追問可不可以不用sleep呢?

list還有個(gè)指令叫blpop,在沒有消息的時(shí)候,它會(huì)阻塞住直到消息到來。

如果對(duì)方接著追問能不能生產(chǎn)一次消費(fèi)多次呢?

使用pub/sub主題訂閱者模式,可以實(shí)現(xiàn) 1:N 的消息隊(duì)列。

如果對(duì)方繼續(xù)追問 pub/su b有什么缺點(diǎn)?

在消費(fèi)者下線的情況下,生產(chǎn)的消息會(huì)丟失,得使用專業(yè)的消息隊(duì)列如RocketMQ等。

如果對(duì)方究極TM追問Redis如何實(shí)現(xiàn)延時(shí)隊(duì)列?

這一套連招下來,我估計(jì)現(xiàn)在你很想把面試官一棒打死(面試官自己都想打死自己了怎么問了這么多自己都不知道的),如果你手上有一根棒球棍的話,但是你很克制。平復(fù)一下激動(dòng)的內(nèi)心,然后神態(tài)自若的回答道:使用sortedset,拿時(shí)間戳作為score,消息內(nèi)容作為key調(diào)用zadd來生產(chǎn)消息,消費(fèi)者用zrangebyscore指令獲取N秒之前的數(shù)據(jù)輪詢進(jìn)行處理。

到這里,面試官暗地里已經(jīng)對(duì)你豎起了大拇指。并且已經(jīng)默默給了你A+,但是他不知道的是此刻你卻豎起了中指,在椅子背后。

2

Redis是怎么持久化的?服務(wù)主從數(shù)據(jù)怎么交互的?

RDB做鏡像全量持久化,AOF做增量持久化。因?yàn)镽DB會(huì)耗費(fèi)較長時(shí)間,不夠?qū)崟r(shí),在停機(jī)的時(shí)候會(huì)導(dǎo)致大量丟失數(shù)據(jù),所以需要AOF來配合使用。在redis實(shí)例重啟時(shí),會(huì)使用RDB持久化文件重新構(gòu)建內(nèi)存,再使用AOF重放近期的操作指令來實(shí)現(xiàn)完整恢復(fù)重啟之前的狀態(tài)。

這里很好理解,把RDB理解為一整個(gè)表全量的數(shù)據(jù),AOF理解為每次操作的日志就好了,服務(wù)器重啟的時(shí)候先把表的數(shù)據(jù)全部搞進(jìn)去,但是他可能不完整,你再回放一下日志,數(shù)據(jù)不就完整了嘛。不過Redis本身的機(jī)制是 AOF持久化開啟且存在AOF文件時(shí),優(yōu)先加載AOF文件;AOF關(guān)閉或者AOF文件不存在時(shí),加載RDB文件;加載AOF/RDB文件城后,Redis啟動(dòng)成功; AOF/RDB文件存在錯(cuò)誤時(shí),Redis啟動(dòng)失敗并打印錯(cuò)誤信息

對(duì)方追問那如果突然機(jī)器掉電會(huì)怎樣?

取決于AOF日志sync屬性的配置,如果不要求性能,在每條寫指令時(shí)都sync一下磁盤,就不會(huì)丟失數(shù)據(jù)。但是在高性能的要求下每次都sync是不現(xiàn)實(shí)的,一般都使用定時(shí)sync,比如1s1次,這個(gè)時(shí)候最多就會(huì)丟失1s的數(shù)據(jù)。

對(duì)方追問RDB的原理是什么?

你給出兩個(gè)詞匯就可以了,fork和cow。fork是指redis通過創(chuàng)建子進(jìn)程來進(jìn)行RDB操作,cow指的是copy on write,子進(jìn)程創(chuàng)建后,父子進(jìn)程共享數(shù)據(jù)段,父進(jìn)程繼續(xù)提供讀寫服務(wù),寫臟的頁面數(shù)據(jù)會(huì)逐漸和子進(jìn)程分離開來。

注:回答這個(gè)問題的時(shí)候,如果你還能說出AOF和RDB的優(yōu)缺點(diǎn),我覺得我是面試官在這個(gè)問題上我會(huì)給你點(diǎn)贊,兩者其實(shí)區(qū)別還是很大的,而且涉及到Redis集群的數(shù)據(jù)同步問題等等。

Pipeline有什么好處,為什么要用pipeline?

可以將多次IO往返的時(shí)間縮減為一次,前提是pipeline執(zhí)行的指令之間沒有因果相關(guān)性。使用redis-benchmark進(jìn)行壓測的時(shí)候可以發(fā)現(xiàn)影響redis的QPS峰值的一個(gè)重要因素是pipeline批次指令的數(shù)目。

Redis的同步機(jī)制了解么?

Redis可以使用主從同步,從從同步。第一次同步時(shí),主節(jié)點(diǎn)做一次bgsave,并同時(shí)將后續(xù)修改操作記錄到內(nèi)存buffer,待完成后將RDB文件全量同步到復(fù)制節(jié)點(diǎn),復(fù)制節(jié)點(diǎn)接受完成后將RDB鏡像加載到內(nèi)存。加載完成后,再通知主節(jié)點(diǎn)將期間修改的操作記錄同步到復(fù)制節(jié)點(diǎn)進(jìn)行重放就完成了同步過程。后續(xù)的增量數(shù)據(jù)通過AOF日志同步即可,有點(diǎn)類似數(shù)據(jù)庫的binlog。

是否使用過Redis集群,集群的高可用怎么保證,集群的原理是什么?

Redis Sentinal著眼于高可用,在master宕機(jī)時(shí)會(huì)自動(dòng)將slave提升為master,繼續(xù)提供服務(wù)。

Redis Cluster著眼于擴(kuò)展性,在單個(gè)redis內(nèi)存不足時(shí),使用Cluster進(jìn)行分片存儲(chǔ)。

面試結(jié)束

小伙子你可以的,什么時(shí)候有時(shí)間來上班啊,要不明天就來吧?

你強(qiáng)裝鎮(zhèn)定,這么急啊我還需要租房,要不下禮拜一吧。

好的 心想這小子這么NB是不是很多Offer在手上,不行我得叫hr給他加錢。

能撐到最后,你自己都忍不住自己給自己點(diǎn)個(gè)贊了!

在技術(shù)面試的時(shí)候,不管是Redis還是什么問題,如果你能舉出實(shí)際的例子,或者是直接說自己開發(fā)過程的問題和收獲會(huì)給面試官的印象分會(huì)加很多,回答邏輯性也要強(qiáng)一點(diǎn),不要東一點(diǎn)西一點(diǎn),容易把自己都繞暈的。

還有一點(diǎn)就是我問你為啥用Redis你不要一上來就直接回答問題了,你可以這樣回答:

您好,首先我們的項(xiàng)目DB遇到了瓶頸,特別是秒殺和熱點(diǎn)數(shù)據(jù)這樣的場景DB基本上就扛不住了,那就需要緩存中間件的加入了,目前市面上有的緩存中間件有 Redis 和 Memcached ,他們的優(yōu)缺點(diǎn)……,綜合這些然后再結(jié)合我們項(xiàng)目特點(diǎn),最后我們在技術(shù)選型的時(shí)候選了誰。

如果你這樣有條不紊,有理有據(jù)的回答了我的問題而且還說出這么多我問題外的知識(shí)點(diǎn),我會(huì)覺得你不只是一個(gè)會(huì)寫代碼的人,你邏輯清晰,你對(duì)技術(shù)選型,對(duì)中間件對(duì)項(xiàng)目都有自己的理解和思考,說白了就是你的offer有戲了。

好了 以上就是這篇文章的全部內(nèi)容了,非常感謝您能看到這里,如果這個(gè)文章寫得還不錯(cuò)的話 求點(diǎn)贊 求關(guān)注 求分享 求留言!

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 1、使用redis有哪些好處? 速度快,因?yàn)閿?shù)據(jù)存在內(nèi)存中,類似于HashMap,HashMap的優(yōu)勢就是查找和操...
    小蘇c閱讀 269評(píng)論 0 1
  • 企業(yè)級(jí)redis集群架構(gòu)的特點(diǎn) 海量數(shù)據(jù) 高并發(fā) 高可用 要達(dá)到高可用,持久化是不可減少的,持久化主要是做災(zāi)難恢復(fù)...
    lucode閱讀 2,285評(píng)論 0 7
  • 一、Redis高可用概述 在介紹Redis高可用之前,先說明一下在Redis的語境中高可用的含義。 我們知道,在w...
    空語閱讀 1,686評(píng)論 0 2
  • 從被動(dòng)變?yōu)橹鲃?dòng) 長期窩在自我舒適區(qū)中打盹兒的人,不會(huì)太主動(dòng)。 主動(dòng)意味著承擔(dān)。例如想主動(dòng)和人談...
    醉酒笑看人生閱讀 300評(píng)論 0 2
  • 今天是我們在一起的352天,還有13天就是一年了。 初戀對(duì)于我來說是說特殊不特殊說平凡不平凡的一個(gè)詞眼。 活了十多...
    menqengwo閱讀 416評(píng)論 0 1

友情鏈接更多精彩內(nèi)容