總結(jié)一波 Redis 面試題，收藏起來。

本文的面試題如下：

• Redis 持久化機(jī)制

• 緩存雪崩、緩存穿透、緩存預(yù)熱、緩存更新、緩存降級(jí)等問題

• 熱點(diǎn)數(shù)據(jù)和冷數(shù)據(jù)是什么

• Memcache與Redis的區(qū)別都有哪些？

• 單線程的redis為什么這么快

• redis的數(shù)據(jù)類型，以及每種數(shù)據(jù)類型的使用場景，Redis 內(nèi)部結(jié)構(gòu)

• redis的過期策略以及內(nèi)存淘汰機(jī)制【～】

• Redis 為什么是單線程的，優(yōu)點(diǎn)

• 如何解決redis的并發(fā)競爭key問題

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

• 有沒有嘗試進(jìn)行多機(jī)redis 的部署？如何保證數(shù)據(jù)一致的？

• 對(duì)于大量的請(qǐng)求怎么樣處理

• Redis 常見性能問題和解決方案？

• 講解下Redis線程模型

• 為什么Redis的操作是原子性的，怎么保證原子性的？

• Redis事務(wù)

• Redis實(shí)現(xiàn)分布式鎖

Redis 持久化機(jī)制

Redis是一個(gè)支持持久化的內(nèi)存數(shù)據(jù)庫，通過持久化機(jī)制把內(nèi)存中的數(shù)據(jù)同步到硬盤文件來保證數(shù)據(jù)持久化。當(dāng)Redis重啟后通過把硬盤文件重新加載到內(nèi)存，就能達(dá)到恢復(fù)數(shù)據(jù)的目的。

實(shí)現(xiàn)：單獨(dú)創(chuàng)建fork()一個(gè)子進(jìn)程，將當(dāng)前父進(jìn)程的數(shù)據(jù)庫數(shù)據(jù)復(fù)制到子進(jìn)程的內(nèi)存中，然后由子進(jìn)程寫入到臨時(shí)文件中，持久化的過程結(jié)束了，再用這個(gè)臨時(shí)文件替換上次的快照文件，然后子進(jìn)程退出，內(nèi)存釋放。

RDB是Redis默認(rèn)的持久化方式。按照一定的時(shí)間周期策略把內(nèi)存的數(shù)據(jù)以快照的形式保存到硬盤的二進(jìn)制文件。即Snapshot快照存儲(chǔ)，對(duì)應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb，通過配置文件中的save參數(shù)來定義快照的周期。（ 快照可以是其所表示的數(shù)據(jù)的一個(gè)副本，也可以是數(shù)據(jù)的一個(gè)復(fù)制品。）
AOF：Redis會(huì)將每一個(gè)收到的寫命令都通過Write函數(shù)追加到文件最后，類似于MySQL的binlog。當(dāng)Redis重啟是會(huì)通過重新執(zhí)行文件中保存的寫命令來在內(nèi)存中重建整個(gè)數(shù)據(jù)庫的內(nèi)容。

當(dāng)兩種方式同時(shí)開啟時(shí)，數(shù)據(jù)恢復(fù)Redis會(huì)優(yōu)先選擇AOF恢復(fù)。

緩存雪崩、緩存穿透、緩存預(yù)熱、緩存更新、緩存降級(jí)等問題

緩存雪崩

緩存雪崩我們可以簡單的理解為：由于原有緩存失效，新緩存未到期間

(例如：我們?cè)O(shè)置緩存時(shí)采用了相同的過期時(shí)間，在同一時(shí)刻出現(xiàn)大面積的緩存過期)，所有原本應(yīng)該訪問緩存的請(qǐng)求都去查詢數(shù)據(jù)庫了，而對(duì)數(shù)據(jù)庫CPU和內(nèi)存造成巨大壓力，嚴(yán)重的會(huì)造成數(shù)據(jù)庫宕機(jī)。從而形成一系列連鎖反應(yīng)，造成整個(gè)系統(tǒng)崩潰。

解決辦法：

大多數(shù)系統(tǒng)設(shè)計(jì)者考慮用加鎖（ 最多的解決方案）或者隊(duì)列的方式保證來保證不會(huì)有大量的線程對(duì)數(shù)據(jù)庫一次性進(jìn)行讀寫，從而避免失效時(shí)大量的并發(fā)請(qǐng)求落到底層存儲(chǔ)系統(tǒng)上。還有一個(gè)簡單方案就時(shí)講緩存失效時(shí)間分散開。

緩存穿透

緩存穿透是指用戶查詢數(shù)據(jù)，在數(shù)據(jù)庫沒有，自然在緩存中也不會(huì)有。這樣就導(dǎo)致用戶查詢的時(shí)候，在緩存中找不到，每次都要去數(shù)據(jù)庫再查詢一遍，然后返回空（相當(dāng)于進(jìn)行了兩次無用的查詢）。這樣請(qǐng)求就繞過緩存直接查數(shù)據(jù)庫，這也是經(jīng)常提的緩存命中率問題。

解決辦法：

最常見的則是采用布隆過濾器，將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠大的bitmap中，一個(gè)一定不存在的數(shù)據(jù)會(huì)被這個(gè)bitmap攔截掉，從而避免了對(duì)底層存儲(chǔ)系統(tǒng)的查詢壓力。

另外也有一個(gè)更為簡單粗暴的方法，如果一個(gè)查詢返回的數(shù)據(jù)為空（不管是數(shù)據(jù)不存在，還是系統(tǒng)故障），我們?nèi)匀话堰@個(gè)空結(jié)果進(jìn)行緩存，但它的過期時(shí)間會(huì)很短，最長不超過五分鐘。通過這個(gè)直接設(shè)置的默認(rèn)值存放到緩存，這樣第二次到緩沖中獲取就有值了，而不會(huì)繼續(xù)訪問數(shù)據(jù)庫，這種辦法最簡單粗暴。

5TB的硬盤上放滿了數(shù)據(jù)，請(qǐng)寫一個(gè)算法將這些數(shù)據(jù)進(jìn)行排重。如果這些數(shù)據(jù)是一些32bit大小的數(shù)據(jù)該如何解決？如果是64bit的呢？

對(duì)于空間的利用到達(dá)了一種極致，那就是Bitmap和布隆過濾器(Bloom Filter)。

Bitmap：典型的就是哈希表

缺點(diǎn)是，Bitmap對(duì)于每個(gè)元素只能記錄1bit信息，如果還想完成額外的功能，恐怕只能靠犧牲更多的空間、時(shí)間來完成了。

布隆過濾器（推薦）

就是引入了k(k>1)k(k>1)個(gè)相互獨(dú)立的哈希函數(shù)，保證在給定的空間、誤判率下，完成元素判重的過程。

它的優(yōu)點(diǎn)是空間效率和查詢時(shí)間都遠(yuǎn)遠(yuǎn)超過一般的算法，缺點(diǎn)是有一定的誤識(shí)別率和刪除困難。

Bloom-Filter算法的核心思想就是利用多個(gè)不同的Hash函數(shù)來解決“沖突”。

Hash存在一個(gè)沖突（碰撞）的問題，用同一個(gè)Hash得到的兩個(gè)URL的值有可能相同。為了減少?zèng)_突，我們可以多引入幾個(gè)Hash，如果通過其中的一個(gè)Hash值我們得出某元素不在集合中，那么該元素肯定不在集合中。只有在所有的Hash函數(shù)告訴我們?cè)撛卦诩现袝r(shí)，才能確定該元素存在于集合中。這便是Bloom-Filter的基本思想。

Bloom-Filter一般用于在大數(shù)據(jù)量的集合中判定某元素是否存在。

緩存穿透與緩存擊穿的區(qū)別

緩存擊穿：是指一個(gè)key非常熱點(diǎn)，在不停的扛著大并發(fā)，大并發(fā)集中對(duì)這一個(gè)點(diǎn)進(jìn)行訪問，當(dāng)這個(gè)key在失效的瞬間，持續(xù)的大并發(fā)就穿破緩存，直接請(qǐng)求數(shù)據(jù)。

解決方案：在訪問key之前，采用SETNX（set if not exists）來設(shè)置另一個(gè)短期key來鎖住當(dāng)前key的訪問，訪問結(jié)束再刪除該短期key。

給一個(gè)我公司處理的案例：背景雙機(jī)拿token，token在存一份到redis，保證系統(tǒng)在token過期時(shí)都只有一個(gè)線程去獲取token;線上環(huán)境有兩臺(tái)機(jī)器，故使用分布式鎖實(shí)現(xiàn)。

三、緩存預(yù)熱

緩存預(yù)熱這個(gè)應(yīng)該是一個(gè)比較常見的概念，相信很多小伙伴都應(yīng)該可以很容易的理解，緩存預(yù)熱就是系統(tǒng)上線后，將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。這樣就可以避免在用戶請(qǐng)求的時(shí)候，先查詢數(shù)據(jù)庫，然后再將數(shù)據(jù)緩存的問題！用戶直接查詢事先被預(yù)熱的緩存數(shù)據(jù)！

解決思路：

• 直接寫個(gè)緩存刷新頁面，上線時(shí)手工操作下；

• 數(shù)據(jù)量不大，可以在項(xiàng)目啟動(dòng)的時(shí)候自動(dòng)進(jìn)行加載；

• 定時(shí)刷新緩存；

四、緩存更新

除了緩存服務(wù)器自帶的緩存失效策略之外（Redis默認(rèn)的有6中策略可供選擇），我們還可以根據(jù)具體的業(yè)務(wù)需求進(jìn)行自定義的緩存淘汰，常見的策略有兩種：

• 定時(shí)去清理過期的緩存；

• 當(dāng)有用戶請(qǐng)求過來時(shí)，再判斷這個(gè)請(qǐng)求所用到的緩存是否過期，過期的話就去底層系統(tǒng)得到新數(shù)據(jù)并更新緩存。

兩者各有優(yōu)劣，第一種的缺點(diǎn)是維護(hù)大量緩存的key是比較麻煩的，第二種的缺點(diǎn)就是每次用戶請(qǐng)求過來都要判斷緩存失效，邏輯相對(duì)比較復(fù)雜！具體用哪種方案，大家可以根據(jù)自己的應(yīng)用場景來權(quán)衡。

五、緩存降級(jí)

當(dāng)訪問量劇增、服務(wù)出現(xiàn)問題（如響應(yīng)時(shí)間慢或不響應(yīng)）或非核心服務(wù)影響到核心流程的性能時(shí)，仍然需要保證服務(wù)還是可用的，即使是有損服務(wù)。系統(tǒng)可以根據(jù)一些關(guān)鍵數(shù)據(jù)進(jìn)行自動(dòng)降級(jí)，也可以配置開關(guān)實(shí)現(xiàn)人工降級(jí)。

降級(jí)的最終目的是保證核心服務(wù)可用，即使是有損的。而且有些服務(wù)是無法降級(jí)的（如加入購物車、結(jié)算）。

以參考日志級(jí)別設(shè)置預(yù)案：

• 一般：比如有些服務(wù)偶爾因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者服務(wù)正在上線而超時(shí)，可以自動(dòng)降級(jí)；

• 警告：有些服務(wù)在一段時(shí)間內(nèi)成功率有波動(dòng)（如在95~100%之間），可以自動(dòng)降級(jí)或人工降級(jí)，并發(fā)送告警；

• 錯(cuò)誤：比如可用率低于90%，或者數(shù)據(jù)庫連接池被打爆了，或者訪問量突然猛增到系統(tǒng)能承受的最大閥值，此時(shí)可以根據(jù)情況自動(dòng)降級(jí)或者人工降級(jí)；

• 嚴(yán)重錯(cuò)誤：比如因?yàn)樘厥庠驍?shù)據(jù)錯(cuò)誤了，此時(shí)需要緊急人工降級(jí)。

服務(wù)降級(jí)的目的，是為了防止Redis服務(wù)故障，導(dǎo)致數(shù)據(jù)庫跟著一起發(fā)生雪崩問題。因此，對(duì)于不重要的緩存數(shù)據(jù)，可以采取服務(wù)降級(jí)策略，例如一個(gè)比較常見的做法就是，Redis出現(xiàn)問題，不去數(shù)據(jù)庫查詢，而是直接返回默認(rèn)值給用戶。

熱點(diǎn)數(shù)據(jù)和冷數(shù)據(jù)是什么

熱點(diǎn)數(shù)據(jù)，緩存才有價(jià)值

對(duì)于冷數(shù)據(jù)而言，大部分?jǐn)?shù)據(jù)可能還沒有再次訪問到就已經(jīng)被擠出內(nèi)存，不僅占用內(nèi)存，而且價(jià)值不大。頻繁修改的數(shù)據(jù)，看情況考慮使用緩存

對(duì)于上面兩個(gè)例子，壽星列表、導(dǎo)航信息都存在一個(gè)特點(diǎn)，就是信息修改頻率不高，讀取通常非常高的場景。

對(duì)于熱點(diǎn)數(shù)據(jù)，比如我們的某IM產(chǎn)品，生日祝福模塊，當(dāng)天的壽星列表，緩存以后可能讀取數(shù)十萬次。再舉個(gè)例子，某導(dǎo)航產(chǎn)品，我們將導(dǎo)航信息，緩存以后可能讀取數(shù)百萬次。

數(shù)據(jù)更新前至少讀取兩次， 緩存才有意義。這個(gè)是最基本的策略，如果緩存還沒有起作用就失效了，那就沒有太大價(jià)值了。

那存不存在，修改頻率很高，但是又不得不考慮緩存的場景呢？有！比如，這個(gè)讀取接口對(duì)數(shù)據(jù)庫的壓力很大，但是又是熱點(diǎn)數(shù)據(jù)，這個(gè)時(shí)候就需要考慮通過緩存手段，減少數(shù)據(jù)庫的壓力，比如我們的某助手產(chǎn)品的，點(diǎn)贊數(shù)，收藏?cái)?shù)，分享數(shù)等是非常典型的熱點(diǎn)數(shù)據(jù)，但是又不斷變化，此時(shí)就需要將數(shù)據(jù)同步保存到Redis緩存，減少數(shù)據(jù)庫壓力。

Memcache與Redis的區(qū)別都有哪些？

1)、存儲(chǔ)方式 Memecache把數(shù)據(jù)全部存在內(nèi)存之中，斷電后會(huì)掛掉，數(shù)據(jù)不能超過內(nèi)存大小。Redis有部份存在硬盤上，redis可以持久化其數(shù)據(jù)

2)、數(shù)據(jù)支持類型 memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富的數(shù)據(jù)類型 ，提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)

3)、使用底層模型不同 它們之間底層實(shí)現(xiàn)方式 以及與客戶端之間通信的應(yīng)用協(xié)議不一樣。Redis直接自己構(gòu)建了VM 機(jī)制 ，因?yàn)橐话愕南到y(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會(huì)浪費(fèi)一定的時(shí)間去移動(dòng)和請(qǐng)求。

4). value 值大小不同：Redis 最大可以達(dá)到 512M；memcache 只有 1mb。

5）redis的速度比memcached快很多

單線程的redis為什么這么快

(一)純內(nèi)存操作

(二)單線程操作，避免了頻繁的上下文切換

(三)采用了非阻塞I/O多路復(fù)用機(jī)制

redis的數(shù)據(jù)類型，以及每種數(shù)據(jù)類型的使用場景

回答：一共五種

(一)String

這個(gè)其實(shí)沒啥好說的，最常規(guī)的set/get操作，value可以是String也可以是數(shù)字。一般做一些復(fù)雜的計(jì)數(shù)功能的緩存。

(二)hash

這里value存放的是結(jié)構(gòu)化的對(duì)象，比較方便的就是操作其中的某個(gè)字段。博主在做單點(diǎn)登錄的時(shí)候，就是用這種數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)用戶信息，以cookieId作為key，設(shè)置30分鐘為緩存過期時(shí)間，能很好的模擬出類似session的效果。

(三)list

使用List的數(shù)據(jù)結(jié)構(gòu)，可以做簡單的消息隊(duì)列的功能。另外還有一個(gè)就是，可以利用lrange命令，做基于redis的分頁功能，性能極佳，用戶體驗(yàn)好。本人還用一個(gè)場景，很合適—取行情信息。就也是個(gè)生產(chǎn)者和消費(fèi)者的場景。LIST可以很好的完成排隊(duì)，先進(jìn)先出的原則。

(四)set

因?yàn)閟et堆放的是一堆不重復(fù)值的集合。所以可以做全局去重的功能。為什么不用JVM自帶的Set進(jìn)行去重？因?yàn)槲覀兊南到y(tǒng)一般都是集群部署，使用JVM自帶的Set，比較麻煩，難道為了一個(gè)做一個(gè)全局去重，再起一個(gè)公共服務(wù)，太麻煩了。

另外，就是利用交集、并集、差集等操作，可以計(jì)算共同喜好，全部的喜好，自己獨(dú)有的喜好等功能。

(五)sorted set

sorted set多了一個(gè)權(quán)重參數(shù)score,集合中的元素能夠按score進(jìn)行排列。可以做排行榜應(yīng)用，取TOP N操作。

Redis 內(nèi)部結(jié)構(gòu)

• dict 本質(zhì)上是為了解決算法中的查找問題（Searching）是一個(gè)用于維護(hù)key和value映射關(guān)系的數(shù)據(jù)結(jié)構(gòu)，與很多語言中的Map或dictionary類似。本質(zhì)上是為了解決算法中的查找問題（Searching）
• sds sds就等同于char * 它可以存儲(chǔ)任意二進(jìn)制數(shù)據(jù)，不能像C語言字符串那樣以字符’\0’來標(biāo)識(shí)字符串的結(jié) 束，因此它必然有個(gè)長度字段。
• skiplist （跳躍表） 跳表是一種實(shí)現(xiàn)起來很簡單，單層多指針的鏈表，它查找效率很高，堪比優(yōu)化過的二叉平衡樹，且比平衡樹的實(shí)現(xiàn)，
• quicklist
• ziplist 壓縮表 ziplist是一個(gè)編碼后的列表，是由一系列特殊編碼的連續(xù)內(nèi)存塊組成的順序型數(shù)據(jù)結(jié)構(gòu)，

redis的過期策略以及內(nèi)存淘汰機(jī)制

maxmemory-policy volatile-lru1

• volatile-lru：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰
• volatile-ttl：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰
• volatile-random：從已設(shè)置過期時(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ù)，新寫入操作會(huì)報(bào)錯(cuò)

Redis 為什么是單線程的

• 速度快，因?yàn)閿?shù)據(jù)存在內(nèi)存中，類似于HashMap，HashMap的優(yōu)勢就是查找和操作的時(shí)間復(fù)雜度都是O(1)
• 支持豐富數(shù)據(jù)類型，支持string，list，set，sorted set，hash
• 支持事務(wù)，操作都是原子性，所謂的原子性就是對(duì)數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行
• 豐富的特性：可用于緩存，消息，按key設(shè)置過期時(shí)間，過期后將會(huì)自動(dòng)刪除如何解決redis的并發(fā)競爭key問題

• 如果對(duì)這個(gè)key操作，不要求順序：準(zhǔn)備一個(gè)分布式鎖，大家去搶鎖，搶到鎖就做set操作即可
• 如果對(duì)這個(gè)key操作，要求順序：分布式鎖+時(shí)間戳。假設(shè)這會(huì)系統(tǒng)B先搶到鎖，將key1設(shè)置為{valueB 3:05}。接下來系統(tǒng)A搶到鎖，發(fā)現(xiàn)自己的valueA的時(shí)間戳早于緩存中的時(shí)間戳，那就不做set操作了。以此類推。
• 利用隊(duì)列，將set方法變成串行訪問也可以redis遇到高并發(fā)，如果保證讀寫key的一致性

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

有沒有嘗試進(jìn)行多機(jī)redis 的部署？如何保證數(shù)據(jù)一致的？

對(duì)于大量的請(qǐng)求怎么樣處理

Redis 常見性能問題和解決方案？

講解下Redis線程模型

為什么Redis的操作是原子性的，怎么保證原子性的？

Redis事務(wù)

1. redis 不支持回滾“Redis 在事務(wù)失敗時(shí)不進(jìn)行回滾，而是繼續(xù)執(zhí)行余下的命令”， 所以 Redis 的內(nèi)部可以保持簡單且快速。
2. 如果在一個(gè)事務(wù)中的命令出現(xiàn)錯(cuò)誤，那么所有的命令都不會(huì)執(zhí)行；
3. 如果在一個(gè)事務(wù)中出現(xiàn)運(yùn)行錯(cuò)誤，那么正確的命令會(huì)被執(zhí)行。

Redis實(shí)現(xiàn)分布式鎖

• 通過Redis中expire()給鎖設(shè)定最大持有時(shí)間，如果超過，則Redis來幫我們釋放鎖。
• 使用 setnx key “當(dāng)前系統(tǒng)時(shí)間+鎖持有的時(shí)間”和getset key “當(dāng)前系統(tǒng)時(shí)間+鎖持有的時(shí)間”組合的命令就可以實(shí)現(xiàn)。

END

有熱門推薦?
1.?Eclipse 官宣，要干掉 VS Code，你怎么看？
2.?史上最便捷搭建Zookeeper服務(wù)器的方法
3.?擁抱 Java 8 并行流：執(zhí)行速度飛起 ！
4.?別再吹Rust了，它太難學(xué)了！
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊(cè)》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點(diǎn)“在看”，關(guān)注公眾號(hào)并回復(fù)?Java?領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
文章有幫助的話，在看，轉(zhuǎn)發(fā)吧。
謝謝支持喲 (*^__^*)