關(guān)于redis緩存的面試題有哪些

這篇文章將為大家詳細講解有關(guān)關(guān)于redis緩存的面試題有哪些，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

redis緩存的面試題

1、redis和memcached什么區(qū)別？為什么高并發(fā)下有時單線程的redis比多線程的memcached效率要高？

區(qū)別：

1. memcached可緩存圖片和視頻。redis支持除k/v更多的數(shù)據(jù)結(jié)構(gòu)；

2. redis可以使用虛擬內(nèi)存，redis可持久化和aof災(zāi)難恢復(fù)，redis通過主從支持數(shù)據(jù)備份；

3.redis可以做消息隊列。

原因：memcached多線程模型引入了緩存一致性和鎖，加鎖帶來了性能損耗。

2、redis主從復(fù)制如何實現(xiàn)的？redis的集群模式如何實現(xiàn)？redis的key是如何尋址的？

主從復(fù)制實現(xiàn)：主節(jié)點將自己內(nèi)存中的數(shù)據(jù)做一份快照，將快照發(fā)給從節(jié)點，從節(jié)點將數(shù)據(jù)恢復(fù)到內(nèi)存中。之后再每次增加新數(shù)據(jù)的時候，主節(jié)點以類似于mysql的二進制日志方式將語句發(fā)送給從節(jié)點，從節(jié)點拿到主節(jié)點發(fā)送過來的語句進行重放。

分片方式：

• 客戶端分片

• 基于代理的分片

• Twemproxy

• codis

• 路由查詢分片

• Redis-cluster體身提供了自動將數(shù)據(jù)分散到RedisCluster不同節(jié)點的能力，整個數(shù)據(jù)集合的某個數(shù)據(jù)子集存儲在哪個節(jié)點對于用戶來說是透明的）

• redis-cluster分片原理：Cluster中有一個16384長度的槽（虛擬槽），編號分別為0-16383。每個Master節(jié)點都會負責(zé)一部分的槽，當有某個key被映射到某個Master負責(zé)的槽，那么這個Master負責(zé)為這個key提供服務(wù)，至于哪個Master節(jié)點負責(zé)哪個槽，可以由用戶指定，也可以在初始化的時候自動生成，只有Master才擁有槽的所有權(quán)。Master節(jié)點維護著一個16384/8字節(jié)的位序列，Master節(jié)點用bit來標識對于某個槽自己是否擁有。比如對于編號為1的槽，Master只要判斷序列的第二位（索引從0開始）是不是為1即可。這種結(jié)構(gòu)很容易添加或者刪除節(jié)點。比如如果我想新添加個節(jié)點D，我需要從節(jié)點A、B、C中得部分槽到D上。

【相關(guān)推薦：Redis視頻教程】

3、使用redis如何設(shè)計分布式鎖？說一下實現(xiàn)思路？使用zk可以嗎？如何實現(xiàn)？這兩種有什么區(qū)別？

redis：

• 線程Asetnx（上鎖的對象超時時的時間戳tl），如果返回true，獲得鎖。

• 線程B用get獲取t1，與當前時間戳比較，判斷是是否超時，沒超時false，若超時執(zhí)行第3步；

• 計算新的超時時間t2，使用getset命令返回t3（該值可能其他線程已經(jīng)修改過），如果t1==t3，獲得鎖，如果t1!=t3說明鎖被其他線程獲取了。

• 獲取鎖后，處理完業(yè)務(wù)邏輯，再去判斷鎖是否超時，如果沒超時刪除鎖，如果已超時，不用處理（防止刪除其他線程的鎖）。

zk：

• 客戶端對某個方法加鎖時，在zk上的與該方法對應(yīng)的指定節(jié)點的目錄下，生成一個唯一的瞬時有序節(jié)點node1；

• 客戶端獲取該路徑下所有已經(jīng)創(chuàng)建的子節(jié)點，如果發(fā)現(xiàn)自己創(chuàng)建的node1的序號是最小的，就認為這個客戶端獲得了鎖。

• 如果發(fā)現(xiàn)node1不是最小的，則監(jiān)聽比自己創(chuàng)建節(jié)點序號小的最大的節(jié)點，進入等待。

• 獲取鎖后，處理完邏輯，刪除自己創(chuàng)建的node1即可。區(qū)別：zk性能差一些，開銷大，實現(xiàn)簡單。

4、知道redis的持久化嗎？底層如何實現(xiàn)的？有什么優(yōu)點缺點？

RDB（RedisDataBase：在不同的時間點將redis的數(shù)據(jù)生成的快照同步到磁盤等介質(zhì)上）：內(nèi)存到硬盤的快照，定期更新。缺點：耗時，耗性能（fork+io操作），易丟失數(shù)據(jù)。

AOF（AppendOnlyFile：將redis所執(zhí)行過的所有指令都記錄下來，在下次redis重啟時，只需要執(zhí)行指令就可以了）：寫日志。缺點：體積大，恢復(fù)速度慢。

bgsave做鏡像全量持久化，aof做增量持久化。因為bgsave會消耗比較長的時間，不夠?qū)崟r，在停機的時候會導(dǎo)致大量的數(shù)據(jù)丟失，需要aof來配合，在redis實例重啟時，優(yōu)先使用aof來恢復(fù)內(nèi)存的狀態(tài)，如果沒有aof日志，就會使用rdb文件來恢復(fù)。Redis會定期做aof重寫，壓縮aof文件日志大小。Redis4.0之后有了混合持久化的功能，將bgsave的全量和aof的增量做了融合處理，這樣既保證了恢復(fù)的效率又兼顧了數(shù)據(jù)的安全性。bgsave的原理，fork和cow，fork是指redis通過創(chuàng)建子進程來進行bgsave操作，cow指的是copyonwrite，子進程創(chuàng)建后，父子進程共享數(shù)據(jù)段，父進程繼續(xù)提供讀寫服務(wù)，寫臟的頁面數(shù)據(jù)會逐漸和子進程分囲開來。

5、redis過期策略都有哪些？LRU算法知道嗎？寫一下java代碼實現(xiàn)？

過期策略：

定時過期（一key一定時器），惰性過期：只有使用key時才判斷key是否已過期，過期則清除。定期過期：前兩者折中。

LRU：newLinkedHashMap<K，V>（capacity，DEFAULT_LOAD_FACTORY，true）；第三個參數(shù)置為true，代表linkedlist按訪問順序排序，可作為LRU緩存；設(shè)為false代表按插入順序排序，可作為FIFO緩存

LRU算法實現(xiàn)：

• 通過雙向鏈表來實現(xiàn)，新數(shù)據(jù)插入到鏈表頭部；

• 每當緩存命中（即緩存數(shù)據(jù)被訪問），則將數(shù)據(jù)移到鏈表頭部；

• 當鏈表滿的時候，將鏈表尾部的數(shù)據(jù)丟棄。

LinkedHashMap：HashMap和雙向鏈表合二為一即是LinkedHashMap。HashMap是無序的，LinkedHashMap通過維護一個額外的雙向鏈表保證了迭代順序。該迭代順序可以是插入順序（默認），也可以是訪問順序。

6、緩存穿透、緩存擊穿、緩存雪崩解決方案？

**緩存穿透：**指查詢一個一定不存在的數(shù)據(jù)，如果從存儲層查不到數(shù)據(jù)則不寫入緩存，這將導(dǎo)致這個不存在的數(shù)據(jù)每次請求都要到DB去查詢，可能導(dǎo)致DB掛掉。

解決方案：

• 查詢返回的數(shù)據(jù)為空，仍把這個空結(jié)果進行緩存，但過期時間會比較短；

• 布隆過濾器：將所有可能存在的數(shù)據(jù)哈希到一個足夠大的bitmap中，一個一定不存在的數(shù)據(jù)會被這個bitmap攔截掉，從而避免了對DB的查詢。

**緩存擊穿：**對于設(shè)置了過期時間的key，緩存在某個時間點過期的時候，恰好這時間點對這個Key有大量的并發(fā)請求過來，這些請求發(fā)現(xiàn)緩存過期一般都會從后端DB加載數(shù)據(jù)并回設(shè)到緩存，這個時候大并發(fā)的請求可能會瞬間把DB壓垮。

解決方案：

• 使用互斥鎖：當緩存失效時，不立即去Ioaddb，先使用如Redis的setnx去設(shè)置一個互斥鎖，當操作成功返回時再進行Ioaddb的操作并回設(shè)緩存，否則重試get緩存的方法。

• 永遠不過期：物理不過期，但邏輯過期（后臺異步線程去刷新）。緩存雪崩：設(shè)置緩存時采用了相同的過期時間，導(dǎo)致緩存在某一時刻同時失效，請求全部轉(zhuǎn)發(fā)到DB，DB瞬時壓力過重雪崩。與緩存擊穿的區(qū)別：雪崩是很多key，擊穿是某一個key緩存。

解決方案：

將緩存失效時間分散開，比如可以在原有的失效時間基礎(chǔ)上增加一個隨機值，比如1-5分鐘隨機，這樣每一個緩存的過期時間的重復(fù)率就會降低，就很難引發(fā)集體失效的事件。

7、在選擇緩存時，什么時候選擇redis，什么時候選擇memcached

選擇redis的情況：

• 復(fù)雜數(shù)據(jù)結(jié)構(gòu)，value的數(shù)據(jù)是哈希，列表，集合，有序集合等這種情況下，會選擇redis，因為memcache無法滿足這些數(shù)據(jù)結(jié)構(gòu)，最典型的的使用場景是，用戶訂單列表，用戶消息，帖子評論等。

• 需要進行數(shù)據(jù)的持久化功能，但是注意，不要把redis當成數(shù)據(jù)庫使用，如果redis掛了，內(nèi)存能夠快速恢復(fù)熱數(shù)據(jù)，不會將壓力瞬間壓在數(shù)據(jù)庫上，沒有cache預(yù)熱的過程。對于只讀和數(shù)據(jù)一致性要求不高的場景可以采用持久化存儲

• 高可用，redis支持集群，可以實現(xiàn)主動復(fù)制，讀寫分離，而對于memcache如果想要實現(xiàn)高可用，需要進行二次開發(fā)。

• 存儲的內(nèi)容比較大，memcache存儲的value最大為1M。

選擇memcache的場景：

純KV，數(shù)據(jù)量非常大的業(yè)務(wù)，使用memcache更合適，原因是：

• memcache的內(nèi)存分配采用的是預(yù)分配內(nèi)存池的管理方式，能夠省去內(nèi)存分配的時間，redis是臨時申請空間，可能導(dǎo)致碎片化。

• 虛擬內(nèi)存使用，memcache將所有的數(shù)據(jù)存儲在物理內(nèi)存里，redis有自己的vm機制，理論上能夠存儲比物理內(nèi)存更多的數(shù)據(jù)，當數(shù)據(jù)超量時，引發(fā)swap，把冷數(shù)據(jù)刷新到磁盤上，從這點上，數(shù)據(jù)量大時，memcache更快

• 網(wǎng)絡(luò)模型，memcache使用非阻塞的10復(fù)用模型，redis也是使用非阻塞的I。復(fù)用模型，但是redis還提供了一些非KV存儲之外的排序，聚合功能，復(fù)雜的CPU計算，會阻塞整個I0調(diào)度，從這點上由于redis提供的功能較多，memcache更快些

• 線程模型，memcache使用多線程，主線程監(jiān)聽，worker子線程接受請求，執(zhí)行讀寫，這個過程可能存在鎖沖突。redis使用的單線程，雖然無鎖沖突，但是難以利用多核的特性提升吞吐量。

8、緩存與數(shù)據(jù)庫不一致怎么辦？

假設(shè)采用的主存分離，讀寫分離的數(shù)據(jù)庫，
如果一個線程A先刪除緩存數(shù)據(jù)，然后將數(shù)據(jù)寫入到主庫當中，這個時候，主庫和從庫同步?jīng)]有完成，線程B從緩存當中讀取數(shù)據(jù)失敗，從從庫當中讀取到舊數(shù)據(jù)，然后更新至緩存，這個時候，緩存當中的就是舊的數(shù)據(jù)。

發(fā)生上述不一致的原因在于，主從庫數(shù)據(jù)不一致問題，加入了緩存之后，主從不一致的時間被拉長了。

處理思路：在從庫有數(shù)據(jù)更新之后，將緩存當中的數(shù)據(jù)也同時進行更新，即當從庫發(fā)生了數(shù)據(jù)更新之后，向緩存發(fā)出刪除，淘汰這段時間寫入的舊數(shù)據(jù)。

9、主從數(shù)據(jù)庫不一致如何解決？

場景描述，對于主從庫，讀寫分離，如果主從庫更新同步有時差，就會導(dǎo)致主從庫數(shù)據(jù)的不一致

• 忽略這個數(shù)據(jù)不一致，在數(shù)據(jù)一致性要求不高的業(yè)務(wù)下，未必需要時時一致性

• 強制讀主庫，使用一個高可用的主庫，數(shù)據(jù)庫讀寫都在主庫，添加一個緩存，提升數(shù)據(jù)讀取的性能。

• 選擇性讀主庫，添加一個緩存，用來記錄必須讀主庫的數(shù)據(jù)，將哪個庫，哪個表，哪個主鍵，作為緩存的key，設(shè)置緩存失效的時間為主從庫同步的時間，如果緩存當中有這個數(shù)據(jù)，直接讀取主庫，如果緩存當中沒有這個主鍵，就到對應(yīng)的從庫中讀取。

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

• master最好不要做持久化工作，如RDB內(nèi)存快照和AOF日志文件

• 如果數(shù)據(jù)比較重要，某個slave開啟AOF備份，策略設(shè)置成每秒同步一次

• 為了主從復(fù)制的速度和連接的穩(wěn)定性，master和Slave最好在一個局域網(wǎng)內(nèi)

• 盡量避免在壓力大得主庫上增加從庫

• 主從復(fù)制不要米用網(wǎng)狀結(jié)構(gòu)，盡量是線性結(jié)構(gòu)，Master<–Slave1<—Slave2…

11、Redis的數(shù)據(jù)淘汰策略有哪些

voltile-lru從已經(jīng)設(shè)置過期時間的數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰

voltile-ttl從已經(jīng)設(shè)置過期時間的數(shù)據(jù)庫集當中挑選將要過期的數(shù)據(jù)

voltile-random從已經(jīng)設(shè)置過期時間的數(shù)據(jù)集任意選擇淘汰數(shù)據(jù)

allkeys-lru從數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰

allkeys-random從數(shù)據(jù)集中任意選擇淘汰的數(shù)據(jù)

no-eviction禁止驅(qū)逐數(shù)據(jù)

12、Redis當中有哪些數(shù)據(jù)結(jié)構(gòu)

字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。如果是咼級用戶，那么還會有，如果你是Redis中高級用戶，還需要加上下面幾種數(shù)據(jù)結(jié)構(gòu)HyperLogLog、Geo、Pub/Sub。

13、假如Redis里面有1億個key，其中有10w個key是以某個固定的已知的前綴開頭的，如果將它們?nèi)空页鰜恚?/strong>

使用keys指令可以掃出指定模式的key列表。

對方接著追問：如果這個redis正在給線上的業(yè)務(wù)提供服務(wù)，那使用keys指令會有什么問題？

這個時候你要回答redis關(guān)鍵的一個特性：redis的單線程的。keys指令會導(dǎo)致線程阻塞一段時間，線上服務(wù)會停頓，直到指令執(zhí)行完畢，服務(wù)才能恢復(fù)。這個時候可以使用scan指令，scan指令可以無阻塞的提取出指定模式的key列表，但是會有一定的重復(fù)概率，在客戶端做一次去重就可以了，但是整體所花費的時間會比直接用keys指令長。

14、使用Redis做過異步隊列嗎，是如何實現(xiàn)的

使用list類型保存數(shù)據(jù)信息，rpush生產(chǎn)消息，lpop消費消息，當lpop沒有消息時，可以sleep一段時間，然后再檢查有沒有信息，如果不想sleep的話，可以使用blpop，在沒有信息的時候，會一直阻塞，直到信息的到來。redis可以通過pub/sub主題訂閱模式實現(xiàn)一個生產(chǎn)者，多個消費者，當然也存在一定的缺點，當消費者下線時，生產(chǎn)的消息會丟失。

15、Redis如何實現(xiàn)延時隊列

使用sortedset，使用時間戳做score，消息內(nèi)容作為key，調(diào)用zadd來生產(chǎn)消息，消費者使用zrangbyscore獲取n秒之前的數(shù)據(jù)做輪詢處理。

16、什么是Redis？簡述它的優(yōu)缺點？

Redis本質(zhì)上是一個Key-Value類型的內(nèi)存數(shù)據(jù)庫，很像memcached，整個數(shù)據(jù)庫統(tǒng)統(tǒng)加載在內(nèi)存當中進行操作，定期通過異步操作把數(shù)據(jù)庫數(shù)據(jù)flush到硬盤上進行保存。

因為是純內(nèi)存操作，Redis的性能非常出色，每秒可以處理超過10萬次讀寫操作，是已知性能最快的Key-ValueDB。

Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存多種數(shù)據(jù)
結(jié)構(gòu)，此外單個value的最大限制是1GB，不像memcached只能保存1MB的數(shù)據(jù)，因此Redis可以用來實現(xiàn)很多有用的功能。

比方說用他的List來做FIFO雙向鏈表，實現(xiàn)一個輕量級的高性能消息隊列服務(wù)，用他的Set可以做高性能的tag系統(tǒng)等等。

另外Redis也可以對存入的Key-Value設(shè)置expire時間，因此也可以被當作一個功能加強版的memcached來用。Redis的主要缺點是數(shù)據(jù)庫容量受到物理內(nèi)存的限制，不能用作海量數(shù)據(jù)的高性能讀寫，因此Redis適合的場景主要局限在較小數(shù)據(jù)量的高性能操作和運算上。

17、Redis相比memcached有哪些優(yōu)勢？

• memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富數(shù)據(jù)類型

• Redis的速度比memcached快很多

• redis可以持久化其數(shù)據(jù)

18、Redis支持哪幾種數(shù)據(jù)類型？

String、List、Set、SortedSet、hashes

19、Redis主要消耗什么物理資源？

內(nèi)存。

20、Redis的全稱是什么？

Remote Dictionary Server

21、Redis有哪幾種數(shù)據(jù)淘汰策略？

noeviction：返回錯誤當內(nèi)存限制達到并且客戶端嘗試執(zhí)行會讓更多內(nèi)存被使用的命令(大部分的寫入指令，但DEL和幾個例外)

allkeys-lru：嘗試回收最少使用的鍵(LRU)，使得新添加的數(shù)據(jù)有空間存放。

volatile-lru：嘗試回收最少使用的鍵(LRU)，但僅限于在過期集合的鍵，使得新添加的數(shù)據(jù)有空間存放。

allkeys-random：回收隨機的鍵使得新添加的數(shù)據(jù)有空間存放。

volatile-random：回收隨機的鍵使得新添加的數(shù)據(jù)有空間存放，但僅限于在過期集合的鍵。

volatile-ttl：回收在過期集合的鍵，并且優(yōu)先回收存活時間(TTL)較短的鍵，使得新添加的數(shù)據(jù)有空間存放。

22、Redis官方為什么不提供Windows版本？

因為目前Linux版本已經(jīng)相當穩(wěn)定，而且用戶量很大，無需開發(fā)windows版本，反而會帶來兼容性等問題。

23、一個字符串類型的值能存儲最大容量是多少？

512M

24、為什么Redis需要把所有數(shù)據(jù)放到內(nèi)存中？

Redis為了達到最快的讀寫速度將數(shù)據(jù)都讀到內(nèi)存中，并通過異步的方式將數(shù)據(jù)寫入磁盤。

所以redis具有快速和數(shù)據(jù)持久化的特征。如果不將數(shù)據(jù)放在內(nèi)存中，磁盤I/O速度為嚴重影響redis的性能。

在內(nèi)存越來越便宜的今天，redis將會越來越受歡迎。如果設(shè)置了最大使用的內(nèi)存，則數(shù)據(jù)已有記錄數(shù)達到內(nèi)存限值后不能繼續(xù)插入新值。

25、Redis集群方案應(yīng)該怎么做？都有哪些方案？

• codis。
  目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在節(jié)點數(shù)量改變情況下，舊節(jié)點數(shù)據(jù)可恢復(fù)到新hash節(jié)點。

• rediscluster3.0自帶的集群，特點在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自身支持節(jié)點設(shè)置從節(jié)點。具體看官方文檔介紹。

• 在業(yè)務(wù)代碼層實現(xiàn)，起幾個毫無關(guān)聯(lián)的redis實例，在代碼層，對key進行hash計算，然后去對應(yīng)的redis實例操作數(shù)據(jù)。這種方式對hash層代碼要求比較高，考慮部分包括，節(jié)點失效后的替代算法方案，數(shù)據(jù)震蕩后的自動腳本恢復(fù)，實例的監(jiān)控，等等。

26、Redis集群方案什么情況下會導(dǎo)致整個集群不可用？

有A，B，C三個節(jié)點的集群，在沒有復(fù)制模型的情況下，如果節(jié)點B失敗了，那么整個集群就會以為缺少5501-11000這個范圍的槽而不可用。

27、MySQL里有2000w數(shù)據(jù)，redis中只存20w的數(shù)據(jù)，如何保證redis中的數(shù)據(jù)都是熱點數(shù)據(jù)？

redis內(nèi)存數(shù)據(jù)集大小上升到一定大小的時候，就會施行數(shù)據(jù)淘汰策略。

28、Redis有哪些適合的場景？

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

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

• 全頁緩存(FPC)
  除基本的會話token之外，Redis還提供很簡便的FPC平臺。回到一致性問題，即使重啟了Redis實例，因為有磁盤的持久化，用戶也不會看到頁面加載速度的下降，這是一個極大改進，類似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中搜索"Redisqueues"，你馬上就能找到大量的開源項目，這些項目的目的就是利用Redis創(chuàng)建非常好的后端工具，以滿足各種隊列需求。例如，Celery有一個后臺就是使用Redis作為broker，你可以從這里去查看。

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

• 當然，這是假定你是根據(jù)你用戶的分數(shù)做遞增的排序。如果你想返回用戶及用戶的分數(shù)，你需要這樣執(zhí)行：
  ZRANGEuser_scores010WITHSCORES
  AgoraGames就是一個很好的例子，用Ruby實現(xiàn)的，它的排行榜就是使用Redis來存儲數(shù)據(jù)的，你可以在這里看到。

• 發(fā)布/訂閱
  最后(但肯定不是最不重要的)是Redis的發(fā)布/訂閱功能。發(fā)布/訂閱的使用場景確實非常多。我已看見人們在社交網(wǎng)絡(luò)連接中使用，還可作為基于發(fā)布/訂閱的腳本觸發(fā)器，甚至用Redis的發(fā)布/訂閱功能來建立聊天系統(tǒng)！

29、Redis支持的Java客戶端都有哪些？官方推薦用哪個？

Redisson、Jedis、lettuce等等，官方推薦使用Redisson。

30、Redis和Redisson有什么關(guān)系？

Redisson是一個高級的分布式協(xié)調(diào)Redis客服端，能幫助用戶在分布式環(huán)境中輕松實現(xiàn)一些Java的對象(Bloomfilter，BitSet，Set，SetMultimap，ScoredSortedSet，SortedSet，Map，ConcurrentMap，List，ListMultimap，Queue，BlockingQueue，Deque，BlockingDeque，Semaphore，Lock，ReadWriteLock，AtomicLong，CountDownLatch，Publish/Subscribe，HyperLogLog)。

31、Jedis與Redisson對比有什么優(yōu)缺點？

Jedis是Redis的Java實現(xiàn)的客戶端，其API提供了比較全面的Redis命令的支持；
Redisson實現(xiàn)了分布式和可擴展的Java數(shù)據(jù)結(jié)構(gòu)，和Jedis相比，功能較為簡單，不支持字符串操作，不支持排序、事務(wù)、管道、分區(qū)等Redis特性。Redisson的宗旨是促進使用者對Redis的關(guān)注分離，從而讓使用者能夠?qū)⒕Ω械胤旁谔幚順I(yè)務(wù)邏輯上。

32、Redis如何設(shè)置密碼及驗證密碼？

設(shè)置密碼：config set require pass 123456 授權(quán)密碼：auth223456

33、說說Redis哈希槽的概念？

Redis集群沒有使用一致性hash，而是引入了哈希槽的概念，Redis集群有16384個哈希槽，每個key通過CRC16校驗后對16384取模來決定放置哪個槽，集群的每個節(jié)點負責(zé)一部分hash槽。

34、Redis集群的主從復(fù)制模型是怎樣的？

為了使在部分節(jié)點失敗或者大部分節(jié)點無法通信的情況下集群仍然可用，所以集群使用了主從復(fù)制模型，每個節(jié)點都會有N-1個復(fù)制品.

35、Redis集群會有寫操作丟失嗎？為什么？

Redis并不能保證數(shù)據(jù)的強一致性，這意味這在實際中集群在特定的條件下可能會丟失寫操作。

36、Redis集群之間是如何復(fù)制的？

異步復(fù)制

37、Redis集群最大節(jié)點個數(shù)是多少？

16384個。

38、Redis集群如何選擇數(shù)據(jù)庫？

Redis集群目前無法做數(shù)據(jù)庫選擇，默認在0數(shù)據(jù)庫。

39、怎么測試Redis的連通性？

ping

40、Redis中的管道有什么用？

一次請求/響應(yīng)服務(wù)器能實現(xiàn)處理新的請求即使舊的請求還未被響應(yīng)。這樣就可以將多個命令發(fā)送到服務(wù)器，而不用等待回復(fù)，最后在一個步驟中讀取該答復(fù)。

這就是管道(pipelining)，是一種幾十年來廣泛使用的技術(shù)。例如許多POP3協(xié)議已經(jīng)實現(xiàn)支持這個功能，大大加快了從服務(wù)器下載新郵件的過程。

41、怎么理解Redis事務(wù)？

事務(wù)是一個單獨的隔離操作：事務(wù)中的所有命令都會序列化、按順序地執(zhí)行。事務(wù)在執(zhí)行的過程中，不會被其他客戶端發(fā)送來的命令請求所打斷。事務(wù)是一個原子操作：事務(wù)中的命令要么全部被執(zhí)行，要么全部都不執(zhí)行。

42、Redis事務(wù)相關(guān)的命令有哪幾個？

MULTI、EXEC、DISCARD、WATCH

43、Rediskey的過期時間和永久有效分別怎么設(shè)置？

EXPIRE和PERSIST命令。

44、Redis如何做內(nèi)存優(yōu)化？

盡可能使用散列表(hashes)，散列表(是說散列表里面存儲的數(shù)少)使用的內(nèi)存非常小，所以你應(yīng)該盡可能的將你的數(shù)據(jù)模型抽象到一個散列表里面。比如你的web系統(tǒng)中有一個用戶對象，不要為這個用戶的名稱，姓氏，郵箱，密碼設(shè)置單獨的key，而是應(yīng)該把這個用戶的所有信息存儲到一張散列表里面。

45、Redis回收進程如何工作的？

一個客戶端運行了新的命令，添加了新的數(shù)據(jù)。
Redi檢查內(nèi)存使用情況，如果大于maxmemory的限制，則根據(jù)設(shè)定好的策略進行回收。一個新的命令被執(zhí)行，等等。

所以我們不斷地穿越內(nèi)存限制的邊界，通過不斷達到邊界然后不斷地回收回到邊界以下。

如果一個命令的結(jié)果導(dǎo)致大量內(nèi)存被使用(例如很大的集合的交集保存到一個新的鍵)，不用多久內(nèi)存限制就會被這個內(nèi)存使用量超越。

關(guān)于“關(guān)于redis緩存的面試題有哪些”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。