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

廣靈網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián)公司,廣靈網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為廣靈上千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務(wù)好的廣靈做網(wǎng)站的公司定做！

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

String（字符串）

格式: set key value

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

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

Hash（哈希）

格式: hmset name key1 value1 key2 value2

Redis hash 是一個鍵值(key=>value)對集合。

Redis hash是一個string類型的field和value的映射表，hash特別適合用于存儲對象。

List（列表）

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

格式: lpush name value

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

格式: rpush name value

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

格式: lrem name index

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

格式: llen name

返回 key 對應(yīng) list 的長度

Set（集合）

格式: sadd name value

Redis的Set是string類型的無序集合。

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

zset(sorted set：有序集合)

格式: zadd name score value

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

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

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

2、什么是Redis持久化？Redis有哪幾種持久化方式？優(yōu)缺點是什么？

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

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

RDB：

rdb是Redis DataBase縮寫

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

AOF:

Aof是Append-only file縮寫

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

aof寫入保存：

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

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

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

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

比較：

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

•  aof比rdb更安全也更大

•  rdb性能比aof好

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

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

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

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

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

For Errors the first byte of the reply is "-" 錯誤

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ù)組

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

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

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

單機(jī)版

特點：

簡單

問題：

•  內(nèi)存容量有限

•  處理能力有限

•  無法高可用。

主從復(fù)制

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

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

特點：

•  master/slave 角色

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

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

問題：

•  無法保證高可用

•  沒有解決 master 寫的壓力

哨兵

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

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

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

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

特點：

•  保證高可用

•  監(jiān)控各個節(jié)點

•  自動故障遷移

缺點：

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

•  沒有解決 master 寫的壓力

集群（proxy 型）

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

特點：

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

•  支持失敗節(jié)點自動刪除

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

缺點：

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

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

集群（直連型）：

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

特點：

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

•  數(shù)據(jù)按照 slot 存儲分布在多個節(jié)點，節(jié)點間數(shù)據(jù)共享，可動態(tài)調(diào)整數(shù)據(jù)分布。

•  可擴(kuò)展性，可線性擴(kuò)展到 1000 個節(jié)點，節(jié)點可動態(tài)添加或刪除。

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

缺點：

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

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

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

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

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

先拿setnx來爭搶鎖，搶到之后，再用expire給鎖加一個過期時間防止鎖忘記了釋放。

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

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

5、使用過Redis做異步隊列么，你是怎么用的？有什么缺點？

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

缺點：

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

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

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

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

緩存穿透

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

如何避免？

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

•  對一定不存在的key進(jìn)行過濾?？梢园阉械目赡艽嬖诘膋ey放到一個大的Bitmap中，查詢時通過該bitmap過濾。

緩存雪崩

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

如何避免？

•  在緩存失效后，通過加鎖或者隊列來控制讀數(shù)據(jù)庫寫緩存的線程數(shù)量。比如對某個key只允許一個線程查詢數(shù)據(jù)和寫緩存，其他線程等待。

•  做二級緩存，A1為原始緩存，A2為拷貝緩存，A1失效時，可以訪問A2，A1緩存失效時間設(shè)置為短期，A2設(shè)置為長期

•  不同的key，設(shè)置不同的過期時間，讓緩存失效的時間點盡量均勻。

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

Redis緩存雪崩、緩存擊穿、緩存穿透和常見的幾種緩存模式

7、Redis常用命令

管理命令

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

工具命令

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

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

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

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

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

10、Redis常見性能問題和解決方案：

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

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

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

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

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

Redis 性能問題分析（好文推薦）

11、Redis的并發(fā)競爭問題如何解決?

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

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

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

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

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

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

13、Redis最適合的場景

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

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

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

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

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

會話緩存（Session Cache）

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

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

全頁緩存（FPC）

除基本的會話token之外，Redis還提供很簡便的FPC平臺?；氐揭恢滦詥栴}，即使重啟了Redis實例，因為有磁盤的持久化，用戶也不會看到頁面加載速度的下降，這是一個極大改進(jìn)，類似PHP本地FPC。

再次以Magento為例，Magento提供一個插件來使用Redis作為全頁緩存后端。

此外，對WordPress的用戶來說，Pantheon有一個非常好的插件 wp-redis，這個插件能幫助你以最快速度加載你曾瀏覽過的頁面。

隊列

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

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

排行榜/計數(shù)器

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

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

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