《吊打面试官》系列-Redis常见面试题
前言
Redis在互聯(lián)網(wǎng)技術(shù)存儲(chǔ)方面使用如此廣泛，幾乎所有的后端技術(shù)面試官都要在Redis的使用和原理方面對(duì)小伙伴們進(jìn)行360°的刁難。
作為一個(gè)在互聯(lián)網(wǎng)公司面一次拿一次Offer的面霸，打敗了無(wú)數(shù)競(jìng)爭(zhēng)對(duì)手，每次都只能看到無(wú)數(shù)落寞的身影失望的離開(kāi)，略感愧疚（請(qǐng)?jiān)试S我使用一下夸張的修辭手法）。
于是在一個(gè)寂寞難耐的夜晚，我痛定思痛，決定開(kāi)始寫(xiě)《吊打面試官》系列，希望能幫助各位讀者以后面試勢(shì)如破竹，對(duì)面試官進(jìn)行360°的反擊，吊打問(wèn)你的面試官，讓一同面試的同僚瞠目結(jié)舌，瘋狂收割大廠(chǎng)Offer！
絮叨
上一期因?yàn)槭窃陔p十一一直在熬夜的大環(huán)境下完成的，所以我自己覺(jué)得質(zhì)量明顯沒(méi)之前的好，我這不一睡好就加班加點(diǎn)準(zhǔn)備補(bǔ)償大家，來(lái)點(diǎn)干貨。（熬夜太容易感冒了，這次點(diǎn)個(gè)贊別白嫖了！）
順帶提一嘴，我把我準(zhǔn)備寫(xiě)啥畫(huà)了一個(gè)思維導(dǎo)圖，以后總不能每篇都放個(gè)賊大的圖吧，就開(kāi)源到了我的GitHub，大家有興趣可以去完善和Star。
這篇我就先放出來(lái)大家看看，感覺(jué)還是差點(diǎn)意思，等大家完善了。
回望過(guò)去
上一期吊打系列我們提到了Redis相關(guān)的一些知識(shí)，還沒(méi)看的小伙伴可以回顧一下
《吊打面試官》系列-Redis基礎(chǔ)
《吊打面試官》系列-緩存雪崩、擊穿、穿透
《吊打面試官》系列-Redis哨兵、持久化、主從、手撕LRU
《吊打面試官》系列-Redis終章-凜冬將至、FPX-新王登基
緩存知識(shí)點(diǎn)
緩存有哪些類(lèi)型？
緩存是高并發(fā)場(chǎng)景下提高熱點(diǎn)數(shù)據(jù)訪(fǎng)問(wèn)性能的一個(gè)有效手段，在開(kāi)發(fā)項(xiàng)目時(shí)會(huì)經(jīng)常使用到。
緩存的類(lèi)型分為：本地緩存、分布式緩存和多級(jí)緩存。
本地緩存：
本地緩存就是在進(jìn)程的內(nèi)存中進(jìn)行緩存，比如我們的 JVM 堆中，可以用 LRUMap 來(lái)實(shí)現(xiàn)，也可以使用 Ehcache 這樣的工具來(lái)實(shí)現(xiàn)。
本地緩存是內(nèi)存訪(fǎng)問(wèn)，沒(méi)有遠(yuǎn)程交互開(kāi)銷(xiāo)，性能最好，但是受限于單機(jī)容量，一般緩存較小且無(wú)法擴(kuò)展。
分布式緩存：
分布式緩存可以很好得解決這個(gè)問(wèn)題。
分布式緩存一般都具有良好的水平擴(kuò)展能力，對(duì)較大數(shù)據(jù)量的場(chǎng)景也能應(yīng)付自如。缺點(diǎn)就是需要進(jìn)行遠(yuǎn)程請(qǐng)求，性能不如本地緩存。
多級(jí)緩存：
為了平衡這種情況，實(shí)際業(yè)務(wù)中一般采用多級(jí)緩存，本地緩存只保存訪(fǎng)問(wèn)頻率最高的部分熱點(diǎn)數(shù)據(jù)，其他的熱點(diǎn)數(shù)據(jù)放在分布式緩存中。
在目前的一線(xiàn)大廠(chǎng)中，這也是最常用的緩存方案，單考單一的緩存方案往往難以撐住很多高并發(fā)的場(chǎng)景。
淘汰策略
不管是本地緩存還是分布式緩存，為了保證較高性能，都是使用內(nèi)存來(lái)保存數(shù)據(jù)，由于成本和內(nèi)存限制，當(dāng)存儲(chǔ)的數(shù)據(jù)超過(guò)緩存容量時(shí)，需要對(duì)緩存的數(shù)據(jù)進(jìn)行剔除。
一般的剔除策略有 FIFO 淘汰最早數(shù)據(jù)、LRU 剔除最近最少使用、和 LFU 剔除最近使用頻率最低的數(shù)據(jù)幾種策略。
noeviction:返回錯(cuò)誤當(dāng)內(nèi)存限制達(dá)到并且客戶(hù)端嘗試執(zhí)行會(huì)讓更多內(nèi)存被使用的命令（大部分的寫(xiě)入指令，但DEL和幾個(gè)例外）
allkeys-lru: 嘗試回收最少使用的鍵（LRU），使得新添加的數(shù)據(jù)有空間存放。
volatile-lru: 嘗試回收最少使用的鍵（LRU），但僅限于在過(guò)期集合的鍵,使得新添加的數(shù)據(jù)有空間存放。
allkeys-random: 回收隨機(jī)的鍵使得新添加的數(shù)據(jù)有空間存放。
volatile-random: 回收隨機(jī)的鍵使得新添加的數(shù)據(jù)有空間存放，但僅限于在過(guò)期集合的鍵。
volatile-ttl: 回收在過(guò)期集合的鍵，并且優(yōu)先回收存活時(shí)間（TTL）較短的鍵,使得新添加的數(shù)據(jù)有空間存放。
如果沒(méi)有鍵滿(mǎn)足回收的前提條件的話(huà)，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。
其實(shí)在大家熟悉的LinkedHashMap中也實(shí)現(xiàn)了Lru算法的，實(shí)現(xiàn)如下：
當(dāng)容量超過(guò)100時(shí)，開(kāi)始執(zhí)行LRU策略：將最近最少未使用的 TimeoutInfoHolder 對(duì)象 evict 掉。
真實(shí)面試中會(huì)讓你寫(xiě)LUR算法，你可別搞原始的那個(gè)，那真TM多，寫(xiě)不完的，你要么懟上面這個(gè)，要么懟下面這個(gè)，找一個(gè)數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)下Java版本的LRU還是比較容易的，知道啥原理就好了。
Memcache
注意后面會(huì)把 Memcache 簡(jiǎn)稱(chēng)為 MC。
先來(lái)看看 MC 的特點(diǎn)：
MC 處理請(qǐng)求時(shí)使用多線(xiàn)程異步 IO 的方式，可以合理利用 CPU 多核的優(yōu)勢(shì)，性能非常優(yōu)秀；
MC 功能簡(jiǎn)單，使用內(nèi)存存儲(chǔ)數(shù)據(jù)；
MC 的內(nèi)存結(jié)構(gòu)以及鈣化問(wèn)題我就不細(xì)說(shuō)了，大家可以查看官網(wǎng)了解下；
MC 對(duì)緩存的數(shù)據(jù)可以設(shè)置失效期，過(guò)期后的數(shù)據(jù)會(huì)被清除；
失效的策略采用延遲失效，就是當(dāng)再次使用數(shù)據(jù)時(shí)檢查是否失效；
當(dāng)容量存滿(mǎn)時(shí)，會(huì)對(duì)緩存中的數(shù)據(jù)進(jìn)行剔除，剔除時(shí)除了會(huì)對(duì)過(guò)期 key 進(jìn)行清理，還會(huì)按 LRU 策略對(duì)數(shù)據(jù)進(jìn)行剔除。
另外，使用 MC 有一些限制，這些限制在現(xiàn)在的互聯(lián)網(wǎng)場(chǎng)景下很致命，成為大家選擇Redis、MongoDB的重要原因：
key 不能超過(guò) 250 個(gè)字節(jié)；
value 不能超過(guò) 1M 字節(jié)；
key 的最大失效時(shí)間是 30 天；
只支持 K-V 結(jié)構(gòu)，不提供持久化和主從同步功能。
Redis
先簡(jiǎn)單說(shuō)一下 Redis 的特點(diǎn)，方便和 MC 比較。
與 MC 不同的是，Redis 采用單線(xiàn)程模式處理請(qǐng)求。這樣做的原因有 2 個(gè)：一個(gè)是因?yàn)椴捎昧朔亲枞漠惒绞录幚頇C(jī)制；另一個(gè)是緩存數(shù)據(jù)都是內(nèi)存操作 IO 時(shí)間不會(huì)太長(zhǎng)，單線(xiàn)程可以避免線(xiàn)程上下文切換產(chǎn)生的代價(jià)。
Redis 支持持久化，所以 Redis 不僅僅可以用作緩存，也可以用作 NoSQL 數(shù)據(jù)庫(kù)。
相比 MC，Redis 還有一個(gè)非常大的優(yōu)勢(shì)，就是除了 K-V 之外，還支持多種數(shù)據(jù)格式，例如 list、set、sorted set、hash 等。
Redis 提供主從同步機(jī)制，以及 Cluster 集群部署能力，能夠提供高可用服務(wù)。
詳解 Redis
Redis 的知識(shí)點(diǎn)結(jié)構(gòu)如下圖所示。
功能
來(lái)看 Redis 提供的功能有哪些吧！
我們先看基礎(chǔ)類(lèi)型：
String：
String 類(lèi)型是 Redis 中最常使用的類(lèi)型，內(nèi)部的實(shí)現(xiàn)是通過(guò) SDS（Simple Dynamic String ）來(lái)存儲(chǔ)的。SDS 類(lèi)似于 Java 中的 ArrayList，可以通過(guò)預(yù)分配冗余空間的方式來(lái)減少內(nèi)存的頻繁分配。
這是最簡(jiǎn)單的類(lèi)型，就是普通的 set 和 get，做簡(jiǎn)單的 KV 緩存。
但是真實(shí)的開(kāi)發(fā)環(huán)境中，很多仔可能會(huì)把很多比較復(fù)雜的結(jié)構(gòu)也統(tǒng)一轉(zhuǎn)成String去存儲(chǔ)使用，比如有的仔他就喜歡把對(duì)象或者List轉(zhuǎn)換為JSONString進(jìn)行存儲(chǔ)，拿出來(lái)再反序列話(huà)啥的。
我在這里就不討論這樣做的對(duì)錯(cuò)了，但是我還是希望大家能在最合適的場(chǎng)景使用最合適的數(shù)據(jù)結(jié)構(gòu)，對(duì)象找不到最合適的但是類(lèi)型可以選最合適的嘛，之后別人接手你的代碼一看這么規(guī)范，誒這小伙子有點(diǎn)東西呀，看到你啥都是用的String，垃圾！
好了這些都是題外話(huà)了，道理還是希望大家記在心里，習(xí)慣成自然嘛，小習(xí)慣成就你。
String的實(shí)際應(yīng)用場(chǎng)景比較廣泛的有：
緩存功能：String字符串是最常用的數(shù)據(jù)類(lèi)型，不僅僅是Redis，各個(gè)語(yǔ)言都是最基本類(lèi)型，因此，利用Redis作為緩存，配合其它數(shù)據(jù)庫(kù)作為存儲(chǔ)層，利用Redis支持高并發(fā)的特點(diǎn)，可以大大加快系統(tǒng)的讀寫(xiě)速度、以及降低后端數(shù)據(jù)庫(kù)的壓力。
計(jì)數(shù)器：許多系統(tǒng)都會(huì)使用Redis作為系統(tǒng)的實(shí)時(shí)計(jì)數(shù)器，可以快速實(shí)現(xiàn)計(jì)數(shù)和查詢(xún)的功能。而且最終的數(shù)據(jù)結(jié)果可以按照特定的時(shí)間落地到數(shù)據(jù)庫(kù)或者其它存儲(chǔ)介質(zhì)當(dāng)中進(jìn)行永久保存。
共享用戶(hù)Session：用戶(hù)重新刷新一次界面，可能需要訪(fǎng)問(wèn)一下數(shù)據(jù)進(jìn)行重新登錄，或者訪(fǎng)問(wèn)頁(yè)面緩存Cookie，但是可以利用Redis將用戶(hù)的Session集中管理，在這種模式只需要保證Redis的高可用，每次用戶(hù)Session的更新和獲取都可以快速完成。大大提高效率。
Hash：
這個(gè)是類(lèi)似 Map 的一種結(jié)構(gòu)，這個(gè)一般就是可以將結(jié)構(gòu)化的數(shù)據(jù)，比如一個(gè)對(duì)象（前提是這個(gè)對(duì)象沒(méi)嵌套其他的對(duì)象）給緩存在 Redis 里，然后每次讀寫(xiě)緩存的時(shí)候，可以就操作 Hash 里的某個(gè)字段。
但是這個(gè)的場(chǎng)景其實(shí)還是多少單一了一些，因?yàn)楝F(xiàn)在很多對(duì)象都是比較復(fù)雜的，比如你的商品對(duì)象可能里面就包含了很多屬性，其中也有對(duì)象。我自己使用的場(chǎng)景用得不是那么多。
List：
List 是有序列表，這個(gè)還是可以玩兒出很多花樣的。
比如可以通過(guò) List 存儲(chǔ)一些列表型的數(shù)據(jù)結(jié)構(gòu)，類(lèi)似粉絲列表、文章的評(píng)論列表之類(lèi)的東西。
比如可以通過(guò) lrange 命令，讀取某個(gè)閉區(qū)間內(nèi)的元素，可以基于 List 實(shí)現(xiàn)分頁(yè)查詢(xún)，這個(gè)是很棒的一個(gè)功能，基于 Redis 實(shí)現(xiàn)簡(jiǎn)單的高性能分頁(yè)，可以做類(lèi)似微博那種下拉不斷分頁(yè)的東西，性能高，就一頁(yè)一頁(yè)走。
比如可以搞個(gè)簡(jiǎn)單的消息隊(duì)列，從 List 頭懟進(jìn)去，從 List 屁股那里弄出來(lái)。
List本身就是我們?cè)陂_(kāi)發(fā)過(guò)程中比較常用的數(shù)據(jù)結(jié)構(gòu)了，熱點(diǎn)數(shù)據(jù)更不用說(shuō)了。
消息隊(duì)列：Redis的鏈表結(jié)構(gòu)，可以輕松實(shí)現(xiàn)阻塞隊(duì)列，可以使用左進(jìn)右出的命令組成來(lái)完成隊(duì)列的設(shè)計(jì)。比如：數(shù)據(jù)的生產(chǎn)者可以通過(guò)Lpush命令從左邊插入數(shù)據(jù)，多個(gè)數(shù)據(jù)消費(fèi)者，可以使用BRpop命令阻塞的“搶”列表尾部的數(shù)據(jù)。
文章列表或者數(shù)據(jù)分頁(yè)展示的應(yīng)用。
比如，我們常用的博客網(wǎng)站的文章列表，當(dāng)用戶(hù)量越來(lái)越多時(shí)，而且每一個(gè)用戶(hù)都有自己的文章列表，而且當(dāng)文章多時(shí)，都需要分頁(yè)展示，這時(shí)可以考慮使用Redis的列表，列表不但有序同時(shí)還支持按照范圍內(nèi)獲取元素，可以完美解決分頁(yè)查詢(xún)功能。大大提高查詢(xún)效率。
Set：
Set 是無(wú)序集合，會(huì)自動(dòng)去重的那種。
直接基于 Set 將系統(tǒng)里需要去重的數(shù)據(jù)扔進(jìn)去，自動(dòng)就給去重了，如果你需要對(duì)一些數(shù)據(jù)進(jìn)行快速的全局去重，你當(dāng)然也可以基于 JVM 內(nèi)存里的 HashSet 進(jìn)行去重，但是如果你的某個(gè)系統(tǒng)部署在多臺(tái)機(jī)器上呢？得基于Redis進(jìn)行全局的 Set 去重。
可以基于 Set 玩兒交集、并集、差集的操作，比如交集吧，我們可以把兩個(gè)人的好友列表整一個(gè)交集，看看倆人的共同好友是誰(shuí)？對(duì)吧。
反正這些場(chǎng)景比較多，因?yàn)閷?duì)比很快，操作也簡(jiǎn)單，兩個(gè)查詢(xún)一個(gè)Set搞定。
Sorted Set：
Sorted set 是排序的 Set，去重但可以排序，寫(xiě)進(jìn)去的時(shí)候給一個(gè)分?jǐn)?shù)，自動(dòng)根據(jù)分?jǐn)?shù)排序。
有序集合的使用場(chǎng)景與集合類(lèi)似，但是set集合不是自動(dòng)有序的，而Sorted set可以利用分?jǐn)?shù)進(jìn)行成員間的排序，而且是插入時(shí)就排序好。所以當(dāng)你需要一個(gè)有序且不重復(fù)的集合列表時(shí)，就可以選擇Sorted set數(shù)據(jù)結(jié)構(gòu)作為選擇方案。
排行榜：有序集合經(jīng)典使用場(chǎng)景。例如視頻網(wǎng)站需要對(duì)用戶(hù)上傳的視頻做排行榜，榜單維護(hù)可能是多方面：按照時(shí)間、按照播放量、按照獲得的贊數(shù)等。
用Sorted Sets來(lái)做帶權(quán)重的隊(duì)列，比如普通消息的score為1，重要消息的score為2，然后工作線(xiàn)程可以選擇按score的倒序來(lái)獲取工作任務(wù)。讓重要的任務(wù)優(yōu)先執(zhí)行。
微博熱搜榜，就是有個(gè)后面的熱度值，前面就是名稱(chēng)
高級(jí)用法：
Bitmap :
位圖是支持按 bit 位來(lái)存儲(chǔ)信息，可以用來(lái)實(shí)現(xiàn) 布隆過(guò)濾器（BloomFilter）；
HyperLogLog:
供不精確的去重計(jì)數(shù)功能，比較適合用來(lái)做大規(guī)模數(shù)據(jù)的去重統(tǒng)計(jì)，例如統(tǒng)計(jì) UV；
Geospatial:
可以用來(lái)保存地理位置，并作位置距離計(jì)算或者根據(jù)半徑計(jì)算位置等。有沒(méi)有想過(guò)用Redis來(lái)實(shí)現(xiàn)附近的人？或者計(jì)算最優(yōu)地圖路徑？
這三個(gè)其實(shí)也可以算作一種數(shù)據(jù)結(jié)構(gòu)，不知道還有多少朋友記得，我在夢(mèng)開(kāi)始的地方，Redis基礎(chǔ)中提到過(guò)，你如果只知道五種基礎(chǔ)類(lèi)型那只能拿60分，如果你能講出高級(jí)用法，那就覺(jué)得你有點(diǎn)東西。
pub/sub：
功能是訂閱發(fā)布功能，可以用作簡(jiǎn)單的消息隊(duì)列。
Pipeline：
可以批量執(zhí)行一組指令，一次性返回全部結(jié)果，可以減少頻繁的請(qǐng)求應(yīng)答。
Lua：
Redis 支持提交 Lua 腳本來(lái)執(zhí)行一系列的功能。
我在前電商老東家的時(shí)候，秒殺場(chǎng)景經(jīng)常使用這個(gè)東西，講道理有點(diǎn)香，利用他的原子性。
話(huà)說(shuō)你們想看秒殺的設(shè)計(jì)么？我記得我面試好像每次都問(wèn)啊，想看的直接點(diǎn)贊后評(píng)論秒殺吧。
事務(wù)：
最后一個(gè)功能是事務(wù)，但 Redis 提供的不是嚴(yán)格的事務(wù)，Redis 只保證串行執(zhí)行命令，并且能保證全部執(zhí)行，但是執(zhí)行命令失敗時(shí)并不會(huì)回滾，而是會(huì)繼續(xù)執(zhí)行下去。
持久化
Redis 提供了 RDB 和 AOF 兩種持久化方式，RDB 是把內(nèi)存中的數(shù)據(jù)集以快照形式寫(xiě)入磁盤(pán)，實(shí)際操作是通過(guò) fork 子進(jìn)程執(zhí)行，采用二進(jìn)制壓縮存儲(chǔ)；AOF 是以文本日志的形式記錄 Redis 處理的每一個(gè)寫(xiě)入或刪除操作。
RDB 把整個(gè) Redis 的數(shù)據(jù)保存在單一文件中，比較適合用來(lái)做災(zāi)備，但缺點(diǎn)是快照保存完成之前如果宕機(jī)，這段時(shí)間的數(shù)據(jù)將會(huì)丟失，另外保存快照時(shí)可能導(dǎo)致服務(wù)短時(shí)間不可用。
AOF 對(duì)日志文件的寫(xiě)入操作使用的追加模式，有靈活的同步策略，支持每秒同步、每次修改同步和不同步，缺點(diǎn)就是相同規(guī)模的數(shù)據(jù)集，AOF 要大于 RDB，AOF 在運(yùn)行效率上往往會(huì)慢于 RDB。
高可用
來(lái)看 Redis 的高可用。Redis 支持主從同步，提供 Cluster 集群部署模式，通過(guò) Sentine l哨兵來(lái)監(jiān)控 Redis 主服務(wù)器的狀態(tài)。當(dāng)主掛掉時(shí)，在從節(jié)點(diǎn)中根據(jù)一定策略選出新主，并調(diào)整其他從 slaveof 到新主。
選主的策略簡(jiǎn)單來(lái)說(shuō)有三個(gè)：
slave 的 priority 設(shè)置的越低，優(yōu)先級(jí)越高；
同等情況下，slave 復(fù)制的數(shù)據(jù)越多優(yōu)先級(jí)越高；
相同的條件下 runid 越小越容易被選中。
在 Redis 集群中，sentinel 也會(huì)進(jìn)行多實(shí)例部署，sentinel 之間通過(guò) Raft 協(xié)議來(lái)保證自身的高可用。
Redis Cluster 使用分片機(jī)制，在內(nèi)部分為 16384 個(gè) slot 插槽，分布在所有 master 節(jié)點(diǎn)上，每個(gè) master 節(jié)點(diǎn)負(fù)責(zé)一部分 slot。數(shù)據(jù)操作時(shí)按 key 做 CRC16 來(lái)計(jì)算在哪個(gè) slot，由哪個(gè) master 進(jìn)行處理。數(shù)據(jù)的冗余是通過(guò) slave 節(jié)點(diǎn)來(lái)保障。
哨兵
哨兵必須用三個(gè)實(shí)例去保證自己的健壯性的，哨兵+主從并不能保證數(shù)據(jù)不丟失，但是可以保證集群的高可用。
為啥必須要三個(gè)實(shí)例呢？我們先看看兩個(gè)哨兵會(huì)咋樣。
master宕機(jī)了 s1和s2兩個(gè)哨兵只要有一個(gè)認(rèn)為你宕機(jī)了就切換了，并且會(huì)選舉出一個(gè)哨兵去執(zhí)行故障，但是這個(gè)時(shí)候也需要大多數(shù)哨兵都是運(yùn)行的。
那這樣有啥問(wèn)題呢？M1宕機(jī)了，S1沒(méi)掛那其實(shí)是OK的，但是整個(gè)機(jī)器都掛了呢？哨兵就只剩下S2個(gè)裸屌了，沒(méi)有哨兵去允許故障轉(zhuǎn)移了，雖然另外一個(gè)機(jī)器上還有R1，但是故障轉(zhuǎn)移就是不執(zhí)行。
經(jīng)典的哨兵集群是這樣的：
M1所在的機(jī)器掛了，哨兵還有兩個(gè)，兩個(gè)人一看他不是掛了嘛，那我們就選舉一個(gè)出來(lái)執(zhí)行故障轉(zhuǎn)移不就好了。
暖男我，小的總結(jié)下哨兵組件的主要功能：
集群監(jiān)控：負(fù)責(zé)監(jiān)控 Redis master 和 slave 進(jìn)程是否正常工作。
消息通知：如果某個(gè) Redis 實(shí)例有故障，那么哨兵負(fù)責(zé)發(fā)送消息作為報(bào)警通知給管理員。
故障轉(zhuǎn)移：如果 master node 掛掉了，會(huì)自動(dòng)轉(zhuǎn)移到 slave node 上。
配置中心：如果故障轉(zhuǎn)移發(fā)生了，通知 client 客戶(hù)端新的 master 地址。
主從
提到這個(gè)，就跟我前面提到的數(shù)據(jù)持久化的RDB和AOF有著比密切的關(guān)系了。
我先說(shuō)下為啥要用主從這樣的架構(gòu)模式，前面提到了單機(jī)QPS是有上限的，而且Redis的特性就是必須支撐讀高并發(fā)的，那你一臺(tái)機(jī)器又讀又寫(xiě)，這誰(shuí)頂?shù)米“?/strong>，不當(dāng)人啊！但是你讓這個(gè)master機(jī)器去寫(xiě)，數(shù)據(jù)同步給別的slave機(jī)器，他們都拿去讀，分發(fā)掉大量的請(qǐng)求那是不是好很多，而且擴(kuò)容的時(shí)候還可以輕松實(shí)現(xiàn)水平擴(kuò)容。
你啟動(dòng)一臺(tái)slave 的時(shí)候，他會(huì)發(fā)送一個(gè)psync命令給master ，如果是這個(gè)slave第一次連接到master，他會(huì)觸發(fā)一個(gè)全量復(fù)制。master就會(huì)啟動(dòng)一個(gè)線(xiàn)程，生成RDB快照，還會(huì)把新的寫(xiě)請(qǐng)求都緩存在內(nèi)存中，RDB文件生成后，master會(huì)將這個(gè)RDB發(fā)送給slave的，slave拿到之后做的第一件事情就是寫(xiě)進(jìn)本地的磁盤(pán)，然后加載進(jìn)內(nèi)存，然后master會(huì)把內(nèi)存里面緩存的那些新命名都發(fā)給slave。
我發(fā)出來(lái)之后來(lái)自CSDN的網(wǎng)友：Jian_Shen_Zer 問(wèn)了個(gè)問(wèn)題：
主從同步的時(shí)候，新的slaver進(jìn)來(lái)的時(shí)候用RDB，那之后的數(shù)據(jù)呢？有新的數(shù)據(jù)進(jìn)入master怎么同步到slaver啊
敖丙答：笨，AOF嘛，增量的就像MySQL的Binlog一樣，把日志增量同步給從服務(wù)就好了
key 失效機(jī)制
Redis 的 key 可以設(shè)置過(guò)期時(shí)間，過(guò)期后 Redis 采用主動(dòng)和被動(dòng)結(jié)合的失效機(jī)制，一個(gè)是和 MC 一樣在訪(fǎng)問(wèn)時(shí)觸發(fā)被動(dòng)刪除，另一種是定期的主動(dòng)刪除。
緩存常見(jiàn)問(wèn)題
緩存更新方式
這是決定在使用緩存時(shí)就該考慮的問(wèn)題。
緩存的數(shù)據(jù)在數(shù)據(jù)源發(fā)生變更時(shí)需要對(duì)緩存進(jìn)行更新，數(shù)據(jù)源可能是 DB，也可能是遠(yuǎn)程服務(wù)。更新的方式可以是主動(dòng)更新。數(shù)據(jù)源是 DB 時(shí)，可以在更新完 DB 后就直接更新緩存。
當(dāng)數(shù)據(jù)源不是 DB 而是其他遠(yuǎn)程服務(wù)，可能無(wú)法及時(shí)主動(dòng)感知數(shù)據(jù)變更，這種情況下一般會(huì)選擇對(duì)緩存數(shù)據(jù)設(shè)置失效期，也就是數(shù)據(jù)不一致的最大容忍時(shí)間。
這種場(chǎng)景下，可以選擇失效更新，key 不存在或失效時(shí)先請(qǐng)求數(shù)據(jù)源獲取最新數(shù)據(jù)，然后再次緩存，并更新失效期。
但這樣做有個(gè)問(wèn)題，如果依賴(lài)的遠(yuǎn)程服務(wù)在更新時(shí)出現(xiàn)異常，則會(huì)導(dǎo)致數(shù)據(jù)不可用。改進(jìn)的辦法是異步更新，就是當(dāng)失效時(shí)先不清除數(shù)據(jù)，繼續(xù)使用舊的數(shù)據(jù)，然后由異步線(xiàn)程去執(zhí)行更新任務(wù)。這樣就避免了失效瞬間的空窗期。另外還有一種純異步更新方式，定時(shí)對(duì)數(shù)據(jù)進(jìn)行分批更新。實(shí)際使用時(shí)可以根據(jù)業(yè)務(wù)場(chǎng)景選擇更新方式。
數(shù)據(jù)不一致
第二個(gè)問(wèn)題是數(shù)據(jù)不一致的問(wèn)題，可以說(shuō)只要使用緩存，就要考慮如何面對(duì)這個(gè)問(wèn)題。緩存不一致產(chǎn)生的原因一般是主動(dòng)更新失敗，例如更新 DB 后，更新 Redis 因?yàn)榫W(wǎng)絡(luò)原因請(qǐng)求超時(shí)；或者是異步更新失敗導(dǎo)致。
解決的辦法是，如果服務(wù)對(duì)耗時(shí)不是特別敏感可以增加重試；如果服務(wù)對(duì)耗時(shí)敏感可以通過(guò)異步補(bǔ)償任務(wù)來(lái)處理失敗的更新，或者短期的數(shù)據(jù)不一致不會(huì)影響業(yè)務(wù)，那么只要下次更新時(shí)可以成功，能保證最終一致性就可以。
緩存穿透
緩存穿透。產(chǎn)生這個(gè)問(wèn)題的原因可能是外部的惡意攻擊，例如，對(duì)用戶(hù)信息進(jìn)行了緩存，但惡意攻擊者使用不存在的用戶(hù)id頻繁請(qǐng)求接口，導(dǎo)致查詢(xún)緩存不命中，然后穿透 DB 查詢(xún)依然不命中。這時(shí)會(huì)有大量請(qǐng)求穿透緩存訪(fǎng)問(wèn)到 DB。
解決的辦法如下。
對(duì)不存在的用戶(hù)，在緩存中保存一個(gè)空對(duì)象進(jìn)行標(biāo)記，防止相同 ID 再次訪(fǎng)問(wèn) DB。不過(guò)有時(shí)這個(gè)方法并不能很好解決問(wèn)題，可能導(dǎo)致緩存中存儲(chǔ)大量無(wú)用數(shù)據(jù)。
使用 BloomFilter 過(guò)濾器，BloomFilter 的特點(diǎn)是存在性檢測(cè)，如果 BloomFilter 中不存在，那么數(shù)據(jù)一定不存在；如果 BloomFilter 中存在，實(shí)際數(shù)據(jù)也有可能會(huì)不存在。非常適合解決這類(lèi)的問(wèn)題。
緩存擊穿
緩存擊穿，就是某個(gè)熱點(diǎn)數(shù)據(jù)失效時(shí)，大量針對(duì)這個(gè)數(shù)據(jù)的請(qǐng)求會(huì)穿透到數(shù)據(jù)源。
解決這個(gè)問(wèn)題有如下辦法。
可以使用互斥鎖更新，保證同一個(gè)進(jìn)程中針對(duì)同一個(gè)數(shù)據(jù)不會(huì)并發(fā)請(qǐng)求到 DB，減小 DB 壓力。
使用隨機(jī)退避方式，失效時(shí)隨機(jī) sleep 一個(gè)很短的時(shí)間，再次查詢(xún)，如果失敗再執(zhí)行更新。
針對(duì)多個(gè)熱點(diǎn) key 同時(shí)失效的問(wèn)題，可以在緩存時(shí)使用固定時(shí)間加上一個(gè)小的隨機(jī)數(shù)，避免大量熱點(diǎn) key 同一時(shí)刻失效。
緩存雪崩
緩存雪崩，產(chǎn)生的原因是緩存掛掉，這時(shí)所有的請(qǐng)求都會(huì)穿透到 DB。
解決方法：
使用快速失敗的熔斷策略，減少 DB 瞬間壓力；
使用主從模式和集群模式來(lái)盡量保證緩存服務(wù)的高可用。
實(shí)際場(chǎng)景中，這兩種方法會(huì)結(jié)合使用。
老朋友都知道為啥我沒(méi)有大篇幅介紹這個(gè)幾個(gè)點(diǎn)了吧，我在之前的文章實(shí)在是寫(xiě)得太詳細(xì)了，忍不住點(diǎn)贊那種，我這里就不做重復(fù)拷貝了。
《吊打面試官》系列-Redis基礎(chǔ)
《吊打面試官》系列-緩存雪崩、擊穿、穿透
《吊打面試官》系列-Redis哨兵、持久化、主從、手撕LRU
《吊打面試官》系列-Redis終章-凜冬將至、FPX-新王登基
考點(diǎn)與加分項(xiàng)
拿筆記一下！
考點(diǎn)
面試的時(shí)候問(wèn)你緩存，主要是考察緩存特性的理解，對(duì) MC、Redis 的特點(diǎn)和使用方式的掌握。
要知道緩存的使用場(chǎng)景，不同類(lèi)型緩存的使用方式，例如：
1.對(duì) DB 熱點(diǎn)數(shù)據(jù)進(jìn)行緩存減少 DB 壓力；對(duì)依賴(lài)的服務(wù)進(jìn)行緩存，提高并發(fā)性能；
2.單純 K-V 緩存的場(chǎng)景可以使用 MC，而需要緩存 list、set 等特殊數(shù)據(jù)格式，可以使用 Redis；
3.需要緩存一個(gè)用戶(hù)最近播放視頻的列表可以使用 Redis 的 list 來(lái)保存、需要計(jì)算排行榜數(shù)據(jù)時(shí)，可以使用 Redis 的 zset 結(jié)構(gòu)來(lái)保存。
要了解 MC 和 Redis 的常用命令，例如原子增減、對(duì)不同數(shù)據(jù)結(jié)構(gòu)進(jìn)行操作的命令等。
了解 MC 和 Redis 在內(nèi)存中的存儲(chǔ)結(jié)構(gòu)，這對(duì)評(píng)估使用容量會(huì)很有幫助。
了解 MC ?和 Redis 的數(shù)據(jù)失效方式和剔除策略，比如主動(dòng)觸發(fā)的定期剔除和被動(dòng)觸發(fā)延期剔除
要理解 Redis 的持久化、主從同步與 Cluster 部署的原理，比如 RDB 和 AOF 的實(shí)現(xiàn)方式與區(qū)別。
要知道緩存穿透、擊穿、雪崩分別的異同點(diǎn)以及解決方案。
不管你有沒(méi)有電商經(jīng)驗(yàn)我覺(jué)得你都應(yīng)該知道秒殺的具體實(shí)現(xiàn)，以及細(xì)節(jié)點(diǎn)。
……..
歡迎去GitHub補(bǔ)充
加分項(xiàng)
如果想要在面試中獲得更好的表現(xiàn)，還應(yīng)了解下面這些加分項(xiàng)。
是要結(jié)合實(shí)際應(yīng)用場(chǎng)景來(lái)介紹緩存的使用。例如調(diào)用后端服務(wù)接口獲取信息時(shí)，可以使用本地+遠(yuǎn)程的多級(jí)緩存；對(duì)于動(dòng)態(tài)排行榜類(lèi)的場(chǎng)景可以考慮通過(guò) Redis 的 Sorted set 來(lái)實(shí)現(xiàn)等等。
最好你有過(guò)分布式緩存設(shè)計(jì)和使用經(jīng)驗(yàn)，例如項(xiàng)目中在什么場(chǎng)景使用過(guò) Redis，使用了什么數(shù)據(jù)結(jié)構(gòu)，解決哪類(lèi)的問(wèn)題；使用 MC 時(shí)根據(jù)預(yù)估值大小調(diào)整 McSlab 分配參數(shù)等等。
最好可以了解緩存使用中可能產(chǎn)生的問(wèn)題。比如 Redis 是單線(xiàn)程處理請(qǐng)求，應(yīng)盡量避免耗時(shí)較高的單個(gè)請(qǐng)求任務(wù)，防止相互影響；Redis 服務(wù)應(yīng)避免和其他 CPU 密集型的進(jìn)程部署在同一機(jī)器；或者禁用 Swap 內(nèi)存交換，防止 Redis 的緩存數(shù)據(jù)交換到硬盤(pán)上，影響性能。再比如前面提到的 MC 鈣化問(wèn)題等等。
要了解 Redis 的典型應(yīng)用場(chǎng)景，例如，使用 Redis 來(lái)實(shí)現(xiàn)分布式鎖；使用 Bitmap 來(lái)實(shí)現(xiàn) BloomFilter，使用 HyperLogLog 來(lái)進(jìn)行 UV 統(tǒng)計(jì)等等。
知道 Redis4.0、5.0 中的新特性，例如支持多播的可持久化消息隊(duì)列 Stream；通過(guò) Module 系統(tǒng)來(lái)進(jìn)行定制功能擴(kuò)展等等。
……..
總結(jié)
以上是生活随笔為你收集整理的《吊打面试官》系列-Redis常见面试题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 15Python文件操作
- 下一篇： 数据库（壹）