[[387146]]

本文轉(zhuǎn)載自微信公眾號「程序員jinjunzhu」，作者 jinjunzhu 。轉(zhuǎn)載本文請聯(lián)系程序員jinjunzhu公眾號。

又到了金三銀四跳槽季，好多同學已經(jīng)開始行動了。今天我來助力一把，送出這套redis面試題，助力大家通關(guān)。

1 redis為什么響應快

1.1數(shù)據(jù)保存在內(nèi)存中

redis數(shù)據(jù)保存在內(nèi)存中，讀寫操作只要訪問內(nèi)存，不需要磁盤IO。

1.2.底層數(shù)據(jù)結(jié)構(gòu)

redis的數(shù)據(jù)以key:value的格式存儲在散列表中，時間復雜度o(1)。

redis為value定義了豐富的數(shù)據(jù)結(jié)構(gòu)，包括態(tài)字符串、雙向鏈表、壓縮列表、hash、跳表和整數(shù)數(shù)組，可以根據(jù)value的特性選擇選擇最高效的數(shù)據(jù)結(jié)構(gòu)。

1.3.單線程模型

redis的網(wǎng)絡IO和數(shù)據(jù)讀寫使用單線程模型，可以綁定CPU，這避免了線程上下文切換帶來的開銷。

「注意：redis6.0對網(wǎng)絡請求引入了多線程模型，讀寫操作還是用單線程?！?/p>

redis多線程網(wǎng)絡模型見下圖：

1.4.IO多路復用

redis采用epoll網(wǎng)絡模型，如下圖：

內(nèi)核會一直監(jiān)聽新的socket連接事件的和已建立socket連接的讀寫事件，把監(jiān)聽到的事件放到事件隊列，redis使用單線程不停的處理這個事件隊列。這避免了阻塞等待連接和讀寫事件到來。

這些事件綁定了回調(diào)函數(shù)，會調(diào)用redis的處理函數(shù)進行處理。

2 redis底層數(shù)據(jù)結(jié)構(gòu)

redis有5種數(shù)據(jù)類型，包括「字符串、列表、集合、有序集合和字典」。

redis底層的數(shù)據(jù)結(jié)構(gòu)有6種，包括「動態(tài)字符串、雙向鏈表、壓縮列表(ziplist)、hash表、跳表(skip list)和整數(shù)數(shù)組」。

redis數(shù)據(jù)類型和底層數(shù)據(jù)結(jié)構(gòu)有如下對應關(guān)系:

2.1.字符串類型

底層數(shù)據(jù)結(jié)構(gòu)是動態(tài)字符串。

2.2.列表

如果同時滿足下面條件，就使用壓縮列表，否則使用雙向鏈表。

• 列表中單個元素小于64字節(jié)
• 列表中元素個數(shù)少于 512

「壓縮列表」在內(nèi)存中是一塊兒連續(xù)的內(nèi)存空間，結(jié)構(gòu)如下：

「壓縮列表查找時間復雜度是o(n)」

2.3.集合

如果同時滿足下面條件，就使用有序整數(shù)數(shù)組，否則使用hash表。

• 集合中元素都是整數(shù)類型
• 集合中元素個數(shù)不超過512個

2.4.有序集合

如果同時滿足下面2個條件，就使用壓縮列表，否則使用跳表。

• 集合中元素都小于64字節(jié)
• 集合中元素個數(shù)小于128個

「注意：有序集合還有一個HASH表用于保存集合中元素的分數(shù)，做ZSCORE操作時，查詢的就是這個HASH表，所以效率很高?！?/p>

「跳表」的結(jié)構(gòu)如下：

如果不加索引，查找10這個數(shù)字需要查詢10次，使用了二級索引，查找10這個數(shù)字需要5次，而使用一級索引，需要查詢3次。

跳表的每一層都是一個有序鏈表，最下面一層保存了全部數(shù)據(jù)。跳表插入、刪除、查詢的時間復雜度是o(logN)。跳表需要存儲額外的索引節(jié)點，會增加額外的空間開銷。

2.5.字典

如果同時滿足下面2個條件，就使用壓縮列表，否則使用hash表。

• 字典中每個entry的key/value都小于64字節(jié)
• 字典中元素個數(shù)小于512個

3 redis緩存淘汰策略

redis總共有8種淘汰策略，如下圖：

volatile-lfu和allkeys-lfu策略是4.0版本新增的。

• 「lru」是按照數(shù)據(jù)的最近最少訪問原則來淘汰數(shù)據(jù)，可能存在的問題是如果大批量冷數(shù)據(jù)最近被訪問了一次，就會占用大量內(nèi)存空間，如果緩存滿了，部分熱數(shù)據(jù)就會被淘汰掉。
• 「lfu」是按照數(shù)據(jù)的最小訪問頻率訪問次數(shù)原則來淘汰數(shù)據(jù)，如果兩個數(shù)據(jù)的訪問次數(shù)相同，則把訪問時間較早的數(shù)據(jù)淘汰。

4 redis數(shù)據(jù)持久化

redis持久化的方式有2種，一種是寫后日志(AOF),一種是內(nèi)存快照(RDB)。

4.1.AOF日志

AOF日志記錄了每一條收到的命令，redis故障宕機恢復時，可以加載AOF日志中的命令進行重放來進行故障恢復。AOF有3種同步策略，如下圖：圖片

如果不是對丟失數(shù)據(jù)特別敏感的業(yè)務，推薦使用everysec，對主線程的阻塞少，故障后丟失數(shù)據(jù)只有1s。

4.2.RDB快照

RDB快照是一個內(nèi)存快照,記錄了redis某一時刻的全部數(shù)據(jù)。

4.3.混合日志

從redis4.0開始，AOF文件也可以保存RDB快照，AOF重寫的時候redis會把AOF文件內(nèi)容清空，先記錄一份RDB快照，這份數(shù)據(jù)以"REDIS"開頭。記錄RDB內(nèi)容后，AOF文件會接著記錄AOF命令。故障恢復時，先加載AOF文件中RDB快照，然后回放AOF文件中后面的命令。

4.4.主從同步

redis主從同步時，主節(jié)點會先生成一份RDB快照發(fā)送給從節(jié)點，把快照之后的命令寫入主從同步緩存區(qū)(replication buffer)，從節(jié)點把RDB文件加載完成后，主節(jié)點把緩存區(qū)命令發(fā)送給從節(jié)點。

4.5.AOF重寫

AOF日志是用記錄命令的方式追加的，這樣可能存在對同一個key的多條命令，這些命令是可以合并成1條的。比如對同一個key的多個set操作日志，可以合成一條。

4.6.阻塞點

AOF重寫和RDB快照執(zhí)行的過程中，redis都會fork一個子進程來執(zhí)行操作，子進程執(zhí)行過程中是不是阻塞主線程的。

「但是要注意2點：」

fork子進程的過程中，redis主線程會拷貝一份內(nèi)存頁表(記錄了虛擬內(nèi)存和物理內(nèi)存的映射關(guān)系)給子進程，這個過程是阻塞的，redis主線程內(nèi)存越大，阻塞時間越長;

子進程和redis主線程共用一塊兒物理內(nèi)存，如果新的請求到來，必須使用copy on write的方式，拷貝要修改的數(shù)據(jù)頁到新的內(nèi)存空間進行修改。如下圖：

注意:如果開啟了內(nèi)存大頁，每次拷貝都需要分配2MB的內(nèi)存。

5 redis高可用

下圖是一個「一主二從三哨兵」的架構(gòu)圖:

從圖我們可以看到哨兵之間、哨兵和主從節(jié)點之間、哨兵和客戶端之間都建立了連接。

如果主節(jié)點掛了，哨兵集群需要完成主從切換，如下圖：

下面我們依次來聊一下這4個步驟「5.1~5.4」。

5.1.判斷主節(jié)點下線

當一個哨兵監(jiān)控到主節(jié)點下線時，就會給其他哨兵發(fā)送確認命令，其他命令會根據(jù)自己的判斷回復"Y"或"N"。

如果有n/2 + 1以上數(shù)量的哨兵都認為主節(jié)點下線了，才會判定主節(jié)點下線。這里的n是哨兵集群的數(shù)量。

n/2 + 1這個參數(shù)由quorum參數(shù)配置，比如有5個哨兵，這里一般配置成3。也可以配置成其他值。

5.2.選舉新主節(jié)點

主節(jié)點被判定下線后，哨兵集群會重新選擇新的主節(jié)點。

5.2.1 淘汰不穩(wěn)定從節(jié)點

根據(jù)配置參數(shù)down-after-milliseconds * 10來淘汰。

「down-after-milliseconds」表示主從節(jié)點斷開時間，10表示次數(shù)，如果從節(jié)點跟主節(jié)點斷開時間超過down-after-milliseconds的次數(shù)達到了10次以上，從節(jié)點就被淘汰了。

5.2.2 slave-priority參數(shù)

「slave-priority」參數(shù)配置了從節(jié)點的優(yōu)先級，選擇從節(jié)點時哨兵會優(yōu)先選擇優(yōu)先級高的從節(jié)點。

5.2.3 復制進度

redis有一個記錄主從增量復制的緩存區(qū)叫repl_backlog_buffer，這是一個環(huán)形結(jié)構(gòu)的緩沖區(qū)，如下圖：

主節(jié)點有一個寫偏移量master_repl_offset，從節(jié)點也有一個偏移量slave_repl_offset。優(yōu)先選擇slave_repl_offset最接近master_repl_offset的從節(jié)點作為新的主節(jié)點。

所以，上圖中偏移量為114的從節(jié)點優(yōu)先被選為新的主節(jié)點。

5.2.4 ID編號

優(yōu)先級和參數(shù)都一樣的情況下，ID編號小的從節(jié)點優(yōu)先被選為新主節(jié)點。

5.3.選舉哨兵leader

第一個判斷主節(jié)點下線的哨兵節(jié)點收到其他節(jié)點的回復并確定主節(jié)點下線后，就會給其他哨兵發(fā)送命令申請成為哨兵leader。

「成為leader的條件如下：」

• 收到贊成票必須大于等quorum值
• 必須拿到半數(shù)以上的贊成票

如果集群配置了5個哨兵，quorum的值設置為3，其中一個哨兵節(jié)點掛了，很有可能會判斷到主節(jié)點下線，但是因為選舉不出哨兵leader而不能切換。如果集群有2個哨兵，其中一個掛了，那必定選不出哨兵leader。

下面的圖展示了哨兵一成功當選leader的過程:

5.4.主節(jié)點切換

選出新主節(jié)點和哨兵leader后，哨兵leader會執(zhí)行主從切換的操作。完成后會做一些「事件通知」：

• 通知其他哨兵新主節(jié)點地址
• 通知所有從節(jié)點新的主節(jié)點地址，從節(jié)點收到后向新主節(jié)點請求主從同步
• 通知客戶端連接新主節(jié)點

5.5.主從切換過程中請求處理

如果客戶端的讀請求會發(fā)送到從節(jié)點，可以正常處理。

在客戶端收到新主節(jié)點地址通知前寫請求會失敗。

客戶端可以采取一些應急措施應對主節(jié)點下線，比如緩存寫請求。

為了能夠及時獲取到新主節(jié)點信息，客戶端可以訂閱哨兵的主節(jié)點下線事件和新主節(jié)點變更事件。

6 redis為什么變慢了

redis變慢了的原因有很多，總結(jié)一下有11個，見下圖：

從圖中看出，redis變慢原因主要有兩類：「阻塞主線程和操作系統(tǒng)限制」。

6.1主線程阻塞

6.1.1.AOF重寫和RDB快照

前面已經(jīng)講過了，redis在AOF重寫時，主線程會fork出一個bgrewriteaof子進程。

redis進行RDB快照時主線程會fork出一個bgsave子進程。

這兩個操作表面上看不阻塞主線程，但fork子進程的這個過程是在主線程完成的。fork子進程時redis需要拷貝內(nèi)存頁表，如果redis實例很大，這個拷貝會耗費大量的CPU資源，阻塞主線程的時間也會變長。

6.1.2.內(nèi)存大頁

redis默認支持內(nèi)存大頁是2MB，使用內(nèi)存大頁，一定程度上可以減少redis的內(nèi)存分配次數(shù)，但是對數(shù)據(jù)持久化會有一定影響。

redis在AOF重寫和RDB快照過程中，如果主線程收到新的寫請求，就需要CopyOnWrite。使用了內(nèi)存大頁，即使redis只修改其中一個大小是1kb的key，也需要拷貝一整頁的數(shù)據(jù)，即2MB。在寫入量較多時，大量拷貝就會導致redis性能下降。

6.1.3.命令復雜度高

執(zhí)行復雜度高的命令是造成redis阻塞的常見原因。比如對一個set或者list數(shù)據(jù)類型執(zhí)行SORT操作，復雜度是O(N+M*log(M))。

6.1.4.bigkey操作

如果一個key的value非常大，創(chuàng)建的時候分配內(nèi)存會很耗時，刪除的時候釋放內(nèi)存也很耗時。

redis4.0以后引入了layfree機制，可以使用子進程異步刪除，從而不影響主線程執(zhí)行。用UNLINK命令替代DEL命令，就可以使用子進程異步刪除。

redis6.0增加了配置項lazyfree-lazy-user-del，配置成yes后，del命令也可以用子進程異步刪除。

如果lazyfree-lazy-user-del不設置為yes，那redis是否采用異步刪除，是要看刪除的時機的。對于String類型和底層采用整數(shù)數(shù)組和壓縮列表的數(shù)據(jù)類型，redis是不會采用異步刪除的。

6.1.5.從節(jié)點全量同步

從節(jié)點全量同步過程中，需要先清除內(nèi)存中的數(shù)據(jù)，然后再加載RDB文件，這個過程中是阻塞的，如果有讀請求到來，只能等到加載RDB文件完成后才能處理請求，所以響應會很慢。

另外，如果redis實例很大，也會造成RDB文件太大，從庫加載時間長。所以盡量保持redis實例不要太大，比如單個實例限制4G，如果超出就采用切片集群。

6.1.6.AOF同步寫盤

appendfsync策略有3種：always、everysec、no，如果采用always，每個命令都會同步寫盤，這個過程是阻塞的，等寫盤成功后才能處理下一條命令。

除非是嚴格不能丟數(shù)據(jù)的場景，否則盡量不要選擇always策略，推薦盡量選擇everysec策略，如果對丟失數(shù)據(jù)不敏感，可以采用no。

6.1.7.內(nèi)存達到maxmemory

內(nèi)存達到maxmemory，需要使用淘汰策略來淘汰部分key。即使采用lazyfree異步刪除，選擇key的過程也是阻塞的。

可以選擇較快的淘汰策略，比如用隨機淘汰來替換LRU和LFU算法淘汰。也可以擴大切片數(shù)量來減輕淘汰key的時間消耗。

6.2操作系統(tǒng)限制

6.2.1.使用了swap

使用swap的原因是操作系統(tǒng)不能給redis分配足夠大的內(nèi)存，如果操作其他開啟了swap，內(nèi)存數(shù)據(jù)就需要不停地跟swap換入和換出，對性能影響非常大。

操作系統(tǒng)沒有能力分配內(nèi)存的原因也可能是其他進程使用了大量的內(nèi)存。

6.2.2.網(wǎng)絡問題

如果網(wǎng)卡負載很大，對redis性能影響會很大。這一方面有可能redis的訪問量確實很高，另一方面也可能是有其他流量大的程序占用了帶寬。

這個最好從運維層面進行監(jiān)控。

6.2.3.線程上下文切換

redis雖然是單線程的，但是在多核cpu的情況下，也可能會發(fā)生上下文切換。如果主線程從一個物理核切換到了另一個物理核，那就不能使用CPU高效的一級緩存和二級緩存了。如下圖所示：

為防止這種情況，可以把redis綁定到一個CPU物理核。

6.2.4.磁盤性能低

對于AOF同步寫盤的使用場景，如果磁盤性能低，也會影響redis的響應?？梢詢?yōu)先采用性能更好的SSD硬盤。

7 設計排行榜功能

redis的zset類型保存了分數(shù)值，可以方便的實現(xiàn)排行榜的功能。

比如要統(tǒng)計10篇文章的排行榜，可以先建立一個存放10篇文章的zset，每當有讀者閱讀一篇文章時，就用ZINCRBY命令給這篇文章的分數(shù)加1，最后可以用range命令統(tǒng)計排行榜前幾位的文章。

8 redis實現(xiàn)分布式鎖

8.1.redis單節(jié)點的分布式鎖

如下圖，一個服務部署了2個客戶端，獲取分布式鎖時一個成功，另一個就失敗了。

redis一般使用setnx實現(xiàn)分布式鎖，命令如下:

SETNX KEY_NAME VALUE 

設置成功返回 1，設置失敗返回 0。

使用單節(jié)點分布式鎖存在一些問題。

8.1.1.客戶端1獲取鎖后發(fā)生了故障

結(jié)果鎖就不能釋放了，其他客戶端永遠獲取不到鎖。解決方法是用下面命令對key設置過期時間：

SET key value [EX seconds] [PX milliseconds] NX 

8.1.2 客戶端2誤刪除了鎖

解決方法是對key設置value時加入一個客戶端表示，比如在客戶端1設置key時在value前拼接一個字符串a(chǎn)pplication1，刪除的時候做一下判斷。

8.2.redis紅鎖

redis單節(jié)點會有可靠性問題，節(jié)點故障后鎖操作就會失敗。redis為了應對單點故障的問題，設計了多節(jié)點的分布式鎖，也叫紅鎖。主要思想是客戶端跟多個redis實例請求加鎖，只有超過半數(shù)的實例加鎖成功，才認為成功獲取了分布式鎖。

如下圖,客戶端分別跟3個實例請求加鎖，有2個實例加鎖成功，所以獲取分布式鎖成功:

9 緩存雪崩、擊穿、穿透

9.1.緩存雪崩

redis做緩存時，如果同一時間大量緩存數(shù)據(jù)失效，客戶端請求會大量發(fā)送到數(shù)據(jù)庫，導致數(shù)據(jù)庫壓力激增。如下圖：

「應對方法主要有3個：」

• 給key設置過期時間時加一個小的隨機數(shù)
• 限流
• 服務降級

9.2.緩存擊穿

某個熱點key，突然過期了，大量請求發(fā)送到了數(shù)據(jù)庫。解決方案是給熱點key不設置過期時間。

9.3.緩存穿透

某個熱點key，查詢緩存和查詢數(shù)據(jù)庫都沒有，就發(fā)生了緩存穿透。如下圖:

「應對方法主要有2個：」

• 緩存熱點的空值和缺省值
• 查詢數(shù)據(jù)庫之前先查詢布隆過濾器

10 數(shù)據(jù)傾斜

什么是數(shù)據(jù)傾斜?看下面這個面試題：

如果redis有一個熱點key，qps能達到100w，該如何存儲?

如果這個熱點key被放到一個redis實例上，這個實例面臨的訪問壓力會非常大。如下圖，redis3這個實例保存了foo這個熱點key，訪問壓力會很大：

「解決方法主要有兩個：」

1.使用客戶端本地緩存來緩存key，這樣改造會有兩個問題：

• 客戶端緩存的熱點key可能消耗大量內(nèi)存

客戶端需要保證本地緩存和redis緩存的一致性

2.給熱點key加一個隨機前綴，讓它保存到不同的redis實例上，這樣也會存在兩個問題：

• 客戶端在訪問的時候需要給這個key加前綴
• 客戶端在刪除的時候需要根據(jù)所有前綴來刪除不同實例上保存的這個key

11 bitmap使用

有一道經(jīng)典的面試題，10億整數(shù)怎么在內(nèi)存中去重排序?

我們先算一下10億整數(shù)占的內(nèi)存，java一個整數(shù)類型占四字節(jié)，占用內(nèi)存大小約

10億 * 4 / 1024 / 1024 = 3.7G 

占得內(nèi)存太大了，如果內(nèi)存不夠，怎么辦呢?

11.1.bitmap介紹

bitmap類型使用的數(shù)據(jù)結(jié)構(gòu)是String，底層存儲格式是二進制的bit數(shù)組。假如我們有1、4、6、9四個數(shù)，保存在bit數(shù)組中如下圖：

在這個bit數(shù)組中用10個bit的空間保存了四個整數(shù)，占用空間非常小。

再回到面試題，我們使用bit數(shù)組長度是10億整數(shù)中 「(最大值 - 最小值 + 1)」。

如果有負數(shù)，需要進行一個轉(zhuǎn)化，所有數(shù)字加最小負數(shù)的絕對值。比如{-2, 0, 1, 3},我們轉(zhuǎn)換成{0, 2, 3, 5}，因為數(shù)組下標必須從0開始

11.2.使用場景

11.2.1.員工打卡記錄

在一個有100個員工的公司，要統(tǒng)計一個月內(nèi)員工全勤的人數(shù)，可以每天創(chuàng)建一個bitmap，簽到的員工bit位置為1。

要統(tǒng)計當天簽到的員工只要用BITCOUNT命令就可以。

要統(tǒng)計當月全勤的員工，只要對當月每天的bitmap做交集運算就可以，命令如下：

BITOP AND srckey1 srckey2 srckey3 ... srckey30 

srckeyN表示第N天的打卡記錄bitmap

11.2.2.統(tǒng)計網(wǎng)站日活躍用戶

比如網(wǎng)站有10萬個用戶，這樣我們創(chuàng)建一個長度為10萬的bitmap，每個用戶id占一個位，如果用戶登錄，就把bit位置為1，日終的時候用BITCOUNT命令統(tǒng)計出當天登錄過的用戶總數(shù)。