App下載

面試官最愛問的 11道 Redis 面試題,我替你整理好了

猿友 2020-10-09 14:21:59 瀏覽數(shù) (2764)
反饋

說說Redis基本數(shù)據(jù)類型有哪些吧

  1. 字符串:redis沒有直接使用C語言傳統(tǒng)的字符串表示,而是自己實(shí)現(xiàn)的叫做簡(jiǎn)單動(dòng)態(tài)字符串SDS的抽象類型。C語言的字符串不記錄自身的長(zhǎng)度信息,而SDS則保存了長(zhǎng)度信息,這樣將獲取字符串長(zhǎng)度的時(shí)間由O(N)降低到了O(1),同時(shí)可以避免緩沖區(qū)溢出和減少修改字符串長(zhǎng)度時(shí)所需的內(nèi)存重分配次數(shù)。
  2. 鏈表linkedlist:redis鏈表是一個(gè)雙向無環(huán)鏈表結(jié)構(gòu),很多發(fā)布訂閱、慢查詢、監(jiān)視器功能都是使用到了鏈表來實(shí)現(xiàn),每個(gè)鏈表的節(jié)點(diǎn)由一個(gè)listNode結(jié)構(gòu)來表示,每個(gè)節(jié)點(diǎn)都有指向前置節(jié)點(diǎn)和后置節(jié)點(diǎn)的指針,同時(shí)表頭節(jié)點(diǎn)的前置和后置節(jié)點(diǎn)都指向NULL。
  3. 字典hashtable:用于保存鍵值對(duì)的抽象數(shù)據(jù)結(jié)構(gòu)。redis使用hash表作為底層實(shí)現(xiàn),每個(gè)字典帶有兩個(gè)hash表,供平時(shí)使用和rehash時(shí)使用,hash表使用鏈地址法來解決鍵沖突,被分配到同一個(gè)索引位置的多個(gè)鍵值對(duì)會(huì)形成一個(gè)單向鏈表,在對(duì)hash表進(jìn)行擴(kuò)容或者縮容的時(shí)候,為了服務(wù)的可用性,rehash的過程不是一次性完成的,而是漸進(jìn)式的。
  4. 跳躍表skiplist:跳躍表是有序集合的底層實(shí)現(xiàn)之一,redis中在實(shí)現(xiàn)有序集合鍵和集群節(jié)點(diǎn)的內(nèi)部結(jié)構(gòu)中都是用到了跳躍表。redis跳躍表由zskiplist和zskiplistNode組成,zskiplist用于保存跳躍表信息(表頭、表尾節(jié)點(diǎn)、長(zhǎng)度等),zskiplistNode用于表示表跳躍節(jié)點(diǎn),每個(gè)跳躍表的層高都是1-32的隨機(jī)數(shù),在同一個(gè)跳躍表中,多個(gè)節(jié)點(diǎn)可以包含相同的分值,但是每個(gè)節(jié)點(diǎn)的成員對(duì)象必須是唯一的,節(jié)點(diǎn)按照分值大小排序,如果分值相同,則按照成員對(duì)象的大小排序。
  5. 整數(shù)集合intset:用于保存整數(shù)值的集合抽象數(shù)據(jù)結(jié)構(gòu),不會(huì)出現(xiàn)重復(fù)元素,底層實(shí)現(xiàn)為數(shù)組。
  6. 壓縮列表ziplist:壓縮列表是為節(jié)約內(nèi)存而開發(fā)的順序性數(shù)據(jù)結(jié)構(gòu),他可以包含多個(gè)節(jié)點(diǎn),每個(gè)節(jié)點(diǎn)可以保存一個(gè)字節(jié)數(shù)組或者整數(shù)值。

基于這些基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu),redis 封裝了自己的對(duì)象系統(tǒng),包含字符串對(duì)象string、列表對(duì)象list、哈希對(duì)象hash、集合對(duì)象set、有序集合對(duì)象zset,每種對(duì)象都用到了至少一種基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)。

redis 通過encoding屬性設(shè)置對(duì)象的編碼形式來提升靈活性和效率,基于不同的場(chǎng)景redis會(huì)自動(dòng)做出優(yōu)化。不同對(duì)象的編碼如下:

  1. 字符串對(duì)象string:int整數(shù)、embstr編碼的簡(jiǎn)單動(dòng)態(tài)字符串、raw簡(jiǎn)單動(dòng)態(tài)字符串

  1. 列表對(duì)象list:ziplist、linkedlist

  1. 哈希對(duì)象hash:ziplist、hashtable

  1. 集合對(duì)象set:intset、hashtable

  1. 有序集合對(duì)象zset:ziplist、skiplist

Redis為什么快呢?

redis 的速度非常的快,單機(jī)的 redis 就可以支撐每秒10幾萬的并發(fā),相對(duì)于 mysql 來說,性能是 mysql 的幾十倍。速度快的原因主要有幾點(diǎn):

  1. 完全基于內(nèi)存操作
  2. C語言實(shí)現(xiàn),優(yōu)化過的數(shù)據(jù)結(jié)構(gòu),基于幾種基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu),redis做了大量的優(yōu)化,性能極高
  3. 使用單線程,無上下文的切換成本
  4. 基于非阻塞的IO多路復(fù)用機(jī)制

那為什么Redis6.0之后又改用多線程呢?

redis 使用多線程并非是完全摒棄單線程,redis 還是使用單線程模型來處理客戶端的請(qǐng)求,只是使用多線程來處理數(shù)據(jù)的讀寫和協(xié)議解析,執(zhí)行命令還是使用單線程。

這樣做的目的是因?yàn)?redis 的性能瓶頸在于網(wǎng)絡(luò)IO而非CPU,使用多線程能提升IO讀寫的效率,從而整體提高 redis 的性能。

知道什么是熱key嗎?熱key問題怎么解決?

所謂熱key問題就是,突然有幾十萬的請(qǐng)求去訪問 redis 上的某個(gè)特定key,那么這樣會(huì)造成流量過于集中,達(dá)到物理網(wǎng)卡上限,從而導(dǎo)致這臺(tái)redis的服務(wù)器宕機(jī)引發(fā)雪崩。

什么是熱key

針對(duì)熱key的解決方案:

  1. 提前把熱key打散到不同的服務(wù)器,降低壓力
  2. 加入二級(jí)緩存,提前加載熱key數(shù)據(jù)到內(nèi)存中,如果 redis 宕機(jī),走內(nèi)存查詢

什么是緩存擊穿、緩存穿透、緩存雪崩?

緩存擊穿

緩存擊穿的概念就是單個(gè)key并發(fā)訪問過高,過期時(shí)導(dǎo)致所有請(qǐng)求直接打到db上,這個(gè)和熱key的問題比較類似,只是說的點(diǎn)在于過期導(dǎo)致請(qǐng)求全部打到DB上而已。

解決方案:

  1. 加鎖更新,比如請(qǐng)求查詢A,發(fā)現(xiàn)緩存中沒有,對(duì)A這個(gè)key加鎖,同時(shí)去數(shù)據(jù)庫查詢數(shù)據(jù),寫入緩存,再返回給用戶,這樣后面的請(qǐng)求就可以從緩存中拿到數(shù)據(jù)了。
  2. 將過期時(shí)間組合寫在value中,通過異步的方式不斷的刷新過期時(shí)間,防止此類現(xiàn)象。

緩存擊穿

緩存穿透

緩存穿透是指查詢不存在緩存中的數(shù)據(jù),每次請(qǐng)求都會(huì)打到DB,就像緩存不存在一樣。

緩存穿透

針對(duì)這個(gè)問題,加一層布隆過濾器。布隆過濾器的原理是在你存入數(shù)據(jù)的時(shí)候,會(huì)通過散列函數(shù)將它映射為一個(gè)位數(shù)組中的K個(gè)點(diǎn),同時(shí)把他們置為1。

這樣當(dāng)用戶再次來查詢A,而A在布隆過濾器值為0,直接返回,就不會(huì)產(chǎn)生擊穿請(qǐng)求打到DB了。

顯然,使用布隆過濾器之后會(huì)有一個(gè)問題就是誤判,因?yàn)樗旧硎且粋€(gè)數(shù)組,可能會(huì)有多個(gè)值落到同一個(gè)位置,那么理論上來說只要我們的數(shù)組長(zhǎng)度夠長(zhǎng),誤判的概率就會(huì)越低,這種問題就根據(jù)實(shí)際情況來就好了。

緩存穿透解決方案

緩存雪崩

當(dāng)某一時(shí)刻發(fā)生大規(guī)模的緩存失效的情況,比如你的緩存服務(wù)宕機(jī)了,會(huì)有大量的請(qǐng)求進(jìn)來直接打到DB上,這樣可能導(dǎo)致整個(gè)系統(tǒng)的崩潰,稱為雪崩。雪崩和擊穿、熱key的問題不太一樣的是,他是指大規(guī)模的緩存都過期失效了。

緩存雪崩

針對(duì)雪崩幾個(gè)解決方案:

  1. 針對(duì)不同key設(shè)置不同的過期時(shí)間,避免同時(shí)過期
  2. 限流,如果redis宕機(jī),可以限流,避免同時(shí)刻大量請(qǐng)求打崩DB
  3. 二級(jí)緩存,同熱key的方案。

Redis的過期策略有哪些?

redis主要有2種過期刪除策略

惰性刪除

惰性刪除指的是當(dāng)我們查詢key的時(shí)候才對(duì)key進(jìn)行檢測(cè),如果已經(jīng)達(dá)到過期時(shí)間,則刪除。顯然,他有一個(gè)缺點(diǎn)就是如果這些過期的key沒有被訪問,那么他就一直無法被刪除,而且一直占用內(nèi)存。

惰性刪除

定期刪除

定期刪除指的是redis每隔一段時(shí)間對(duì)數(shù)據(jù)庫做一次檢查,刪除里面的過期key。由于不可能對(duì)所有key去做輪詢來刪除,所以redis會(huì)每次隨機(jī)取一些key去做檢查和刪除。

那么定期+惰性都沒有刪除過期的key怎么辦?

假設(shè)redis每次定期隨機(jī)查詢key的時(shí)候沒有刪掉,這些key也沒有做查詢的話,就會(huì)導(dǎo)致這些key一直保存在redis里面無法被刪除,這時(shí)候就會(huì)走到redis的內(nèi)存淘汰機(jī)制。

  1. volatile-lru:從已設(shè)置過期時(shí)間的key中,移出最近最少使用的key進(jìn)行淘汰
  2. volatile-ttl:從已設(shè)置過期時(shí)間的key中,移出將要過期的key
  3. volatile-random:從已設(shè)置過期時(shí)間的key中隨機(jī)選擇key淘汰
  4. allkeys-lru:從key中選擇最近最少使用的進(jìn)行淘汰
  5. allkeys-random:從key中隨機(jī)選擇key進(jìn)行淘汰
  6. noeviction:當(dāng)內(nèi)存達(dá)到閾值的時(shí)候,新寫入操作報(bào)錯(cuò)

持久化方式有哪些?有什么區(qū)別?

redis持久化方案分為RDB和AOF兩種。

RDB

RDB持久化可以手動(dòng)執(zhí)行也可以根據(jù)配置定期執(zhí)行,它的作用是將某個(gè)時(shí)間點(diǎn)上的數(shù)據(jù)庫狀態(tài)保存到RDB文件中,RDB文件是一個(gè)壓縮的二進(jìn)制文件,通過它可以還原某個(gè)時(shí)刻數(shù)據(jù)庫的狀態(tài)。由于RDB文件是保存在硬盤上的,所以即使redis崩潰或者退出,只要RDB文件存在,就可以用它來恢復(fù)還原數(shù)據(jù)庫的狀態(tài)。

可以通過SAVE或者BGSAVE來生成RDB文件。

SAVE命令會(huì)阻塞redis進(jìn)程,直到RDB文件生成完畢,在進(jìn)程阻塞期間,redis不能處理任何命令請(qǐng)求,這顯然是不合適的。

BGSAVE則是會(huì)fork出一個(gè)子進(jìn)程,然后由子進(jìn)程去負(fù)責(zé)生成RDB文件,父進(jìn)程還可以繼續(xù)處理命令請(qǐng)求,不會(huì)阻塞進(jìn)程。

AOF

AOF和RDB不同,AOF是通過保存redis服務(wù)器所執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)的。

AOF通過追加、寫入、同步三個(gè)步驟來實(shí)現(xiàn)持久化機(jī)制。

  1. 當(dāng)AOF持久化處于激活狀態(tài),服務(wù)器執(zhí)行完寫命令之后,寫命令將會(huì)被追加append到aof_buf緩沖區(qū)的末尾
  2. 在服務(wù)器每結(jié)束一個(gè)事件循環(huán)之前,將會(huì)調(diào)用flushAppendOnlyFile函數(shù)決定是否要將aof_buf的內(nèi)容保存到AOF文件中,可以通過配置appendfsync來決定。

always ##aof_buf內(nèi)容寫入并同步到AOF文件
everysec ##將aof_buf中內(nèi)容寫入到AOF文件,如果上次同步AOF文件時(shí)間距離現(xiàn)在超過1秒,則再次對(duì)AOF文件進(jìn)行同步
no ##將aof_buf內(nèi)容寫入AOF文件,但是并不對(duì)AOF文件進(jìn)行同步,同步時(shí)間由操作系統(tǒng)決定

如果不設(shè)置,默認(rèn)選項(xiàng)將會(huì)是everysec,因?yàn)閍lways來說雖然最安全(只會(huì)丟失一次事件循環(huán)的寫命令),但是性能較差,而everysec模式只不過會(huì)可能丟失1秒鐘的數(shù)據(jù),而no模式的效率和everysec相仿,但是會(huì)丟失上次同步AOF文件之后的所有寫命令數(shù)據(jù)。

怎么實(shí)現(xiàn)Redis的高可用?

要想實(shí)現(xiàn)高可用,一臺(tái)機(jī)器肯定是不夠的,而redis要保證高可用,有2個(gè)可選方案。

主從架構(gòu)

主從模式是最簡(jiǎn)單的實(shí)現(xiàn)高可用的方案,核心就是主從同步。主從同步的原理如下:

  1. slave發(fā)送sync命令到master
  2. master收到sync之后,執(zhí)行bgsave,生成RDB全量文件
  3. master把slave的寫命令記錄到緩存
  4. bgsave執(zhí)行完畢之后,發(fā)送RDB文件到slave,slave執(zhí)行
  5. master發(fā)送緩存中的寫命令到slave,slave執(zhí)行

主從架構(gòu)

這里我寫的這個(gè)命令是sync,但是在redis2.8版本之后已經(jīng)使用psync來替代sync了,原因是sync命令非常消耗系統(tǒng)資源,而psync的效率更高。

哨兵

基于主從方案的缺點(diǎn)還是很明顯的,假設(shè)master宕機(jī),那么就不能寫入數(shù)據(jù),那么slave也就失去了作用,整個(gè)架構(gòu)就不可用了,除非你手動(dòng)切換,主要原因就是因?yàn)闆]有自動(dòng)故障轉(zhuǎn)移機(jī)制。而哨兵(sentinel)的功能比單純的主從架構(gòu)全面的多了,它具備自動(dòng)故障轉(zhuǎn)移、集群監(jiān)控、消息通知等功能。

哨兵

哨兵可以同時(shí)監(jiān)視多個(gè)主從服務(wù)器,并且在被監(jiān)視的master下線時(shí),自動(dòng)將某個(gè)slave提升為master,然后由新的master繼續(xù)接收命令。整個(gè)過程如下:

  1. 初始化sentinel,將普通的redis代碼替換成sentinel專用代碼
  2. 初始化masters字典和服務(wù)器信息,服務(wù)器信息主要保存ip:port,并記錄實(shí)例的地址和ID
  3. 創(chuàng)建和master的兩個(gè)連接,命令連接和訂閱連接,并且訂閱sentinel:hello頻道
  4. 每隔10秒向master發(fā)送info命令,獲取master和它下面所有slave的當(dāng)前信息
  5. 當(dāng)發(fā)現(xiàn)master有新的slave之后,sentinel和新的slave同樣建立兩個(gè)連接,同時(shí)每個(gè)10秒發(fā)送info命令,更新master信息
  6. sentinel每隔1秒向所有服務(wù)器發(fā)送ping命令,如果某臺(tái)服務(wù)器在配置的響應(yīng)時(shí)間內(nèi)連續(xù)返回?zé)o效回復(fù),將會(huì)被標(biāo)記為下線狀態(tài)
  7. 選舉出領(lǐng)頭sentinel,領(lǐng)頭sentinel需要半數(shù)以上的sentinel同意
  8. 領(lǐng)頭sentinel從已下線的的master所有slave中挑選一個(gè),將其轉(zhuǎn)換為master
  9. 讓所有的slave改為從新的master復(fù)制數(shù)據(jù)
  10. 將原來的master設(shè)置為新的master的從服務(wù)器,當(dāng)原來master重新回復(fù)連接時(shí),就變成了新master的從服務(wù)器

sentinel會(huì)每隔1秒向所有實(shí)例(包括主從服務(wù)器和其他sentinel)發(fā)送ping命令,并且根據(jù)回復(fù)判斷是否已經(jīng)下線,這種方式叫做主觀下線。當(dāng)判斷為主觀下線時(shí),就會(huì)向其他監(jiān)視的sentinel詢問,如果超過半數(shù)的投票認(rèn)為已經(jīng)是下線狀態(tài),則會(huì)標(biāo)記為客觀下線狀態(tài),同時(shí)觸發(fā)故障轉(zhuǎn)移。

能說說redis集群的原理嗎?

如果說依靠哨兵可以實(shí)現(xiàn)redis的高可用,如果還想在支持高并發(fā)同時(shí)容納海量的數(shù)據(jù),那就需要redis集群。redis集群是redis提供的分布式數(shù)據(jù)存儲(chǔ)方案,集群通過數(shù)據(jù)分片sharding來進(jìn)行數(shù)據(jù)的共享,同時(shí)提供復(fù)制和故障轉(zhuǎn)移的功能。

節(jié)點(diǎn)

一個(gè)redis集群由多個(gè)節(jié)點(diǎn)node組成,而多個(gè)node之間通過cluster meet命令來進(jìn)行連接,節(jié)點(diǎn)的握手過程:

  1. 節(jié)點(diǎn)A收到客戶端的cluster meet命令
  2. A根據(jù)收到的IP地址和端口號(hào),向B發(fā)送一條meet消息
  3. 節(jié)點(diǎn)B收到meet消息返回pong
  4. A知道B收到了meet消息,返回一條ping消息,握手成功
  5. 最后,節(jié)點(diǎn)A將會(huì)通過gossip協(xié)議把節(jié)點(diǎn)B的信息傳播給集群中的其他節(jié)點(diǎn),其他節(jié)點(diǎn)也將和B進(jìn)行握手

節(jié)點(diǎn)

槽slot

redis通過集群分片的形式來保存數(shù)據(jù),整個(gè)集群數(shù)據(jù)庫被分為16384個(gè)slot,集群中的每個(gè)節(jié)點(diǎn)可以處理0-16384個(gè)slot,當(dāng)數(shù)據(jù)庫16384個(gè)slot都有節(jié)點(diǎn)在處理時(shí),集群處于上線狀態(tài),反之只要有一個(gè)slot沒有得到處理都會(huì)處理下線狀態(tài)。通過cluster addslots命令可以將slot指派給對(duì)應(yīng)節(jié)點(diǎn)處理。

slot是一個(gè)位數(shù)組,數(shù)組的長(zhǎng)度是16384/8=2048,而數(shù)組的每一位用1表示被節(jié)點(diǎn)處理,0表示不處理,如圖所示的話表示A節(jié)點(diǎn)處理0-7的slot。

槽slot

當(dāng)客戶端向節(jié)點(diǎn)發(fā)送命令,如果剛好找到slot屬于當(dāng)前節(jié)點(diǎn),那么節(jié)點(diǎn)就執(zhí)行命令,反之,則會(huì)返回一個(gè)MOVED命令到客戶端指引客戶端轉(zhuǎn)向正確的節(jié)點(diǎn)。(MOVED過程是自動(dòng)的)

槽slot

如果增加或者移出節(jié)點(diǎn),對(duì)于slot的重新分配也是非常方便的,redis提供了工具幫助實(shí)現(xiàn)slot的遷移,整個(gè)過程是完全在線的,不需要停止服務(wù)。

故障轉(zhuǎn)移

如果節(jié)點(diǎn)A向節(jié)點(diǎn)B發(fā)送ping消息,節(jié)點(diǎn)B沒有在規(guī)定的時(shí)間內(nèi)響應(yīng)pong,那么節(jié)點(diǎn)A會(huì)標(biāo)記節(jié)點(diǎn)B為pfail疑似下線狀態(tài),同時(shí)把B的狀態(tài)通過消息的形式發(fā)送給其他節(jié)點(diǎn),如果超過半數(shù)以上的節(jié)點(diǎn)都標(biāo)記B為pfail狀態(tài),B就會(huì)被標(biāo)記為fail下線狀態(tài),此時(shí)將會(huì)發(fā)生故障轉(zhuǎn)移,優(yōu)先從復(fù)制數(shù)據(jù)較多的從節(jié)點(diǎn)選擇一個(gè)成為主節(jié)點(diǎn),并且接管下線節(jié)點(diǎn)的slot,整個(gè)過程和哨兵非常類似,都是基于Raft協(xié)議做選舉。

了解Redis事務(wù)機(jī)制嗎?

redis 通過MULTI、EXEC、WATCH等命令來實(shí)現(xiàn)事務(wù)機(jī)制,事務(wù)執(zhí)行過程將一系列多個(gè)命令按照順序一次性執(zhí)行,并且在執(zhí)行期間,事務(wù)不會(huì)被中斷,也不會(huì)去執(zhí)行客戶端的其他請(qǐng)求,直到所有命令執(zhí)行完畢。事務(wù)的執(zhí)行過程如下:

  1. 服務(wù)端收到客戶端請(qǐng)求,事務(wù)以MULTI開始
  2. 如果客戶端正處于事務(wù)狀態(tài),則會(huì)把事務(wù)放入隊(duì)列同時(shí)返回給客戶端QUEUED,反之則直接執(zhí)行這個(gè)命令
  3. 當(dāng)收到客戶端EXEC命令時(shí),WATCH命令監(jiān)視整個(gè)事務(wù)中的key是否有被修改,如果有則返回空回復(fù)到客戶端表示失敗,否則redis會(huì)遍歷整個(gè)事務(wù)隊(duì)列,執(zhí)行隊(duì)列中保存的所有命令,最后返回結(jié)果給客戶端

WATCH的機(jī)制本身是一個(gè)CAS的機(jī)制,被監(jiān)視的key會(huì)被保存到一個(gè)鏈表中,如果某個(gè)key被修改,那么REDIS_DIRTY_CAS標(biāo)志將會(huì)被打開,這時(shí)服務(wù)器會(huì)拒絕執(zhí)行事務(wù)。

文章來源于公眾號(hào):科技繆繆 ,作者科技繆繆

以上就是W3Cschool編程獅關(guān)于面試官最愛問的 11道 Redis 面試題,我替你整理好了的相關(guān)介紹了,希望對(duì)大家有所幫助。

0 人點(diǎn)贊