Redis有哪些數(shù)據(jù)結(jié)構(gòu)？Redis 有 5 種基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，它們分別是：string(字符串)、list(列表)、hash(字典)、set(集 合) 和 zset(有序集

Redis有哪些數(shù)據(jù)結(jié)構(gòu)？

Redis 有 5 種基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，它們分別是：string(字符串)、list(列表)、hash(字典)、set(集 合) 和 zset(有序集合)。
這 5 種是 Redis 相關(guān)知識中最基礎(chǔ)、最重要的部分。

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

512M

單線程還是多線程？

Redis6.0采用多線程IO，不過命令的執(zhí)行還是單線程的。
Redis6.0之前，IO線程和執(zhí)行線程都是單線程的。

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

Redis 為了達(dá)到最快的讀寫速度將數(shù)據(jù)都讀到內(nèi)存中，并通過異步的方式將數(shù)據(jù)寫入磁盤。
所以 redis 具有快速和數(shù)據(jù)持久化的特征，如果不將數(shù)據(jù)放在內(nèi)存中，磁盤 I/O 速度為嚴(yán)重影 響 redis 的性能。
在內(nèi)存越來越便宜的今天，redis 將會越來越受歡迎， 如果設(shè)置了最大使用的內(nèi)存，則數(shù)據(jù)已 有記錄數(shù)達(dá)到內(nèi)存限值后不能繼續(xù)插入新值。

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

設(shè)置密碼：config set requirepass 123456
授權(quán)密碼：auth 123456

緩存失效？緩存穿透？緩存雪崩？緩存并發(fā)？

1. 緩存失效 緩存失效指的是大量的緩存在同一時間失效，到時DB的瞬間壓力飆升。造成這種現(xiàn)象的 原因是，key的過期時間都設(shè)置成一樣了。解決方案是，key的過期時間引入隨機因素， 比如5分鐘+隨機秒這種方式。
2. 緩存穿透 緩存穿透是指查詢一條數(shù)據(jù)庫和緩存都沒有的一條數(shù)據(jù)，就會一直查詢數(shù)據(jù)庫，對數(shù)據(jù) 庫的訪問壓力就會增大，緩存穿透的解決方案，有以下2種： 緩存空對象：代碼維護較簡單，但是效果不好。 布隆過濾器：代碼維護復(fù)雜，效果很好。
3. 緩存擊穿 熱點key在某個時間點過期的時候，而恰好在這個時間點對這個Key有大量的并發(fā)請求過來，從而大量的請求打到db。

緩存擊穿解決方案
解決緩存擊穿的方法也有兩種，

第一種是設(shè)置key永不過期；第二種是使用分布式鎖，保證同一時刻只能有一個查詢請求重新加載熱點數(shù)據(jù)到緩存中，這樣，其他的線程只需等待該線程運行完畢，即可重新從Redis中獲取數(shù)據(jù)。
第一種方式比較簡單，在設(shè)置熱點key的時候，不給key設(shè)置過期時間即可。不過還有另外一種方式也可以達(dá)到key不過期的目的，就是正常給key設(shè)置過期時間，不過在后臺同時啟一個定時任務(wù)去定時地更新這個緩存。

1. 緩存雪崩 緩存雪崩 是指在某一個時間段，緩存集中過期失效。此刻無數(shù)的請求直接繞開緩存，直 接請求數(shù)據(jù)庫。 造成緩存雪崩的原因，有以下2種： reids宕機。 大部分?jǐn)?shù)據(jù)失效。

對于緩存雪崩的解決方案有以下2種：
搭建高可用的集群，防止單機的redis宕機。
設(shè)置不同的過期時間，防止同意之間內(nèi)大量的key失效。

1. 緩存并發(fā) 有時候如果網(wǎng)站并發(fā)訪問高，一個緩存如果失效，可能出現(xiàn)多個進程同時查詢DB，同時 設(shè)置緩存的情況，如果并發(fā)確實很大，這也可能造成DB壓力過大，還有緩存頻繁更新的 問題。 一般處理方案是在查DB的時候進行加鎖，如果KEY不存在，就加鎖，然后查DB入緩存， 然后解鎖；其他進程如果發(fā)現(xiàn)有鎖就等待，然后等解鎖后再查緩存或者進入DB查詢。

Redis中的熱key怎么處理？

1、對熱key進行分散處理。比如：在key上加上不同的前后綴，緩存多個key，使得各個key分 散到不同的節(jié)點上。
2、采用多級緩存。

大key怎么處理？

大key指的是value特別大的key。比如很長的字符串，或者很大的set等等。 大key會造成2個問題：
1、數(shù)據(jù)傾斜，比如某些節(jié)點內(nèi)存占用過高。
2、當(dāng)刪除大key或者大 key自動過期的時候，會造成QPS突降，因為Redis是單線程的緣故。
處理方案：可以將一個大key進行分片處理，比如：將一個大set分成多個小的set。

統(tǒng)計網(wǎng)站的UV，應(yīng)該怎么做？

UV與PV不同，UV需要去重。一般有2種方案：
1、用BitMap。存的是用戶的uid，計算UV的時候，做下bitcount就行了。
2、用布隆過濾器。將每次訪問的用戶uid都放到布隆過濾器中。優(yōu)點是省內(nèi)存，缺點是無法得 到精確的UV。但是對于不需要精確知道具體UV，只需要大概的數(shù)量級的場景，是個不錯的選 擇。

事務(wù)機制了解過嗎？

Redis事務(wù)的概念：
Redis 事務(wù)的本質(zhì)是一組命令的集合。事務(wù)支持一次執(zhí)行多個命令，一個事務(wù)中所有命令都會 被序列化。在事務(wù)執(zhí)行過程，會按照順序串行化執(zhí)行隊列中的命令，其他客戶端提交的命令請 求不會插入到事務(wù)執(zhí)行命令序列中。
Redis事務(wù)就是一次性、順序性、排他性的執(zhí)行一個隊列中的一系列命令。
Redis事務(wù)沒有隔離級別的概念：
批量操作在發(fā)送 EXEC 命令前被放入隊列緩存，并不會被實際執(zhí)行，也就不存在事務(wù)內(nèi)的查詢 要看到事務(wù)里的更新，事務(wù)外查詢不能看到。
Redis不保證原子性：
Redis中，單條命令是原子性執(zhí)行的，但事務(wù)不保證原子性，且沒有回滾。事務(wù)中任意命令執(zhí) 行失敗，其余的命令仍會被執(zhí)行。
Redis事務(wù)的三個階段：
開始事務(wù)
命令入隊
執(zhí)行事務(wù)
Redis事務(wù)相關(guān)命令：
watch key1 key2 … : 監(jiān)視一或多個key,如果在事務(wù)執(zhí)行之前，被監(jiān)視的key被其他命令改動， 則事務(wù)被打斷 （ 類似樂觀鎖 ）
multi : 標(biāo)記一個事務(wù)塊的開始（ queued ）
exec : 執(zhí)行所有事務(wù)塊的命令 （ 一旦執(zhí)行exec后，之前加的監(jiān)控鎖都會被取消掉 ）
discard : 取消事務(wù)，放棄事務(wù)塊中的所有命令
unwatch : 取消watch對所有key的監(jiān)控

在什么情況下會觸發(fā)key的回收？

2種情況：1、定時（抽樣）清理；2、執(zhí)行命令時，判斷內(nèi)存是否超過maxmemory。

在集群種查找key的時候，是怎么定位到具體節(jié)點的？

使用crc16算法對key進行hash 將hash值對16384取模，得到具體的槽位根據(jù)節(jié)點和槽位的映射信息（與集群建立連接后，客戶端可以取得槽位映射信息），找到具體的節(jié)點地址 去具體的節(jié)點找key如果key不在這個節(jié)點上，則redis集群會返回moved指令，加上新的節(jié)點地址給客戶端，同時，客戶端會刷新本地的節(jié)點槽位映射關(guān)系如果槽位正在遷移中，那么redis集群會返回asking指令給客戶端，這是臨時糾正，客戶端不會刷新本地的節(jié)點槽位映射關(guān)系

用Redis做延時隊列，具體應(yīng)該怎么實現(xiàn)？

可以使用Zset實現(xiàn)。member是任務(wù)描述，score是執(zhí)行時間，然后用定時器定時去掃描，一 旦有執(zhí)行時間小于或等于當(dāng)前時間的任務(wù)，就立即執(zhí)行。

持久化了解過嗎？

Redis持久化有RDB和AOF這2種方式。
RDB：將數(shù)據(jù)庫快照以二進制的方式保存到磁盤中。
AOF：以協(xié)議文本方式，將所有對數(shù)據(jù)庫進行過寫入的命令和參數(shù)記錄到AOF文件，從而記錄 數(shù)據(jù)庫狀態(tài)。

r過期鍵的刪除策略？

• （1） 定時刪除:在設(shè)置鍵的過期時間的同時，創(chuàng)建一個定時器 timer). 讓定時器在鍵的過期時間來臨時，立即執(zhí)行對鍵的刪除操作。
• （2） 惰性刪除:放任鍵過期不管，但是每次從鍵空間中獲取鍵時，都檢查取得的鍵是否過期，如果過期的話，就刪除該鍵;如果沒有過期，就返回該鍵。
• （3） 定期刪除:每隔一段時間程序就對數(shù)據(jù)庫進行一次檢查，刪除里面的過期鍵。至于要刪除多少過期鍵，以及要檢查多少個數(shù)據(jù)庫，則由算法決定。

回收策略(淘汰策略)

• volatile-lru：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰
• volatile-ttl：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰
• volatile-random：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰
• allkeys-lru：從數(shù)據(jù)集（server.db[i].dict）中挑選最近最少使用的數(shù)據(jù)淘汰
• allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰
• no-enviction（驅(qū)逐）：禁止驅(qū)逐數(shù)據(jù)
  注意這里的 6 種機制，volatile 和 allkeys 規(guī)定了是對已設(shè)置過期時間的數(shù)據(jù)集淘汰數(shù)據(jù)還是從全部數(shù)據(jù)集淘汰數(shù)據(jù)，后面的 lru、ttl 以及 random 是三種不同的淘汰策略，再加上一種 no-enviction 永不回收的策略。
  使用策略規(guī)則：
• （1） 如果數(shù)據(jù)呈現(xiàn)冪律分布，也就是一部分?jǐn)?shù)據(jù)訪問頻率高，一部分?jǐn)?shù)據(jù)訪問頻率低，則使用 allkeys-lru
• （2） 如果數(shù)據(jù)呈現(xiàn)平等分布，也就是所有的數(shù)據(jù)訪問頻率都相同，則使用 allkeys-random

同步機制了解么？

答：Redis 可以使用主從同步，從從同步。
第一次同步時，主節(jié)點做一次bgsave，并同時將后續(xù)修改操作記錄到內(nèi)存 buffer，待完成后將 rdb 文件全量同步到復(fù)制節(jié)點，復(fù)制節(jié)點接受完成后將 rdb 鏡像加載到內(nèi)存。加載完成后，再通知主節(jié)點將期間修改的操作記錄同步到復(fù)制節(jié)點進行重放就完成了同步過程。

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

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

Redis 實例最多能存放多少的 keys？ List、Set、Sorted Set 他們最多能存放多少元素？

答：理論上 Redis 可以處理多達(dá) 2的32次方 的 keys，并且在實際中進行了測試，每個實例至少存放了 2 億 5 千萬的 keys。我們正在測試一些較大的值。
任何list、set、和 sorted set 都可以放 232 個元素。換句話說，Redis 的存儲極限是系統(tǒng)中的可用內(nèi)存值。

管道有什么用？

一次請求/響應(yīng)服務(wù)器能實現(xiàn)處理新的請求即使舊的請求還未被響應(yīng)。這樣就可以將多個命令發(fā) 送到服務(wù)器，而不用等待回復(fù)，最后在一個步驟中讀取該答復(fù)。
這就是管道（pipelining），是一種幾十年來廣泛使用的技術(shù)。例如許多POP3協(xié)議已經(jīng)實現(xiàn) 支持這個功能，大大加快了從服務(wù)器下載新郵件的過程。

高可用方案有哪些？

Redis 單副本

Redis 單副本，采用單個 Redis 節(jié)點部署架構(gòu)，沒有備用節(jié)點實時同步數(shù)據(jù)，不提供數(shù)據(jù)持久化和備份策略，適用于數(shù)據(jù)可靠性要求不高的純緩存業(yè)務(wù)場景。

Redis 多副本（主從）

Redis 多副本，采用主從（replication）部署結(jié)構(gòu)，相較于單副本而言最大的特點就是主從實例間數(shù)據(jù)實時同步，并且提供數(shù)據(jù)持久化和備份策略。主從實例部署在不同的物理服務(wù)器上，根據(jù)公司的基礎(chǔ)環(huán)境配置，可以實現(xiàn)同時對外提供服務(wù)和讀寫分離策略。

Redis Sentinel（哨兵）

Redis Sentinel 是社區(qū)版本推出的原生高可用解決方案，其部署架構(gòu)主要包括兩部分：Redis Sentinel 集群和 Redis 數(shù)據(jù)集群。

其中 Redis Sentinel 集群是由若干 Sentinel 節(jié)點組成的分布式集群，可以實現(xiàn)故障發(fā)現(xiàn)、故障自動轉(zhuǎn)移、配置中心和客戶端通知。Redis Sentinel 的節(jié)點數(shù)量要滿足 2n+1（n>=1）的奇數(shù)個。

Redis Cluster

Redis Cluster 是社區(qū)版推出的 Redis 分布式集群解決方案，主要解決 Redis 分布式方面的需求，比如，當(dāng)遇到單機內(nèi)存，并發(fā)和流量等瓶頸的時候，Redis Cluster 能起到很好的負(fù)載均衡的目的。

Redis Cluster 集群節(jié)點最小配置 6 個節(jié)點以上（3 主 3 從），其中主節(jié)點提供讀寫操作，從節(jié)點作為備用節(jié)點，不提供請求，只作為故障轉(zhuǎn)移使用。

Redis Cluster 采用虛擬槽分區(qū)，所有的鍵根據(jù)哈希函數(shù)映射到 0～16383 個整數(shù)槽內(nèi)，每個節(jié)點負(fù)責(zé)維護一部分槽以及槽所印映射的鍵值數(shù)據(jù)。

哨兵機制?

答：Redis的哨兵(sentinel) 系統(tǒng)用于管理多個 Redis 服務(wù)器,該系統(tǒng)執(zhí)行以下三個任務(wù):

監(jiān)控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。

提醒(Notification):當(dāng)被監(jiān)控的某個 Redis出現(xiàn)問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應(yīng)用程序發(fā)送通知。

自動故障遷移(Automatic failover):當(dāng)一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級為新的Master, 并讓失效Master的其他Slave改為復(fù)制新的Master; 當(dāng)客戶端試圖連接失效的Master時,集群也會向客戶端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一個分布式系統(tǒng),你可以在一個架構(gòu)中運行多個哨兵(sentinel) 進程,這些進程使用流言協(xié)議(gossipprotocols)來接收關(guān)于Master是否下線的信息,并使用投票協(xié)議(agreement protocols)來決定是否執(zhí)行自動故障遷移,以及選擇哪個Slave作為新的Master。

每個哨兵(sentinel) 會向其它哨兵(sentinel)、master、slave定時發(fā)送消息,以確認(rèn)對方是否”活”著,如果發(fā)現(xiàn)對方在指定時間(可配置)內(nèi)未回應(yīng),則暫時認(rèn)為對方已掛(所謂的”主觀認(rèn)為宕機” Subjective Down,簡稱sdown).

若“哨兵群”中的多數(shù)sentinel,都報告某一master沒響應(yīng),系統(tǒng)才認(rèn)為該master"徹底死亡"(即:客觀上的真正down機,Objective Down,簡稱odown),通過一定的vote算法,從剩下的slave節(jié)點中,選一臺提升為master,然后自動修改相關(guān)配置。

雖然哨兵(sentinel) 釋出為一個單獨的可執(zhí)行文件 redis-sentinel ,但實際上它只是一個運行在特殊模式下的 Redis 服務(wù)器，你可以在啟動一個普通 Redis 服務(wù)器時通過給定 --sentinel 選項來啟動哨兵(sentinel)。

哨兵(sentinel) 的一些設(shè)計思路和zookeeper非常類似

redis鎖

面試官:這樣設(shè)置會不會有問題呢？如果加鎖成功的客戶端掛了怎么辦？

我：比如上圖中的客戶端1掛了，這個鎖就不能釋放了。可以設(shè)置一個過期時間，命令如下：

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

面試官:設(shè)置了過期時間，如果業(yè)務(wù)還沒有執(zhí)行完成，但是redis鎖過期了，怎么辦？

我：需要對鎖進行續(xù)約。

面試官：能說一下具體怎么操作嗎？

我：設(shè)置鎖成功后，啟動一個watchdog，每隔一段時間(比如10s)為當(dāng)前分布式鎖續(xù)約，也就是每隔10s重新設(shè)置當(dāng)前key的超時時間。命令如下：

EXPIRE <key> <seconds>

面試官：watchdog怎么實現(xiàn)呢？

我：當(dāng)客戶端加鎖成功后，可以啟動一個定時任務(wù)，每隔10s(最好支持配置)來檢測業(yè)務(wù)是否處理完成，檢測的依據(jù)就是判斷分布式鎖的key是否還存在，如果存在，就進行續(xù)約。

面試官：如果當(dāng)前線程已經(jīng)處理完，這個key是被其他客戶端寫入的呢？

我：可以為每個客戶端指定一個clientID，在VALUE中增加一個clientID的前綴，這樣在續(xù)鎖的時候，可以判斷當(dāng)前分布式鎖的value前綴來確定是不是當(dāng)前客戶端的，如果是再續(xù)鎖，否則不做處理。

面試官:你們的續(xù)鎖功能是自己實現(xiàn)的嗎？

我:我們用的redisson的分布式鎖方案，使用redisson獲取分布式鎖非常簡單，代碼如下：

RLock lock = redisson.getLock("client-lock");nlock.lock();ntry {n//處理業(yè)務(wù)n} catch (Exception e) {n//處理異常n} finally {nlock.unlock();n}

具體原理是：如果客戶端1加鎖成功，這個分布式鎖超時時間默認(rèn)是30秒(可以通過Config.lockWatchdogTimeout來修改)。加鎖成功后，就會啟動一個watchdog，watchdog是一個后臺線程，會每隔10秒檢查一下客戶端1是否還持有鎖key，如果是，就延長鎖key的生存時間，延長操作就是再次把鎖key的超時時間設(shè)置成30s。

面試官：redisson里的定時器怎么實現(xiàn)的？

我：redisson定時器使用的是netty-common包中的HashedWheelTime來實現(xiàn)的。

面試官：如果client1宕機了，這時分布式鎖還可以續(xù)期嗎？

我：因為分布式鎖的續(xù)期是在客戶端執(zhí)行的，所以如果client1宕機了，續(xù)期線程就不能工作了，也就不能續(xù)期了。這時應(yīng)該把分布式鎖刪除，讓其他客戶端來獲取。

面試官：那如果client1宕機了，其他客戶端需要等待30s才能有機會獲取到鎖，有辦法立刻刪除鎖嗎？

我：因為client1宕機了，只能等到超時時間后鎖被自動刪除。如果要立刻刪除，需要增加額外的工作，比如增加哨兵機制，讓哨兵來維護所有redis客戶端的列表。哨兵定時監(jiān)控客戶端是否宕機，如果檢測到宕機，立刻刪除這個客戶端的鎖。如下圖：

這里的哨兵并不是redis的哨兵，而且為了檢測客戶端故障業(yè)務(wù)系統(tǒng)自己做的哨兵。

面試官：如果不用redisson，怎么實現(xiàn)分布式鎖續(xù)鎖呢？比如springboot2.0默認(rèn)使用redis客戶端是Lettuce。

我：Lettuce并沒有提供像redisson這樣的watchdog機制，所以續(xù)鎖需要業(yè)務(wù)系統(tǒng)自己實現(xiàn)。可以分為以下幾步來實現(xiàn)：

加鎖的命令，我們參照spring包里的分布式鎖代碼，如果鎖存在并且是當(dāng)前客戶端加的鎖，那就續(xù)鎖，如果鎖不存在，則加鎖。代碼如下：

private static final String OBTAIN_LOCK_SCRIPT =n"local lockClientId = redis.call('GET', KEYS[1])n" +n"if lockClientId == ARGV[1] thenn" +n" redis.call('PEXPIRE', KEYS[1], ARGV[2])n" +n" return truen" +n"elseif not lockClientId thenn" +n" redis.call('SET', KEYS[1], ARGV[1], 'PX', ARGV[2])n" +n" return truen" +n"endn" +n"return false";

把鎖保存在一個數(shù)據(jù)結(jié)構(gòu)里，比如HashMap，定時任務(wù)定時掃描這個map，對每個鎖進行續(xù)鎖操作。代碼如下：

redisTemplate.execute(renewLockScript,nCollections.singletonList(lockKey), clientId,nString.valueOf(expireAfter));