腳本之家服務(wù)器常用軟件

快捷導(dǎo)航

2021年最新Redis面試題匯總(3)

更新時(shí)間：2021年07月15日 17:31:56 作者：java李楊勇

在程序員面試過程中redis相關(guān)的知識(shí)是常被問到的話題。這篇文章主要介紹了幾道Redis面試題，整理一下分享給大家，感興趣的小伙伴們可以參考一下

1、Redis 怎么保證高可用、有哪些集群模式

主從復(fù)制、哨兵模式、集群模式。

2、主從復(fù)制

在當(dāng)前最新的 Redis 6.0 中，主從復(fù)制的完整過程如下：

1）開啟主從復(fù)制

通常有以下三種方式：

在 slave 直接執(zhí)行命令：slaveof <masterip> <masterport>
在 slave 配置文件中加入：slaveof <masterip> <masterport>
使用啟動(dòng)命令：--slaveof <masterip> <masterport>

注：在 Redis 5.0 之后，slaveof 相關(guān)命令和配置已經(jīng)被替換成 replicaof，例如 replicaof <masterip> <masterport>。為了兼容舊版本，通過配置的方式仍然支持 slaveof，但是通過命令的方式則不行了。

2）建立套接字（socket）連接

slave 將根據(jù)指定的 IP 地址和端口，向 master 發(fā)起套接字（socket）連接，master 在接受（accept） slave 的套接字連接之后，為該套接字創(chuàng)建相應(yīng)的客戶端狀態(tài)，此時(shí)連接建立完成。

3）發(fā)送PING命令

slave 向 master 發(fā)送一個(gè) PING 命令，以檢査套接字的讀寫狀態(tài)是否正常、 master 能否正常處理命令請(qǐng)求。

4）身份驗(yàn)證

slave 向 master 發(fā)送 AUTH password 命令來進(jìn)行身份驗(yàn)證。

5）發(fā)送端口信息

在身份驗(yàn)證通過后后， slave 將向 master 發(fā)送自己的監(jiān)聽端口號(hào)， master 收到后記錄在 slave 所對(duì)應(yīng)的客戶端狀態(tài)的 slave_listening_port 屬性中。

6）發(fā)送IP地址

如果配置了 slave_announce_ip，則 slave 向 master 發(fā)送 slave_announce_ip 配置的 IP 地址， master 收到后記錄在 slave 所對(duì)應(yīng)的客戶端狀態(tài)的 slave_ip 屬性。

該配置是用于解決服務(wù)器返回內(nèi)網(wǎng) IP 時(shí)，其他服務(wù)器無法訪問的情況?？梢酝ㄟ^該配置直接指定公網(wǎng) IP。

7）發(fā)送CAPA

CAPA 全稱是 capabilities，這邊表示的是同步復(fù)制的能力。slave 會(huì)在這一階段發(fā)送 capa 告訴 master 自己具備的（同步）復(fù)制能力， master 收到后記錄在 slave 所對(duì)應(yīng)的客戶端狀態(tài)的 slave_capa 屬性。

8）數(shù)據(jù)同步

slave 將向 master 發(fā)送 PSYNC 命令， master 收到該命令后判斷是進(jìn)行部分重同步還是完整重同步，然后根據(jù)策略進(jìn)行數(shù)據(jù)的同步。

9）命令傳播

當(dāng)完成了同步之后，就會(huì)進(jìn)入命令傳播階段，這時(shí) master 只要一直將自己執(zhí)行的寫命令發(fā)送給 slave ，而 slave 只要一直接收并執(zhí)行 master 發(fā)來的寫命令，就可以保證 master 和 slave 一直保持一致了。

以部分重同步為例，主從復(fù)制的核心步驟流程圖如下：

3、哨兵

哨兵（Sentinel）是 Redis 的高可用性解決方案：由一個(gè)或多個(gè) Sentinel 實(shí)例組成的 Sentinel 系統(tǒng)可以監(jiān)視任意多個(gè)主服務(wù)器，以及這些主服務(wù)器屬下的所有從服務(wù)器。

Sentinel 可以在被監(jiān)視的主服務(wù)器進(jìn)入下線狀態(tài)時(shí)，自動(dòng)將下線主服務(wù)器的某個(gè)從服務(wù)器升級(jí)為新的主服務(wù)器，然后由新的主服務(wù)器代替已下線的主服務(wù)器繼續(xù)處理命令請(qǐng)求。

1）哨兵故障檢測(cè)

檢查主觀下線狀態(tài)

在默認(rèn)情況下，Sentinel 會(huì)以每秒一次的頻率向所有與它創(chuàng)建了命令連接的實(shí)例（包括主服務(wù)器、從服務(wù)器、其他 Sentinel 在內(nèi)）發(fā)送 PING 命令，并通過實(shí)例返回的 PING 命令回復(fù)來判斷實(shí)例是否在線。

如果一個(gè)實(shí)例在 down-after-miliseconds 毫秒內(nèi)，連續(xù)向 Sentinel 返回?zé)o效回復(fù)，那么 Sentinel 會(huì)修改這個(gè)實(shí)例所對(duì)應(yīng)的實(shí)例結(jié)構(gòu)，在結(jié)構(gòu)的 flags 屬性中設(shè)置 SRI_S_DOWN 標(biāo)識(shí)，以此來表示這個(gè)實(shí)例已經(jīng)進(jìn)入主觀下線狀態(tài)。

檢查客觀下線狀態(tài)

當(dāng) Sentinel 將一個(gè)主服務(wù)器判斷為主觀下線之后，為了確定這個(gè)主服務(wù)器是否真的下線了，它會(huì)向同樣監(jiān)視這一服務(wù)器的其他 Sentinel 進(jìn)行詢問，看它們是否也認(rèn)為主服務(wù)器已經(jīng)進(jìn)入了下線狀態(tài)（可以是主觀下線或者客觀下線）。

當(dāng) Sentinel 從其他 Sentinel 那里接收到足夠數(shù)量（quorum，可配置）的已下線判斷之后，Sentinel 就會(huì)將服務(wù)器置為客觀下線，在 flags 上打上 SRI_O_DOWN 標(biāo)識(shí)，并對(duì)主服務(wù)器執(zhí)行故障轉(zhuǎn)移操作。

2）哨兵故障轉(zhuǎn)移流程

當(dāng)哨兵監(jiān)測(cè)到某個(gè)主節(jié)點(diǎn)客觀下線之后，就會(huì)開始故障轉(zhuǎn)移流程。核心流程如下：

發(fā)起一次選舉，選舉出領(lǐng)頭 Sentinel領(lǐng)頭 Sentinel 在已下線主服務(wù)器的所有從服務(wù)器里面，挑選出一個(gè)從服務(wù)器，并將其升級(jí)為新的主服務(wù)器。領(lǐng)頭 Sentinel 將剩余的所有從服務(wù)器改為復(fù)制新的主服務(wù)器。領(lǐng)頭 Sentinel 更新相關(guān)配置信息，當(dāng)這個(gè)舊的主服務(wù)器重新上線時(shí)，將其設(shè)置為新的主服務(wù)器的從服務(wù)器。

4、集群模式

哨兵模式最大的缺點(diǎn)就是所有的數(shù)據(jù)都放在一臺(tái)服務(wù)器上，無法較好的進(jìn)行水平擴(kuò)展。

為了解決哨兵模式存在的問題，集群模式應(yīng)運(yùn)而生。在高可用上，集群基本是直接復(fù)用的哨兵模式的邏輯，并且針對(duì)水平擴(kuò)展進(jìn)行了優(yōu)化。

集群模式具備的特點(diǎn)如下：

采取去中心化的集群模式，將數(shù)據(jù)按槽存儲(chǔ)分布在多個(gè) Redis 節(jié)點(diǎn)上。集群共有 16384 個(gè)槽，每個(gè)節(jié)點(diǎn)負(fù)責(zé)處理部分槽。
使用 CRC16 算法來計(jì)算 key 所屬的槽：crc16(key,keylen) & 16383。
所有的 Redis 節(jié)點(diǎn)彼此互聯(lián)，通過 PING-PONG 機(jī)制來進(jìn)行節(jié)點(diǎn)間的心跳檢測(cè)。
分片內(nèi)采用一主多從保證高可用，并提供復(fù)制和故障恢復(fù)功能。在實(shí)際使用中，通常會(huì)將主從分布在不同機(jī)房，避免機(jī)房出現(xiàn)故障導(dǎo)致整個(gè)分片出問題，下面的架構(gòu)圖就是這樣設(shè)計(jì)的。
客戶端與 Redis 節(jié)點(diǎn)直連，不需要中間代理層（proxy）?？蛻舳瞬恍枰B接集群所有節(jié)點(diǎn)，連接集群中任何一個(gè)可用節(jié)點(diǎn)即可。

集群的架構(gòu)圖如下所示：

5、集群選舉

故障轉(zhuǎn)移的第一步就是選舉出新的主節(jié)點(diǎn)，以下是集群選舉新的主節(jié)點(diǎn)的方法：

1）當(dāng)從節(jié)點(diǎn)發(fā)現(xiàn)自己正在復(fù)制的主節(jié)點(diǎn)進(jìn)入已下線狀態(tài)時(shí)，會(huì)發(fā)起一次選舉：將 currentEpoch（配置紀(jì)元）加1，然后向集群廣播一條 CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST 消息，要求所有收到這條消息、并且具有投票權(quán)的主節(jié)點(diǎn)向這個(gè)從節(jié)點(diǎn)投票。

2）其他節(jié)點(diǎn)收到消息后，會(huì)判斷是否要給發(fā)送消息的節(jié)點(diǎn)投票，判斷流程如下：

當(dāng)前節(jié)點(diǎn)是 slave，或者當(dāng)前節(jié)點(diǎn)是 master，但是不負(fù)責(zé)處理槽，則當(dāng)前節(jié)點(diǎn)沒有投票權(quán)，直接返回。
請(qǐng)求節(jié)點(diǎn)的 currentEpoch 小于當(dāng)前節(jié)點(diǎn)的 currentEpoch，校驗(yàn)失敗返回。因?yàn)榘l(fā)送者的狀態(tài)與當(dāng)前集群狀態(tài)不一致，可能是長(zhǎng)時(shí)間下線的節(jié)點(diǎn)剛剛上線，這種情況下，直接返回即可。
當(dāng)前節(jié)點(diǎn)在該 currentEpoch 已經(jīng)投過票，校驗(yàn)失敗返回。
請(qǐng)求節(jié)點(diǎn)是 master，校驗(yàn)失敗返回。
請(qǐng)求節(jié)點(diǎn)的 master 為空，校驗(yàn)失敗返回。
請(qǐng)求節(jié)點(diǎn)的 master 沒有故障，并且不是手動(dòng)故障轉(zhuǎn)移，校驗(yàn)失敗返回。因?yàn)槭謩?dòng)故障轉(zhuǎn)移是可以在 master 正常的情況下直接發(fā)起的。
上一次為該master的投票時(shí)間，在cluster_node_timeout的2倍范圍內(nèi)，校驗(yàn)失敗返回。這個(gè)用于使獲勝?gòu)墓?jié)點(diǎn)有時(shí)間將其成為新主節(jié)點(diǎn)的消息通知給其他從節(jié)點(diǎn)，從而避免另一個(gè)從節(jié)點(diǎn)發(fā)起新一輪選舉又進(jìn)行一次沒必要的故障轉(zhuǎn)移
請(qǐng)求節(jié)點(diǎn)宣稱要負(fù)責(zé)的槽位，是否比之前負(fù)責(zé)這些槽位的節(jié)點(diǎn)，具有相等或更大的 configEpoch，如果不是，校驗(yàn)失敗返回。

如果通過以上所有校驗(yàn)，那么主節(jié)點(diǎn)將向要求投票的從節(jié)點(diǎn)返回一條 CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK 消息，表示這個(gè)主節(jié)點(diǎn)支持從節(jié)點(diǎn)成為新的主節(jié)點(diǎn)。

3）每個(gè)參與選舉的從節(jié)點(diǎn)都會(huì)接收 CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK 消息，并根據(jù)自己收到了多少條這種消息來統(tǒng)計(jì)自己獲得了多少個(gè)主節(jié)點(diǎn)的支持。

4）如果集群里有N個(gè)具有投票權(quán)的主節(jié)點(diǎn)，那么當(dāng)一個(gè)從節(jié)點(diǎn)收集到大于等于N/2+1 張支持票時(shí)，這個(gè)從節(jié)點(diǎn)就會(huì)當(dāng)選為新的主節(jié)點(diǎn)。因?yàn)樵诿恳粋€(gè)配置紀(jì)元里面，每個(gè)具有投票權(quán)的主節(jié)點(diǎn)只能投一次票，所以如果有 N個(gè)主節(jié)點(diǎn)進(jìn)行投票，那么具有大于等于 N/2+1 張支持票的從節(jié)點(diǎn)只會(huì)有一個(gè)，這確保了新的主節(jié)點(diǎn)只會(huì)有一個(gè)。

5）如果在一個(gè)配置紀(jì)元里面沒有從節(jié)點(diǎn)能收集到足夠多的支持票，那么集群進(jìn)入一個(gè)新的配置紀(jì)元，并再次進(jìn)行選舉，直到選出新的主節(jié)點(diǎn)為止。

這個(gè)選舉新主節(jié)點(diǎn)的方法和選舉領(lǐng)頭 Sentinel 的方法非常相似，因?yàn)閮烧叨际腔?Raft 算法的領(lǐng)頭選舉（leader election）方法來實(shí)現(xiàn)的。

6、如何保證集群在線擴(kuò)容的安全性？（Redis 集群要增加分片，槽的遷移怎么保證無損）

例如：集群已經(jīng)對(duì)外提供服務(wù)，原來有3分片，準(zhǔn)備新增2個(gè)分片，怎么在不下線的情況下，無損的從原有的3個(gè)分片指派若干個(gè)槽給這2個(gè)分片？

Redis 使用了 ASK 錯(cuò)誤來保證在線擴(kuò)容的安全性。

在槽的遷移過程中若有客戶端訪問，依舊先訪問源節(jié)點(diǎn)，源節(jié)點(diǎn)會(huì)先在自己的數(shù)據(jù)庫里面査找指定的鍵，如果找到的話，就直接執(zhí)行客戶端發(fā)送的命令。

如果沒找到，說明該鍵可能已經(jīng)被遷移到目標(biāo)節(jié)點(diǎn)了，源節(jié)點(diǎn)將向客戶端返回一個(gè) ASK 錯(cuò)誤，該錯(cuò)誤會(huì)指引客戶端轉(zhuǎn)向正在導(dǎo)入槽的目標(biāo)節(jié)點(diǎn)，并再次發(fā)送之前想要執(zhí)行的命令，從而獲取到結(jié)果。

ASK錯(cuò)誤

在進(jìn)行重新分片期間，源節(jié)點(diǎn)向目標(biāo)節(jié)點(diǎn)遷移一個(gè)槽的過程中，可能會(huì)出現(xiàn)這樣一種情況：屬于被遷移槽的一部分鍵值對(duì)保存在源節(jié)點(diǎn)里面，而另一部分鍵值對(duì)則保存在目標(biāo)節(jié)點(diǎn)里面。

當(dāng)客戶端向源節(jié)點(diǎn)發(fā)送一個(gè)與數(shù)據(jù)庫鍵有關(guān)的命令，并且命令要處理的數(shù)據(jù)庫鍵恰好就屬于正在被遷移的槽時(shí)。源節(jié)點(diǎn)會(huì)先在自己的數(shù)據(jù)庫里面査找指定的鍵，如果找到的話，就直接執(zhí)行客戶端發(fā)送的命令。

否則，這個(gè)鍵有可能已經(jīng)被遷移到了目標(biāo)節(jié)點(diǎn)，源節(jié)點(diǎn)將向客戶端返回一個(gè) ASK 錯(cuò)誤，指引客戶端轉(zhuǎn)向正在導(dǎo)入槽的目標(biāo)節(jié)點(diǎn)，并再次發(fā)送之前想要執(zhí)行的命令，從而獲取到結(jié)果。

7、Redis 事務(wù)的實(shí)現(xiàn)

一個(gè)事務(wù)從開始到結(jié)束通常會(huì)經(jīng)歷以下3個(gè)階段：

1）事務(wù)開始：multi 命令將執(zhí)行該命令的客戶端從非事務(wù)狀態(tài)切換至事務(wù)狀態(tài)，底層通過 flags 屬性標(biāo)識(shí)。

2）命令入隊(duì)：當(dāng)客戶端處于事務(wù)狀態(tài)時(shí)，服務(wù)器會(huì)根據(jù)客戶端發(fā)來的命令執(zhí)行不同的操作：

exec、discard、watch、multi 命令會(huì)被立即執(zhí)行
其他命令不會(huì)立即執(zhí)行，而是將命令放入到一個(gè)事務(wù)隊(duì)列，然后向客戶端返回 QUEUED 回復(fù)。

3）事務(wù)執(zhí)行：當(dāng)一個(gè)處于事務(wù)狀態(tài)的客戶端向服務(wù)器發(fā)送 exec 命令時(shí)，服務(wù)器會(huì)遍歷事務(wù)隊(duì)列，執(zhí)行隊(duì)列中的所有命令，最后將結(jié)果全部返回給客戶端。

不過 redis 的事務(wù)并不推薦在實(shí)際中使用，如果要使用事務(wù)，推薦使用 Lua 腳本，redis 會(huì)保證一個(gè) Lua 腳本里的所有命令的原子性。

8、Redis 的 Java 客戶端有哪些？官方推薦哪個(gè)？

Redis 官網(wǎng)展示的 Java 客戶端如下圖所示，其中官方推薦的是標(biāo)星的3個(gè)：Jedis、Redisson 和 lettuce。

9、Redis 里面有1億個(gè) key，其中有 10 個(gè) key 是包含 java，如何將它們?nèi)空页鰜恚?/h2>
1）keys java 命令，該命令性能很好，但是在數(shù)據(jù)量特別大的時(shí)候會(huì)有性能問題

2）scan 0 MATCH java 命令，基于游標(biāo)的迭代器，更好的選擇

SCAN 命令是一個(gè)基于游標(biāo)的迭代器（cursor based iterator）： SCAN 命令每次被調(diào)用之后，都會(huì)向用戶返回一個(gè)新的游標(biāo)，用戶在下次迭代時(shí)需要使用這個(gè)新游標(biāo)作為 SCAN 命令的游標(biāo)參數(shù)，以此來延續(xù)之前的迭代過程。

當(dāng) SCAN 命令的游標(biāo)參數(shù)被設(shè)置為 0 時(shí)，服務(wù)器將開始一次新的迭代，而當(dāng)服務(wù)器向用戶返回值為 0 的游標(biāo)時(shí)，表示迭代已結(jié)束。

10、使用過 Redis 做消息隊(duì)列么？

Redis 本身提供了一些組件來實(shí)現(xiàn)消息隊(duì)列的功能，但是多多少少都存在一些缺點(diǎn)，相比于市面上成熟的消息隊(duì)列，例如 Kafka、Rocket MQ 來說并沒有優(yōu)勢(shì)，因此目前我們并沒有使用 Redis 來做消息隊(duì)列。

關(guān)于 Redis 做消息隊(duì)列的常見方案主要有以下：

1）Redis 5.0 之前可以使用 List（blocking）、Pub/Sub 等來實(shí)現(xiàn)輕量級(jí)的消息發(fā)布訂閱功能組件，但是這兩種實(shí)現(xiàn)方式都有很明顯的缺點(diǎn)，兩者中相對(duì)完善的 Pub/Sub 的主要缺點(diǎn)就是消息無法持久化，如果出現(xiàn)網(wǎng)絡(luò)斷開、Redis 宕機(jī)等，消息就會(huì)被丟棄。

2）為了解決 Pub/Sub 模式等的缺點(diǎn)，Redis 在 5.0 引入了全新的 Stream，Stream 借鑒了很多 Kafka 的設(shè)計(jì)思想，有以下幾個(gè)特點(diǎn)：

提供了消息的持久化和主備復(fù)制功能，可以讓任何客戶端訪問任何時(shí)刻的數(shù)據(jù)，并且能記住每一個(gè)客戶端的訪問位置，還能保證消息不丟失。
引入了消費(fèi)者組的概念，不同組接收到的數(shù)據(jù)完全一樣（前提是條件一樣），但是組內(nèi)的消費(fèi)者則是競(jìng)爭(zhēng)關(guān)系。

Redis Stream 相比于 pub/sub 已經(jīng)有很明顯的改善，但是相比于 Kafka，其實(shí)沒有優(yōu)勢(shì)，同時(shí)存在：尚未經(jīng)過大量驗(yàn)證、成本較高、不支持分區(qū)（partition）、無法支持大規(guī)模數(shù)據(jù)等問題。

11、Redis 和 Memcached 的比較

1）數(shù)據(jù)結(jié)構(gòu)：memcached 支持簡(jiǎn)單的 key-value 數(shù)據(jù)結(jié)構(gòu)，而 redis 支持豐富的數(shù)據(jù)結(jié)構(gòu)：String、List、Set、Hash、SortedSet 等。

2）數(shù)據(jù)存儲(chǔ)：memcached 和 redis 的數(shù)據(jù)都是全部在內(nèi)存中。

網(wǎng)上有一種說法 “當(dāng)物理內(nèi)存用完時(shí)，Redis可以將一些很久沒用到的 value 交換到磁盤，同時(shí)在內(nèi)存中清除”，這邊指的是 redis 里的虛擬內(nèi)存（Virtual Memory）功能，該功能在 Redis 2.0 被引入，但是在 Redis 2.4 中被默認(rèn)關(guān)閉，并標(biāo)記為廢棄，而在后續(xù)版中被完全移除。

3）持久化：memcached 不支持持久化，redis 支持將數(shù)據(jù)持久化到磁盤

4）災(zāi)難恢復(fù)：實(shí)例掛掉后，memcached 數(shù)據(jù)不可恢復(fù)，redis 可通過 RDB、AOF 恢復(fù)，但是還是會(huì)有數(shù)據(jù)丟失問題

5）事件庫：memcached 使用 Libevent 事件庫，redis 自己封裝了簡(jiǎn)易事件庫 AeEvent

6）過期鍵刪除策略：memcached 使用惰性刪除，redis 使用惰性刪除+定期刪除

7）內(nèi)存驅(qū)逐（淘汰）策略：memcached 主要為 LRU 算法，redis 當(dāng)前支持8種淘汰策略，見本文第16題

8）性能比較

按“CPU 單核” 維度比較：由于 Redis 只使用單核，而 Memcached 可以使用多核，所以在比較上：在處理小數(shù)據(jù)時(shí)，平均每一個(gè)核上 Redis 比 Memcached 性能更高，而在 100k 左右的大數(shù)據(jù)時(shí)， Memcached 性能要高于 Redis。
按“實(shí)例”維度進(jìn)行比較：由于 Memcached 多線程的特性，在 Redis 6.0 之前，通常情況下 Memcached 性能是要高于 Redis 的，同時(shí)實(shí)例的 CPU 核數(shù)越多，Memcached 的性能優(yōu)勢(shì)越大。
至于網(wǎng)上說的 redis 的性能比 memcached 快很多，這個(gè)說法就離譜。