共計(jì) 6818 個(gè)字符，預(yù)計(jì)需要花費(fèi) 18 分鐘才能閱讀完成。

本篇內(nèi)容主要講解“常見(jiàn) Redis 面試題有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓丸趣 TV 小編來(lái)帶大家學(xué)習(xí)“常見(jiàn) Redis 面試題有哪些”吧!

1、Redis 支持的數(shù)據(jù)類型？

String（字符串）

格式: set key value

string 類型是二進(jìn)制安全的。意思是 redis 的 string 可以包含任何數(shù)據(jù)。比如 jpg 圖片或者序列化的對(duì)象。

string 類型是 Redis 最基本的數(shù)據(jù)類型，一個(gè)鍵最大能存儲(chǔ) 512MB。

Hash（哈希）

格式: hmset name key1 value1 key2 value2

Redis hash 是一個(gè)鍵值 (key= value) 對(duì)集合。

Redis hash 是一個(gè) string 類型的 field 和 value 的映射表，hash 特別適合用于存儲(chǔ)對(duì)象。

List（列表）

Redis 列表是簡(jiǎn)單的字符串列表，按照插入順序排序。你可以添加一個(gè)元素到列表的頭部（左邊）或者尾部（右邊）

格式: lpush name value

在 key 對(duì)應(yīng) list 的頭部添加字符串元素

格式: rpush name value

在 key 對(duì)應(yīng) list 的尾部添加字符串元素

格式: lrem name index

key 對(duì)應(yīng) list 中刪除 count 個(gè)和 value 相同的元素

格式: llen name

返回 key 對(duì)應(yīng) list 的長(zhǎng)度

Set（集合）

格式: sadd name value

Redis 的 Set 是 string 類型的無(wú)序集合。

集合是通過(guò)哈希表實(shí)現(xiàn)的，所以添加，刪除，查找的復(fù)雜度都是 O(1)。

zset(sorted set：有序集合)

格式: zadd name score value

Redis zset 和 set 一樣也是 string 類型元素的集合, 且不允許重復(fù)的成員。

不同的是每個(gè)元素都會(huì)關(guān)聯(lián)一個(gè) double 類型的分?jǐn)?shù)。redis 正是通過(guò)分?jǐn)?shù)來(lái)為集合中的成員進(jìn)行從小到大的排序。

zset 的成員是唯一的, 但分?jǐn)?shù) (score) 卻可以重復(fù)。

2、什么是 Redis 持久化？Redis 有哪幾種持久化方式？?jī)?yōu)缺點(diǎn)是什么？

持久化就是把內(nèi)存的數(shù)據(jù)寫(xiě)到磁盤中去，防止服務(wù)宕機(jī)了內(nèi)存數(shù)據(jù)丟失。

Redis 提供了兩種持久化方式：RDB（默認(rèn)）和 AOF

RDB：

rdb 是 Redis DataBase 縮寫(xiě)

功能核心函數(shù) rdbSave(生成 RDB 文件)和 rdbLoad（從文件加載內(nèi)存）兩個(gè)函數(shù)

AOF:

Aof 是 Append-only file 縮寫(xiě)

每當(dāng)執(zhí)行服務(wù)器 (定時(shí)) 任務(wù)或者函數(shù)時(shí) flushAppendOnlyFile 函數(shù)都會(huì)被調(diào)用，這個(gè)函數(shù)執(zhí)行以下兩個(gè)工作

aof 寫(xiě)入保存：

 WRITE：根據(jù)條件，將 aof_buf 中的緩存寫(xiě)入到 AOF 文件

 SAVE：根據(jù)條件，調(diào)用 fsync 或 fdatasync 函數(shù)，將 AOF 文件保存到磁盤中。

存儲(chǔ)結(jié)構(gòu):

內(nèi)容是 redis 通訊協(xié)議 (RESP) 格式的命令文本存儲(chǔ)。

比較：

 aof 文件比 rdb 更新頻率高，優(yōu)先使用 aof 還原數(shù)據(jù)。

 aof 比 rdb 更安全也更大

 rdb 性能比 aof 好

  如果兩個(gè)都配了優(yōu)先加載 AOF

剛剛上面你有提到 redis 通訊協(xié)議(RESP)，能解釋下什么是 RESP？有什么特點(diǎn)？（可以看到很多面試其實(shí)都是連環(huán)炮，面試官其實(shí)在等著你回答到這個(gè)點(diǎn)，如果你答上了對(duì)你的評(píng)價(jià)就又加了一分）

RESP 是 redis 客戶端和服務(wù)端之前使用的一種通訊協(xié)議；

RESP 的特點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單、快速解析、可讀性好

For Simple Strings the first byte of the reply is + 回復(fù)

For Errors the first byte of the reply is – 錯(cuò)誤

For Integers the first byte of the reply is : 整數(shù)

For Bulk Strings the first byte of the reply is $ 字符串

For Arrays the first byte of the reply is * 數(shù)組

持久化在面試中問(wèn)到的頻率較高，重點(diǎn)學(xué)一下，篇幅有限，具體點(diǎn)下面的文章：

10 分鐘徹底理解 Redis 的持久化機(jī)制：RDB 和 AOF

3、Redis 有哪些架構(gòu)模式？講講各自的特點(diǎn)

單機(jī)版

特點(diǎn)：

簡(jiǎn)單

問(wèn)題：

  內(nèi)存容量有限

  處理能力有限

  無(wú)法高可用。

主從復(fù)制

Redis 的復(fù)制（replication）功能允許用戶根據(jù)一個(gè) Redis 服務(wù)器來(lái)創(chuàng)建任意多個(gè)該服務(wù)器的復(fù)制品，其中被復(fù)制的服務(wù)器為主服務(wù)器（master），而通過(guò)復(fù)制創(chuàng)建出來(lái)的服務(wù)器復(fù)制品則為從服務(wù)器（slave）。

只要主從服務(wù)器之間的網(wǎng)絡(luò)連接正常，主從服務(wù)器兩者會(huì)具有相同的數(shù)據(jù)，主服務(wù)器就會(huì)一直將發(fā)生在自己身上的數(shù)據(jù)更新同步 給從服務(wù)器，從而一直保證主從服務(wù)器的數(shù)據(jù)相同。

特點(diǎn)：

 master/slave 角色

 master/slave 數(shù)據(jù)相同

  降低 master 讀壓力在轉(zhuǎn)交從庫(kù)

問(wèn)題：

  無(wú)法保證高可用

  沒(méi)有解決 master 寫(xiě)的壓力

哨兵

Redis sentinel 是一個(gè)分布式系統(tǒng)中監(jiān)控 redis 主從服務(wù)器，并在主服務(wù)器下線時(shí)自動(dòng)進(jìn)行故障轉(zhuǎn)移。其中三個(gè)特性：

監(jiān)控（Monitoring）：Sentinel 會(huì)不斷地檢查你的主服務(wù)器和從服務(wù)器是否運(yùn)作正常。

  提醒（Notification）：當(dāng)被監(jiān)控的某個(gè) Redis 服務(wù)器出現(xiàn)問(wèn)題時(shí)，Sentinel 可以通過(guò) API 向管理員或者其他應(yīng)用程序發(fā)送通知。

  自動(dòng)故障遷移（Automatic failover）：當(dāng)一個(gè)主服務(wù)器不能正常工作時(shí)，Sentinel 會(huì)開(kāi)始一次自動(dòng)故障遷移操作。

特點(diǎn)：

  保證高可用

  監(jiān)控各個(gè)節(jié)點(diǎn)

  自動(dòng)故障遷移

缺點(diǎn)：

  主從模式，切換需要時(shí)間丟數(shù)據(jù)

  沒(méi)有解決 master 寫(xiě)的壓力

集群（proxy 型）

Twemproxy 是一個(gè) Twitter 開(kāi)源的一個(gè) redis 和 memcache 快速 / 輕量級(jí)代理服務(wù)器；Twemproxy 是一個(gè)快速的單線程代理程序，支持 Memcached ASCII 協(xié)議和 redis 協(xié)議。

特點(diǎn)：

  多種 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins

  支持失敗節(jié)點(diǎn)自動(dòng)刪除

  后端 Sharding 分片邏輯對(duì)業(yè)務(wù)透明，業(yè)務(wù)方的讀寫(xiě)方式和操作單個(gè) Redis 一致

缺點(diǎn)：

  增加了新的 proxy，需要維護(hù)其高可用。

 failover 邏輯需要自己實(shí)現(xiàn)，其本身不能支持故障的自動(dòng)轉(zhuǎn)移可擴(kuò)展性差，進(jìn)行擴(kuò)縮容都需要手動(dòng)干預(yù)

集群（直連型）：

從 redis 3.0 之后版本支持 redis-cluster 集群，Redis-Cluster 采用無(wú)中心結(jié)構(gòu)，每個(gè)節(jié)點(diǎn)保存數(shù)據(jù)和整個(gè)集群狀態(tài), 每個(gè)節(jié)點(diǎn)都和其他所有節(jié)點(diǎn)連接。

特點(diǎn)：

  無(wú)中心架構(gòu)（不存在哪個(gè)節(jié)點(diǎn)影響性能瓶頸），少了 proxy 層。

  數(shù)據(jù)按照 slot 存儲(chǔ)分布在多個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)間數(shù)據(jù)共享，可動(dòng)態(tài)調(diào)整數(shù)據(jù)分布。

  可擴(kuò)展性，可線性擴(kuò)展到 1000 個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)可動(dòng)態(tài)添加或刪除。

  高可用性，部分節(jié)點(diǎn)不可用時(shí)，集群仍可用。通過(guò)增加 Slave 做備份數(shù)據(jù)副本   - 實(shí)現(xiàn)故障自動(dòng) failover，節(jié)點(diǎn)之間通過(guò) gossip 協(xié)議交換狀態(tài)信息，用投票機(jī)制完成 Slave 到 Master 的角色提升。

缺點(diǎn)：

  資源隔離性較差，容易出現(xiàn)相互影響的情況。

  數(shù)據(jù)通過(guò)異步復(fù)制, 不保證數(shù)據(jù)的強(qiáng)一致性

高可用 Redis 架構(gòu)分析搭建，可以參考：

高可用 Redis 服務(wù)架構(gòu)分析與搭建

4、使用過(guò) Redis 分布式鎖么，它是怎么實(shí)現(xiàn)的？

先拿 setnx 來(lái)爭(zhēng)搶鎖，搶到之后，再用 expire 給鎖加一個(gè)過(guò)期時(shí)間防止鎖忘記了釋放。

如果在 setnx 之后執(zhí)行 expire 之前進(jìn)程意外 crash 或者要重啟維護(hù)了，那會(huì)怎么樣？

set 指令有非常復(fù)雜的參數(shù)，這個(gè)應(yīng)該是可以同時(shí)把 setnx 和 expire 合成一條指令來(lái)用的！

5、使用過(guò) Redis 做異步隊(duì)列么，你是怎么用的？有什么缺點(diǎn)？

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

缺點(diǎn)：

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

能不能生產(chǎn)一次消費(fèi)多次呢？

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

6、什么是緩存穿透？如何避免？什么是緩存雪崩？何如避免？

緩存穿透

一般的緩存系統(tǒng)，都是按照 key 去緩存查詢，如果不存在對(duì)應(yīng)的 value，就應(yīng)該去后端系統(tǒng)查找（比如 DB）。一些惡意的請(qǐng)求會(huì)故意查詢不存在的 key, 請(qǐng)求量很大，就會(huì)對(duì)后端系統(tǒng)造成很大的壓力。這就叫做緩存穿透。

如何避免？

對(duì)查詢結(jié)果為空的情況也進(jìn)行緩存，緩存時(shí)間設(shè)置短一點(diǎn)，或者該 key 對(duì)應(yīng)的數(shù)據(jù) insert 了之后清理緩存。

  對(duì)一定不存在的 key 進(jìn)行過(guò)濾。可以把所有的可能存在的 key 放到一個(gè)大的 Bitmap 中，查詢時(shí)通過(guò)該 bitmap 過(guò)濾。

緩存雪崩

當(dāng)緩存服務(wù)器重啟或者大量緩存集中在某一個(gè)時(shí)間段失效，這樣在失效的時(shí)候，會(huì)給后端系統(tǒng)帶來(lái)很大壓力。導(dǎo)致系統(tǒng)崩潰。

如何避免？

  在緩存失效后，通過(guò)加鎖或者隊(duì)列來(lái)控制讀數(shù)據(jù)庫(kù)寫(xiě)緩存的線程數(shù)量。比如對(duì)某個(gè) key 只允許一個(gè)線程查詢數(shù)據(jù)和寫(xiě)緩存，其他線程等待。

  做二級(jí)緩存，A1 為原始緩存，A2 為拷貝緩存，A1 失效時(shí)，可以訪問(wèn) A2，A1 緩存失效時(shí)間設(shè)置為短期，A2 設(shè)置為長(zhǎng)期

  不同的 key，設(shè)置不同的過(guò)期時(shí)間，讓緩存失效的時(shí)間點(diǎn)盡量均勻。

這道相當(dāng)常見(jiàn)，詳細(xì)再參考下文，一定熟練掌握：

Redis 緩存雪崩、緩存擊穿、緩存穿透和常見(jiàn)的幾種緩存模式

7、Redis 常用命令

管理命令

# dbsize  返回當(dāng)前數(shù)據(jù)庫(kù)  key  的數(shù)量。 # info  返回當(dāng)前  redis  服務(wù)器狀態(tài)和一些統(tǒng)計(jì)信息。 # monitor  實(shí)時(shí)監(jiān)聽(tīng)并返回 redis 服務(wù)器接收到的所有請(qǐng)求信息。 # shutdown  把數(shù)據(jù)同步保存到磁盤上，并關(guān)閉 redis 服務(wù)。 # config get parameter  獲取一個(gè)  redis  配置參數(shù)信息。（個(gè)別參數(shù)可能無(wú)法獲取） # config set parameter value  設(shè)置一個(gè)  redis  配置參數(shù)信息。（個(gè)別參數(shù)可能無(wú)法獲取） # config resetstat  重置  info  命令的統(tǒng)計(jì)信息。（重置包括：keyspace  命中數(shù)、 # keyspace  錯(cuò)誤數(shù)、  處理命令數(shù)，接收連接數(shù)、過(guò)期  key  數(shù)） # debug object key  獲取一個(gè)  key  的調(diào)試信息。 # debug segfault  制造一次服務(wù)器當(dāng)機(jī)。 # flushdb  刪除當(dāng)前數(shù)據(jù)庫(kù)中所有  key, 此方法不會(huì)失敗。小心慎用  # flushall  刪除全部數(shù)據(jù)庫(kù)中所有  key，此方法不會(huì)失敗。小心慎用

工具命令

#redis-server：Redis  服務(wù)器的  daemon  啟動(dòng)程序  #redis-cli：Redis  命令行操作工具。當(dāng)然，你也可以用  telnet  根據(jù)其純文本協(xié)議來(lái)操作  #redis-benchmark：Redis  性能測(cè)試工具，測(cè)試  Redis  在你的系統(tǒng)及你的配置下的讀寫(xiě)性能  $redis-benchmark -n 100000  ndash;c 50 # 模擬同時(shí)由  50  個(gè)客戶端發(fā)送  100000  個(gè)  SETs/GETs  查詢  #redis-check-aof：更新日志檢查  #redis-check-dump：本地?cái)?shù)據(jù)庫(kù)檢查

8.Redis 單例、主從模式、sentinel 以及集群的配置方式及優(yōu)缺點(diǎn)對(duì)比

Redis 單例、主從模式、sentinel 以及集群的配置方式及優(yōu)缺點(diǎn)對(duì)比

9、為什么 Redis 單線程卻能支撐高并發(fā)？

為什么 Redis 單線程卻能支撐高并發(fā)？

10、Redis 常見(jiàn)性能問(wèn)題和解決方案：

1).Master 寫(xiě)內(nèi)存快照，save 命令調(diào)度 rdbSave 函數(shù)，會(huì)阻塞主線程的工作，當(dāng)快照比較大時(shí)對(duì)性能影響是非常大的，會(huì)間斷性暫停服務(wù)，所以 Master 最好不要寫(xiě)內(nèi)存快照。

2).Master AOF 持久化，如果不重寫(xiě) AOF 文件，這個(gè)持久化方式對(duì)性能的影響是最小的，但是 AOF 文件會(huì)不斷增大，AOF 文件過(guò)大會(huì)影響 Master 重啟的恢復(fù)速度。Master 最好不要做任何持久化工作，包括內(nèi)存快照和 AOF 日志文件，特別是不要啟用內(nèi)存快照做持久化，如果數(shù)據(jù)比較關(guān)鍵，某個(gè) Slave 開(kāi)啟 AOF 備份數(shù)據(jù)，策略為每秒同步一次。

3).Master 調(diào)用 BGREWRITEAOF 重寫(xiě) AOF 文件，AOF 在重寫(xiě)的時(shí)候會(huì)占大量的 CPU 和內(nèi)存資源，導(dǎo)致服務(wù) load 過(guò)高，出現(xiàn)短暫服務(wù)暫停現(xiàn)象。

4).Redis 主從復(fù)制的性能問(wèn)題，為了主從復(fù)制的速度和連接的穩(wěn)定性，Slave 和 Master 最好在同一個(gè)局域網(wǎng)內(nèi)

Redis 性能分析相關(guān)問(wèn)題，限于篇幅，給出文章鏈接：

Redis 性能問(wèn)題分析（好文推薦）

11、Redis 的并發(fā)競(jìng)爭(zhēng)問(wèn)題如何解決?

Redis 為單進(jìn)程單線程模式，采用隊(duì)列模式將并發(fā)訪問(wèn)變?yōu)榇性L問(wèn)。Redis 本身沒(méi)有鎖的概念，Redis 對(duì)于多個(gè)客戶端連接并不存在競(jìng)爭(zhēng)，但是在 Jedis 客戶端對(duì) Redis 進(jìn)行并發(fā)訪問(wèn)時(shí)會(huì)發(fā)生連接超時(shí)、數(shù)據(jù)轉(zhuǎn)換錯(cuò)誤、阻塞、客戶端關(guān)閉連接等問(wèn)題，這些問(wèn)題均是由于客戶端連接混亂造成。對(duì)此有 2 種解決方法：

  客戶端角度，為保證每個(gè)客戶端間正常有序與 Redis 進(jìn)行通信，對(duì)連接進(jìn)行池化，同時(shí)對(duì)客戶端讀寫(xiě) Redis 操作采用內(nèi)部鎖 synchronized。

  服務(wù)器角度，利用 setnx 實(shí)現(xiàn)鎖。

注：對(duì)于第一種，需要應(yīng)用程序自己處理資源的同步，可以使用的方法比較通俗，可以使用 synchronized 也可以使用 lock；第二種需要用到 Redis 的 setnx 命令，但是需要注意一些問(wèn)題。

12、說(shuō)說(shuō) Redis 的內(nèi)存淘汰策略

直接點(diǎn)這里：Redis 的內(nèi)存淘汰策略

13、Redis 最適合的場(chǎng)景

Redis 最適合所有數(shù)據(jù) in-momory 的場(chǎng)景，雖然 Redis 也提供持久化功能，但實(shí)際更多的是一個(gè) disk-backed 的功能，跟傳統(tǒng)意義上的持久化有比較大的差別，那么可能大家就會(huì)有疑問(wèn)，似乎 Redis 更像一個(gè)加強(qiáng)版的 Memcached，那么何時(shí)使用 Memcached，何時(shí)使用 Redis 呢?

如果簡(jiǎn)單地比較 Redis 與 Memcached 的區(qū)別，大多數(shù)都會(huì)得到以下觀點(diǎn)：

 Redis 不僅僅支持簡(jiǎn)單的 k / v 類型的數(shù)據(jù)，同時(shí)還提供 list，set，zset，hash 等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。

 Redis 支持?jǐn)?shù)據(jù)的備份，即 master-slave 模式的數(shù)據(jù)備份。

 Redis 支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時(shí)候可以再次加載進(jìn)行使用。

會(huì)話緩存（Session Cache）

最常用的一種使用 Redis 的情景是會(huì)話緩存（session cache）。用 Redis 緩存會(huì)話比其他存儲(chǔ)（如 Memcached）的優(yōu)勢(shì)在于：Redis 提供持久化。當(dāng)維護(hù)一個(gè)不是嚴(yán)格要求一致性的緩存時(shí)，如果用戶的購(gòu)物車信息全部丟失，大部分人都會(huì)不高興的，現(xiàn)在，他們還會(huì)這樣嗎？

幸運(yùn)的是，隨著 Redis 這些年的改進(jìn)，很容易找到怎么恰當(dāng)?shù)氖褂?Redis 來(lái)緩存會(huì)話的文檔。甚至廣為人知的商業(yè)平臺(tái) Magento 也提供 Redis 的插件。

全頁(yè)緩存（FPC）

除基本的會(huì)話 token 之外，Redis 還提供很簡(jiǎn)便的 FPC 平臺(tái)。回到一致性問(wèn)題，即使重啟了 Redis 實(shí)例，因?yàn)橛写疟P的持久化，用戶也不會(huì)看到頁(yè)面加載速度的下降，這是一個(gè)極大改進(jìn)，類似 PHP 本地 FPC。

再次以 Magento 為例，Magento 提供一個(gè)插件來(lái)使用 Redis 作為全頁(yè)緩存后端。

此外，對(duì) WordPress 的用戶來(lái)說(shuō)，Pantheon 有一個(gè)非常好的插件 wp-redis，這個(gè)插件能幫助你以最快速度加載你曾瀏覽過(guò)的頁(yè)面。

隊(duì)列

Reids 在內(nèi)存存儲(chǔ)引擎領(lǐng)域的一大優(yōu)點(diǎn)是提供 list 和 set 操作，這使得 Redis 能作為一個(gè)很好的消息隊(duì)列平臺(tái)來(lái)使用。Redis 作為隊(duì)列使用的操作，就類似于本地程序語(yǔ)言（如 Python）對(duì) list 的 push/pop 操作。

如果你快速的在 Google 中搜索“Redis queues”，你馬上就能找到大量的開(kāi)源項(xiàng)目，這些項(xiàng)目的目的就是利用 Redis 創(chuàng)建非常好的后端工具，以滿足各種隊(duì)列需求。例如，Celery 有一個(gè)后臺(tái)就是使用 Redis 作為 broker，你可以從這里去查看。

排行榜 / 計(jì)數(shù)器

Redis 在內(nèi)存中對(duì)數(shù)字進(jìn)行遞增或遞減的操作實(shí)現(xiàn)的非常好。集合（Set）和有序集合（Sorted Set）也使得我們?cè)趫?zhí)行這些操作的時(shí)候變的非常簡(jiǎn)單，Redis 只是正好提供了這兩種數(shù)據(jù)結(jié)構(gòu)。所以，我們要從排序集合中獲取到排名最靠前的 10 個(gè)用戶 ndash; 我們稱之為“user_scores”。

當(dāng)然，這是假定你是根據(jù)你用戶的分?jǐn)?shù)做遞增的排序。如果你想返回用戶及用戶的分?jǐn)?shù)，你需要這樣執(zhí)行：ZRANGE user_scores 0 10 WITHSCORES

到此，相信大家對(duì)“常見(jiàn) Redis 面試題有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是丸趣 TV 網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！