全解析：從數(shù)據(jù)結(jié)構(gòu)到分布式鎖的復(fù)習(xí)體系)
8月準(zhǔn)備Java面試Redis這一塊是繞不開的高頻考點(diǎn)。無論是校招還是社招Redis 都是面試官最喜歡深挖的方向它不像 MySQL 那樣以背 SQL 為主而是可以通過數(shù)據(jù)結(jié)構(gòu)、緩存設(shè)計(jì)、分布式鎖、集群方案層層遞進(jìn)地考察候選人的實(shí)戰(zhàn)能力。網(wǎng)上關(guān)于 Redis 面試題的資料很零散不少文章只給結(jié)論不給原理看完記住結(jié)論面試官多問一句“為什么”就容易露餡。這篇文章會(huì)把 Redis 面試中最核心的知識(shí)點(diǎn)整理成一套完整的復(fù)習(xí)體系按照“概念-數(shù)據(jù)結(jié)構(gòu)-持久化-緩存問題-分布式鎖-集群-排錯(cuò)-復(fù)習(xí)路線”的順序展開。每部分都會(huì)給出面試中高頻的問題、標(biāo)準(zhǔn)的回答思路、容易踩的坑以及配套的命令和代碼示例。不管你是剛開始準(zhǔn)備面試還是已經(jīng)進(jìn)入沖刺階段都可以直接對(duì)照這篇文章查漏補(bǔ)缺。先把這份內(nèi)容存下面試前翻一遍確實(shí)能少走很多彎路。1. 先搞清楚 Redis 在面試中到底考什么1.1 Redis 是什么為什么面試必考RedisRemote Dictionary Server是一個(gè)基于內(nèi)存的鍵值型 NoSQL 數(shù)據(jù)庫(kù)。它的核心特點(diǎn)是所有數(shù)據(jù)都存儲(chǔ)在內(nèi)存中所以讀寫速度非?？旃俜浇o出的基準(zhǔn)測(cè)試中單實(shí)例 QPS 可以達(dá)到 10 萬(wàn)級(jí)別。同時(shí)它支持持久化、過期策略、發(fā)布訂閱、事務(wù)、Lua 腳本、分布式鎖、集群擴(kuò)展等豐富的功能所以在互聯(lián)網(wǎng)項(xiàng)目中Redis 主要用于緩存、會(huì)話共享、排行榜、分布式鎖、消息隊(duì)列等場(chǎng)景。面試中考察 Redis本質(zhì)上是從三個(gè)維度進(jìn)行面試者是否掌握 Redis 的數(shù)據(jù)模型和常用命令。面試者是否理解 Redis 的底層機(jī)制比如持久化、淘汰策略、線程模型。面試者是否具備在真實(shí)項(xiàng)目中解決緩存問題、設(shè)計(jì)分布式方案的能力。這三個(gè)維度由淺入深正好對(duì)應(yīng)面試官追問的節(jié)奏。如果只是背題不深入很容易在追問環(huán)節(jié)被識(shí)別出來。1.2 Redis 和 MySQL 有什么區(qū)別這是面試開場(chǎng)高頻題。標(biāo)準(zhǔn)的回答思路是MySQL 是關(guān)系型數(shù)據(jù)庫(kù)數(shù)據(jù)存儲(chǔ)在磁盤上支持復(fù)雜的 SQL 查詢、事務(wù) ACID、表關(guān)聯(lián)。Redis 是基于內(nèi)存的鍵值存儲(chǔ)讀寫速度快但一般不作為唯一數(shù)據(jù)源而是作為緩存層加速訪問。Redis 支持的數(shù)據(jù)類型更豐富如 String、Hash、List、Set、ZSet每種類型都有自己的適用場(chǎng)景。MySQL 的數(shù)據(jù)一致性由事務(wù)保證Redis 在持久化上存在丟數(shù)據(jù)的可能取決于持久化策略所以兩者一般是配合使用?；卮饡r(shí)要強(qiáng)調(diào)“Redis 不是用來替代 MySQL 的而是為了提升系統(tǒng)的讀取性能”。如果面試官問“為什么不直接用 Redis 存所有數(shù)據(jù)”可以從成本、內(nèi)存容量、事務(wù)能力、持久化能力等方面回答。1.3 Redis 為什么快這個(gè)問題基本必問回答要點(diǎn)可以歸納為四點(diǎn)純內(nèi)存操作。數(shù)據(jù)放在內(nèi)存中讀寫不涉及磁盤 IO。單線程模型。Redis 網(wǎng)絡(luò)請(qǐng)求處理使用單線程避免了多線程上下文切換和鎖競(jìng)爭(zhēng)的開銷。注意Redis 6.0 之后引入了多線程 IO但核心命令執(zhí)行仍然是單線程的。IO 多路復(fù)用。Redis 基于 epoll 實(shí)現(xiàn) IO 多路復(fù)用可以在一個(gè)線程里處理多個(gè)連接的讀寫事件。高效的數(shù)據(jù)結(jié)構(gòu)。Redis 底層使用 SDS、跳表、壓縮列表、哈希表等高效結(jié)構(gòu)在不同數(shù)據(jù)量和場(chǎng)景下自動(dòng)選擇最優(yōu)編碼。面試官可能會(huì)追問“單線程為什么還這么快”核心原因就是 CPU 不是瓶頸內(nèi)存和網(wǎng)絡(luò)的 IO 才是瓶頸而單線程避免了鎖和上下文切換。2. Redis 核心數(shù)據(jù)結(jié)構(gòu)與常見面試問題2.1 String 字符串String 是 Redis 最基礎(chǔ)的數(shù)據(jù)類型value 最大能存儲(chǔ) 512MB。底層實(shí)現(xiàn)是 SDSSimple Dynamic String相比 C 字符串SDS 可以 O(1) 獲取長(zhǎng)度、避免緩沖區(qū)溢出、減少內(nèi)存重分配次數(shù)。常用命令SET key value GET key INCR key DECR key EXPIRE key seconds SETEX key seconds valueString 的典型應(yīng)用場(chǎng)景緩存用戶信息、配置數(shù)據(jù)。計(jì)數(shù)器如點(diǎn)贊數(shù)、訪問量。分布式 ID 生成利用 INCR 命令生成遞增序列。分布式鎖的SET key value NX EX也是基于 String 實(shí)現(xiàn)的。面試題舉例“String 的底層實(shí)現(xiàn)是什么和傳統(tǒng) C 字符串有什么不同”回答時(shí)把 SDS 的動(dòng)態(tài)擴(kuò)容、二進(jìn)制安全、獲取長(zhǎng)度 O(1) 這三個(gè)特點(diǎn)說出來即可。2.2 Hash 哈希Hash 類型是一個(gè) string 類型的 field 和 value 的映射表適合存儲(chǔ)對(duì)象數(shù)據(jù)。比如一個(gè)用戶對(duì)象包含 id、name、age如果用 String 存儲(chǔ)需要序列化整個(gè)對(duì)象更新某個(gè)字段要重新寫入整個(gè)對(duì)象用 Hash 則可以直接更新某個(gè)字段。常用命令HSET user:1001 name zhangsan HGET user:1001 name HGETALL user:1001 HDEL user:1001 name HINCRBY user:1001 age 1Hash 底層在數(shù)據(jù)量小的時(shí)候使用壓縮列表ziplist數(shù)據(jù)量大時(shí)轉(zhuǎn)為哈希表hashtable。因?yàn)?Redis 3.2 之后引入了 listpack不同版本的編碼細(xì)節(jié)略有差異但面試中掌握“小數(shù)據(jù)量壓縮存儲(chǔ)、大數(shù)據(jù)量哈希表”這個(gè)思路就夠了。面試題舉例“Hash 和 String 都存對(duì)象怎么選”一般推薦對(duì)象字段頻繁修改、只需要部分字段時(shí)用 Hash對(duì)象整體讀取、轉(zhuǎn)發(fā)給前端時(shí)用 String JSON 更省內(nèi)存且直觀。2.3 List 列表List 是簡(jiǎn)單的字符串列表按照插入順序排序可以從頭部或尾部添加元素。底層在元素少時(shí)使用壓縮列表元素多時(shí)轉(zhuǎn)為雙向鏈表quicklist 是 Redis 3.2 之后引入的混合結(jié)構(gòu)。常用命令LPUSH key value [value ...] RPUSH key value [value ...] LPOP key RPOP key LRANGE key start stop LLEN key典型應(yīng)用場(chǎng)景消息隊(duì)列LPUSH BRPOP 實(shí)現(xiàn)簡(jiǎn)單的生產(chǎn)消費(fèi)模型。最新動(dòng)態(tài)列表用 LPUSH 把新數(shù)據(jù)放到頭部用 LRANGE 分頁(yè)查詢。時(shí)間線列表關(guān)注的人發(fā)布動(dòng)態(tài)后推送到自己的 List 中。面試題舉例“List 和 Stream 做消息隊(duì)列有什么區(qū)別”List 結(jié)構(gòu)簡(jiǎn)單但無法支持消費(fèi)組、消息確認(rèn)等特性Redis Stream5.0 引入支持消費(fèi)者組、消息持久化、ACK 確認(rèn)更適合可靠性要求更高的場(chǎng)景。2.4 Set 集合Set 是無序、不可重復(fù)的字符串集合。集合操作支持交集、并集、差集這是它在業(yè)務(wù)中最大的價(jià)值。常用命令SADD key member [member ...] SMEMBERS key SREM key member SISMEMBER key member SINTER key1 key2 # 交集 SUNION key1 key2 # 并集 SDIFF key1 key2 # 差集典型應(yīng)用場(chǎng)景抽獎(jiǎng)去重用戶參與抽獎(jiǎng)SADD 時(shí)自動(dòng)去重。共同關(guān)注用 SINTER 獲取兩個(gè)用戶的共同關(guān)注列表。標(biāo)簽系統(tǒng)給文章打標(biāo)簽用 SMEMBERS 查詢標(biāo)簽用 SINTER 查同時(shí)包含多個(gè)標(biāo)簽的文章。2.5 ZSet 有序集合ZSet 在 Set 的基礎(chǔ)上給每個(gè)成員增加了一個(gè) score分值Redis 根據(jù) score 自動(dòng)排序。底層實(shí)現(xiàn)是跳表skiplist加哈希表。常用命令ZADD key score member ZRANGE key start stop ZREVRANGE key start stop ZSCORE key member ZINCRBY key increment member ZRANK key member典型應(yīng)用場(chǎng)景排行榜。比如游戲積分排行榜、商品銷量榜用 ZINCRBY 增加分?jǐn)?shù)用 ZREVRANGE 獲取 Top N。延遲隊(duì)列。把任務(wù)執(zhí)行時(shí)間作為 score用一個(gè)線程輪詢 ZRANGEBYSCORE 獲取到期的任務(wù)?；瑒?dòng)窗口限流。用 score 存時(shí)間戳通過 ZRANGEBYSCORE 統(tǒng)計(jì)時(shí)間窗口內(nèi)的請(qǐng)求數(shù)。面試中經(jīng)常追問“ZSet 的底層結(jié)構(gòu)為什么用跳表而不是紅黑樹”回答要點(diǎn)跳表實(shí)現(xiàn)簡(jiǎn)單、支持范圍查詢、在有序集合的場(chǎng)景下性能足夠O(log N)而且跳表更適合做范圍查找ZSet 的核心操作就是按分?jǐn)?shù)范圍取數(shù)據(jù)。2.6 其他高級(jí)數(shù)據(jù)類型面試加分項(xiàng)Bitmap位圖用位操作存儲(chǔ)布爾型數(shù)據(jù)典型場(chǎng)景是用戶簽到、在線狀態(tài)。HyperLogLog去重計(jì)數(shù)內(nèi)存極小適合統(tǒng)計(jì) UV。GEO地理位置存儲(chǔ)適合“附近的人”功能。Stream可靠消息隊(duì)列支持消費(fèi)者組。這部分可以展示知識(shí)廣度面試官如果追問能說出“GEO 底層基于 ZSet 實(shí)現(xiàn)每個(gè)位置的經(jīng)緯度會(huì)被編碼為 score”這種程度就夠用了。3. Redis 持久化機(jī)制RDB 和 AOF3.1 為什么需要持久化Redis 是內(nèi)存型數(shù)據(jù)庫(kù)如果進(jìn)程異常退出或服務(wù)器宕機(jī)內(nèi)存中的數(shù)據(jù)會(huì)全部丟失。持久化的目的就是把內(nèi)存中的數(shù)據(jù)保存到磁盤上使 Redis 重啟時(shí)能夠恢復(fù)數(shù)據(jù)。面試中問到持久化通常圍繞兩個(gè)問題RDB 和 AOF 分別是什么如何選擇3.2 RDB 快照持久化RDBRedis DataBase是在指定時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤生成一個(gè)二進(jìn)制的 dump.rdb 文件。觸發(fā)方式# 手動(dòng)觸發(fā) SAVE BGSAVE # 自動(dòng)觸發(fā)在 redis.conf 中配置 save 900 1 save 300 10 save 60 10000SAVE 會(huì)阻塞 Redis 主進(jìn)程BGSAVE 會(huì) fork 子進(jìn)程來生成 RDB主進(jìn)程繼續(xù)處理命令。面試中需要說清楚RDB 的優(yōu)點(diǎn)是文件緊湊、恢復(fù)速度快、適合做備份和災(zāi)難恢復(fù)缺點(diǎn)是可能丟失最后一次快照之后的數(shù)據(jù)同時(shí) fork 子進(jìn)程在大數(shù)據(jù)量下會(huì)有短暫的阻塞。3.3 AOF 追加持久化AOFAppend Of File會(huì)把每次寫命令追加到 aof 文件末尾。Redis 重啟時(shí)通過重新執(zhí)行 AOF 文件中的命令來恢復(fù)數(shù)據(jù)。AOF 默認(rèn)是關(guān)閉的開啟配置appendonly yes appendfilename appendonly.aof appendfsync always appendfsync everysec appendfsync no配置項(xiàng)說明always每次寫入都同步到磁盤數(shù)據(jù)最安全性能最差。everysec每秒同步一次最多丟失 1 秒數(shù)據(jù)是推薦配置。no由操作系統(tǒng)決定什么時(shí)候同步性能好但安全性不可控。為了避免 AOF 文件過大Redis 提供了 AOF 重寫機(jī)制通過BGREWRITEAOF命令或自動(dòng)觸發(fā)用盡可能少的命令來記錄當(dāng)前數(shù)據(jù)集。3.4 RDB 和 AOF 怎么選對(duì)比項(xiàng)RDBAOF文件大小二進(jìn)制壓縮文件小記錄寫命令文件較大恢復(fù)速度快較慢數(shù)據(jù)安全性可能丟較多數(shù)據(jù)最多丟 1 秒everysec對(duì)性能影響fork 子進(jìn)程可能瞬間阻塞寫頻率高時(shí)影響較大生產(chǎn)環(huán)境常用的方案是同時(shí)開啟 RDB 和 AOF。Redis 優(yōu)先使用 AOF 恢復(fù)數(shù)據(jù)因?yàn)?AOF 數(shù)據(jù)更完整同時(shí)利用 RDB 做定期備份。如果對(duì)數(shù)據(jù)丟失容忍度很低必須開啟 AOF 并設(shè)置 appendfsync everysec。4. 緩存設(shè)計(jì)穿透、擊穿、雪崩與解決方案4.1 緩存穿透緩存穿透是指查詢一個(gè)不存在的數(shù)據(jù)緩存中沒有數(shù)據(jù)庫(kù)中也沒有導(dǎo)致每次請(qǐng)求都直接打到數(shù)據(jù)庫(kù)。如果有惡意攻擊者持續(xù)構(gòu)造不存在的 key數(shù)據(jù)庫(kù)壓力驟增。解決方案緩存空值查詢結(jié)果為空也緩存設(shè)置較短的過期時(shí)間。布隆過濾器把所有可能存在的數(shù)據(jù)哈希到一個(gè) bitmap 中請(qǐng)求先經(jīng)過布隆過濾器過濾掉大部分不存在的 key。參數(shù)校驗(yàn)在接口層攔截明顯不合法的請(qǐng)求。示例代碼緩存空值使用 Spring Data Redispublic Object getData(String key) { Object value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } // 模擬從數(shù)據(jù)庫(kù)查詢 Object dbValue queryFromDB(key); if (dbValue null) { // 緩存空值防止穿透過期時(shí)間設(shè)置短一些 redisTemplate.opsForValue().set(key, , 60, TimeUnit.SECONDS); } else { redisTemplate.opsForValue().set(key, dbValue, 30, TimeUnit.MINUTES); } return dbValue; }4.2 緩存擊穿緩存擊穿是指某個(gè)熱點(diǎn) key 剛好在過期時(shí)間失效此時(shí)大量并發(fā)請(qǐng)求同時(shí)查詢這個(gè) key緩存未命中請(qǐng)求全部打到數(shù)據(jù)庫(kù)。解決方案互斥鎖只允許一個(gè)線程查數(shù)據(jù)庫(kù)并重建緩存其他線程等待。邏輯過期緩存中不設(shè)置物理過期時(shí)間而是存儲(chǔ)一個(gè)邏輯過期時(shí)間字段查詢時(shí)判斷是否過期如果過期則異步重建緩存。熱點(diǎn)數(shù)據(jù)永不過期在 value 中保存過期時(shí)間業(yè)務(wù)層判斷后異步更新。這里給出基于互斥鎖的簡(jiǎn)化示例public String getHotData(String key) { String value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } String lockKey lock: key; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 3, TimeUnit.SECONDS); if (locked) { try { value queryFromDB(key); redisTemplate.opsForValue().set(key, value, 30, TimeUnit.MINUTES); return value; } finally { redisTemplate.delete(lockKey); } } else { // 等待其他線程寫入緩存 try { Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return getHotData(key); } }互斥鎖方案簡(jiǎn)單有效代價(jià)是緩存重建期間有少量線程等待。實(shí)際項(xiàng)目中要重點(diǎn)關(guān)注鎖的釋放避免因異常導(dǎo)致鎖無法釋放。4.3 緩存雪崩緩存雪崩是指大量 key 在同一時(shí)間失效或者 Redis 服務(wù)宕機(jī)導(dǎo)致所有請(qǐng)求直接打到數(shù)據(jù)庫(kù)。解決方案過期時(shí)間隨機(jī)化在設(shè)置過期時(shí)間時(shí)加上一個(gè)隨機(jī)值避免同一時(shí)間大面積失效。Redis 集群高可用使用主從復(fù)制、哨兵或 Cluster 模式避免單點(diǎn)故障。多級(jí)緩存本地緩存如 Caffeine Redis 緩存即使 Redis 不可用本地緩存也能扛一部分流量。服務(wù)降級(jí)在數(shù)據(jù)庫(kù)層增加限流和降級(jí)策略保護(hù)數(shù)據(jù)庫(kù)不被壓垮。面試中更好的回答是“緩存雪崩的重點(diǎn)不是如何保證 Redis 不宕機(jī)而是要在 Redis 不可用或緩存大規(guī)模失效時(shí)系統(tǒng)依然能通過降級(jí)、限流、多級(jí)緩存等手段保持可用?！?.4 緩存一致性問題只要用 Redis 做緩存就繞不開“緩存和數(shù)據(jù)庫(kù)數(shù)據(jù)不一致”的問題。常見的方案Cache Aside Pattern旁路緩存讀的時(shí)候先讀緩存緩存沒有則讀數(shù)據(jù)庫(kù)并回填寫的時(shí)候先更新數(shù)據(jù)庫(kù)再刪除緩存。延遲雙刪更新數(shù)據(jù)庫(kù)后刪除緩存等一段時(shí)間再次刪除避免并發(fā)下讀到舊數(shù)據(jù)。基于 Canal 監(jiān)聽 MySQL binlog異步更新緩存。面試中不要只說一個(gè)方案要能分析利弊。比較推薦的回答一般業(yè)務(wù)采用 Cache Aside 模式更新時(shí)“先更新數(shù)據(jù)庫(kù)再刪除緩存”如果要求更高的一致性可以引入分布式事務(wù)或 binlog 異步同步但這會(huì)增加系統(tǒng)復(fù)雜度需要根據(jù)業(yè)務(wù)權(quán)衡。5. Redis 分布式鎖5.1 為什么要用分布式鎖在分布式系統(tǒng)中多個(gè)服務(wù)實(shí)例同時(shí)操作共享資源時(shí)Java 的synchronized和ReentrantLock只能鎖住當(dāng)前 JVM 內(nèi)的線程無法跨進(jìn)程互斥。分布式鎖就是讓多個(gè)進(jìn)程之間通過 Redis 實(shí)現(xiàn)互斥訪問。5.2 基于 Redis 實(shí)現(xiàn)分布式鎖的演進(jìn)最早的方案是使用SETNX加鎖然后EXPIRE設(shè)置過期時(shí)間但這兩個(gè)命令不是原子的如果在 SETNX 之后、EXPIRE 之前進(jìn)程崩潰鎖就會(huì)永遠(yuǎn)不釋放。后來 Redis 官方推薦使用SET key value NX EX seconds一條命令完成加鎖和過期時(shí)間設(shè)置。加鎖命令SET lock:order:1001 uuid_value NX EX 30釋放鎖時(shí)不能直接DEL因?yàn)槿绻i已經(jīng)過期另一個(gè)線程獲取了同一把鎖當(dāng)前線程再執(zhí)行 DEL 就會(huì)誤刪別人的鎖。所以釋放鎖需要先比較 value 是否還是自己的再刪除這個(gè)過程要用 Lua 腳本保證原子性-- 釋放鎖的 Lua 腳本 if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 endJava 中通過 Spring Data Redis 執(zhí)行 Lua 腳本private static final String UNLOCK_SCRIPT if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; public void unlock(String lockKey, String requestId) { DefaultRedisScriptLong script new DefaultRedisScript(UNLOCK_SCRIPT, Long.class); redisTemplate.execute(script, Arrays.asList(lockKey), requestId); }5.3 Redisson 與看門狗機(jī)制手寫分布式鎖需要處理各種邊界條件生產(chǎn)環(huán)境推薦使用 Redisson。Redisson 提供了RLock內(nèi)部通過 Lua 腳本實(shí)現(xiàn)加鎖、解鎖、重入還提供了看門狗機(jī)制如果鎖的持有者沒有顯式釋放鎖看門狗會(huì)每隔一段時(shí)間自動(dòng)續(xù)期防止業(yè)務(wù)沒執(zhí)行完鎖就過期了。RLock lock redissonClient.getLock(lock:order:1001); try { // 嘗試加鎖最多等待 5 秒鎖有效期默認(rèn) 30 秒看門狗會(huì)自動(dòng)續(xù)期 if (lock.tryLock(5, TimeUnit.SECONDS)) { // 業(yè)務(wù)邏輯 } } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }5.4 RedLock 有必要用嗎RedLock 是 Redis 官方提出的多節(jié)點(diǎn)分布式鎖算法要求向多個(gè)獨(dú)立的 Redis 主節(jié)點(diǎn)加鎖超過半數(shù)成功才算加鎖成功。面試中經(jīng)常被問到但實(shí)際項(xiàng)目中較少使用因?yàn)?RedLock 依賴時(shí)鐘同步、網(wǎng)絡(luò)延遲實(shí)現(xiàn)復(fù)雜且在多主切換下仍存在一致性問題。推薦回答思路“單節(jié)點(diǎn) Redis 鎖 Redisson 的看門狗在絕大多數(shù)業(yè)務(wù)中已經(jīng)夠用如果要更強(qiáng)的安全性優(yōu)先考慮 ZooKeeper 或 etcd 的分布式鎖而不是 RedLock?！?. Redis 集群與可用性6.1 主從復(fù)制Redis 主從復(fù)制是指一臺(tái)主節(jié)點(diǎn)Master將數(shù)據(jù)同步到多臺(tái)從節(jié)點(diǎn)Slave實(shí)現(xiàn)讀寫分離和容災(zāi)。主節(jié)點(diǎn)負(fù)責(zé)寫操作從節(jié)點(diǎn)負(fù)責(zé)讀操作數(shù)據(jù)由主節(jié)點(diǎn)單向同步到從節(jié)點(diǎn)。順序上主從復(fù)制分為兩個(gè)階段全量復(fù)制從節(jié)點(diǎn)首次同步時(shí)主節(jié)點(diǎn)生成 RDB 快照并發(fā)送給從節(jié)點(diǎn)。增量復(fù)制后續(xù)主節(jié)點(diǎn)把寫命令發(fā)送給從節(jié)點(diǎn)。從節(jié)點(diǎn)斷開重連后主節(jié)點(diǎn)通過復(fù)制積壓緩沖區(qū)同步斷連期間的數(shù)據(jù)。配置方式# 從節(jié)點(diǎn)配置 replicaof 127.0.0.1 63796.2 哨兵模式主從復(fù)制解決了數(shù)據(jù)備份和讀寫分離但主節(jié)點(diǎn)宕機(jī)后需要人工把某個(gè)從節(jié)點(diǎn)提升為主節(jié)點(diǎn)。哨兵Sentinel可以自動(dòng)監(jiān)控主節(jié)點(diǎn)和從節(jié)點(diǎn)的健康狀態(tài)在主節(jié)點(diǎn)故障時(shí)自動(dòng)完成故障轉(zhuǎn)移從剩余從節(jié)點(diǎn)中選舉新的主節(jié)點(diǎn)。哨兵的關(guān)鍵作用監(jiān)控檢查主從節(jié)點(diǎn)的運(yùn)行狀態(tài)。通知節(jié)點(diǎn)故障時(shí)通知其他實(shí)例。自動(dòng)故障轉(zhuǎn)移主節(jié)點(diǎn)不可用時(shí)自動(dòng)選舉新的主節(jié)點(diǎn)。配置中心客戶端通過哨兵獲取當(dāng)前主節(jié)點(diǎn)地址。6.3 Cluster 集群模式Redis Cluster 是 Redis 3.0 引入的分布式解決方案能夠?qū)?shù)據(jù)自動(dòng)分片到多個(gè)節(jié)點(diǎn)上每個(gè)節(jié)點(diǎn)保存一部分?jǐn)?shù)據(jù)。Redis Cluster 采用無中心化架構(gòu)節(jié)點(diǎn)之間通過 Gossip 協(xié)議通信。分片原理整個(gè)數(shù)據(jù)空間被劃分為 16384 個(gè)哈希槽slot。每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分 slot例如三主節(jié)點(diǎn)分別負(fù)責(zé) 0~5460、5461~10922、10923~16383。計(jì)算 key 的 CRC16 值然后對(duì) 16384 取模得到該 key 應(yīng)該存儲(chǔ)到哪個(gè) slot。Cluster 模式的優(yōu)勢(shì)是支持水平擴(kuò)展性能隨節(jié)點(diǎn)增加而提升。需要注意的坑是 Cluster 模式下不支持多 key 操作除非這些 key 在同一個(gè) slot因此需要使用 Hash Tag 技術(shù)讓相關(guān) key 落到同一個(gè)槽位。面試常見問題“為什么 Redis Cluster 是 16384 個(gè)槽”常見的解釋是16384 個(gè)槽在保證數(shù)據(jù)分布均勻的同時(shí)可以使節(jié)點(diǎn)間心跳消息中的位圖更小減少帶寬消耗且對(duì)于常用規(guī)模的集群已經(jīng)足夠。6.4 一致性哈希和哈希槽可能被追問“Redis 為什么不用一致性哈?！?。一致性哈希是分布式緩存中常用的分片算法如 Memcached但 Redis Cluster 選擇哈希槽的原因主要有哈希槽將數(shù)據(jù)分成固定數(shù)量的槽位節(jié)點(diǎn)增減時(shí)只需要遷移部分槽位數(shù)據(jù)遷移范圍可控。槽位和節(jié)點(diǎn)的映射關(guān)系明確客戶端可以精確計(jì)算 key 所在節(jié)點(diǎn)。數(shù)據(jù)遷移時(shí)是以槽為單位進(jìn)行操作粒度更清晰。7. Redis 內(nèi)存淘汰與常見問題排查7.1 過期刪除策略Redis 的過期刪除策略是“惰性刪除 定期刪除”的結(jié)合惰性刪除訪問 key 時(shí)檢查是否過期過期則刪除。優(yōu)點(diǎn)是不占用額外 CPU缺點(diǎn)是過期 key 可能長(zhǎng)期占用內(nèi)存。定期刪除Redis 每隔一段時(shí)間隨機(jī)抽取一部分設(shè)置了過期時(shí)間的 key刪除其中已過期的 key。7.2 內(nèi)存淘汰策略當(dāng) Redis 內(nèi)存達(dá)到maxmemory限制后會(huì)根據(jù)配置的maxmemory-policy進(jìn)行淘汰。常見配置項(xiàng)策略含義noeviction不淘汰寫入時(shí)報(bào)錯(cuò)allkeys-lru從所有 key 中按 LRU 淘汰volatile-lru從設(shè)置了過期時(shí)間的 key 中按 LRU 淘汰allkeys-lfu從所有 key 中按 LFU 淘汰volatile-lfu從設(shè)置了過期時(shí)間的 key 中按 LFU 淘汰allkeys-random從所有 key 中隨機(jī)淘汰volatile-ttl從設(shè)置了過期時(shí)間且剩余時(shí)間最短的 key 中淘汰面試中回答“生產(chǎn)環(huán)境推薦哪種策略”時(shí)不要直接說“用 allkeys-lru”。正確的思路是優(yōu)先給每個(gè) key 設(shè)置合理的過期時(shí)間根據(jù)業(yè)務(wù)是否允許緩存丟失決定使用 volatile-lru 還是 allkeys-lru如果業(yè)務(wù)數(shù)據(jù)要求嚴(yán)格不淘汰則使用 noeviction 并做好告警。7.3 內(nèi)存不足報(bào)錯(cuò) OutOfMemoryErrorJVM 項(xiàng)目和 Redis 都會(huì)出現(xiàn)內(nèi)存不足的報(bào)錯(cuò)。熱詞中出現(xiàn)的java: outofmemoryerror: insufficient memory屬于 JVM 啟動(dòng)時(shí)內(nèi)存不足常見原因是啟動(dòng) JVM 時(shí)指定的 -Xmx 大于物理內(nèi)存。服務(wù)器內(nèi)存被其他進(jìn)程占用剩余可用內(nèi)存不足。系統(tǒng)沒有足夠交換空間。排查方法# 查看系統(tǒng)內(nèi)存 free -h # 查看 Java 進(jìn)程內(nèi)存占用 ps aux | grep java jmap -heap pid如果 Redis 本身內(nèi)存不足可以檢查maxmemory配置、大 key、連接數(shù)、內(nèi)存碎片率必要時(shí)擴(kuò)容或清理大 key。7.4 連接失敗和超時(shí)Redis 連接失敗通常表現(xiàn)為ERR max number of clients reached或RedisConnectionFailureException。排查思路檢查 Redis 服務(wù)是否啟動(dòng)redis-cli ping。檢查端口連通性telnet 127.0.0.1 6379。檢查客戶端最大連接數(shù)配置CONFIG GET maxclients。檢查防火墻和遠(yuǎn)程訪問配置bind、protected-mode。檢查業(yè)務(wù)代碼是否存在連接池泄漏用完連接沒有釋放。Spring Boot 中可以通過配置連接池參數(shù)優(yōu)化spring.redis.hostlocalhost spring.redis.port6379 spring.redis.lettuce.pool.max-active50 spring.redis.lettuce.pool.max-idle20 spring.redis.lettuce.pool.min-idle5 spring.redis.lettuce.pool.max-wait3000ms7.5 熱詞背后的 Redis 高頻面試題庫(kù)根據(jù)搜索熱詞高頻被搜的還有redis 下載、windows 安裝 redis、docker 安裝 redis 主從、redis desktop manager 可視化客戶端、redis 緩存治理。這些屬于環(huán)境搭建和運(yùn)維工具建議在復(fù)習(xí)基礎(chǔ)知識(shí)的同時(shí)把本機(jī)環(huán)境搭好用 Redis Desktop Manager 或 Another Redis Desktop Manager 連一次能加深對(duì) Redis 數(shù)據(jù)結(jié)構(gòu)的印象。8. 三天沖刺計(jì)劃與復(fù)習(xí)建議8.1 第 1 天數(shù)據(jù)結(jié)構(gòu)與基礎(chǔ)命令把 String、Hash、List、Set、ZSet 的常用命令全部敲一遍。理解每個(gè)類型的底層編碼和適用場(chǎng)景。用 Spring Data Redis 寫一個(gè)增刪改查的小 Demo。當(dāng)天結(jié)束前完成自測(cè)能默寫每種數(shù)據(jù)類型至少兩個(gè)應(yīng)用場(chǎng)景。8.2 第 2 天持久化、緩存問題與分布式鎖配置 RDB 和 AOF觀察 dump.rdb 和 appendonly.aof 文件的生成。手寫緩存穿透、擊穿、雪崩的解決方案示例。手寫 SET NX EX 分布式鎖和 Lua 解鎖腳本?？赐?Redisson 官方文檔了解 RLock 基本用法。8.3 第 3 天集群、運(yùn)維與面試模擬用 Docker 搭建一主兩從、哨兵或 Cluster 環(huán)境。檢查 Redis 日志分析主從復(fù)制和故障轉(zhuǎn)移的過程。把高頻面試題制作成卡片按“先結(jié)論后原理再舉例”的方式模擬作答。# Docker 搭建 Redis 主從示例 docker run -d --name redis-master -p 6379:6379 redis:latest docker run -d --name redis-slave1 -p 6380:6379 --link redis-master \ redis:latest redis-server --replicaof redis-master 6379 docker run -d --name redis-slave2 -p 6381:6379 --link redis-master \ redis:latest redis-server --replicaof redis-master 63798.4 面試答題的通用模板面試中回答 Redis 相關(guān)問題時(shí)推薦采用“結(jié)論先行展開原理結(jié)合實(shí)際場(chǎng)景”的結(jié)構(gòu)先給結(jié)論用一兩句話說清楚是什么比如“緩存雪崩是指大量 key 同時(shí)過期導(dǎo)致請(qǐng)求打到數(shù)據(jù)庫(kù)”。展開原因和原理說明為什么會(huì)出現(xiàn)。給出解決方案結(jié)合自己的項(xiàng)目經(jīng)驗(yàn)描述實(shí)際是怎么處理的。如果被追問說明方案的優(yōu)缺點(diǎn)和備選方案。8.5 面試中避免踩的坑只背結(jié)論不解釋原理。面試官只要追問“為什么”就會(huì)暴露。忽略版本差異。Redis 6.0 引入了多線程 IO5.0 引入了 Stream不同版本支持的配置和行為有差異回答時(shí)注明“以 Redis 6.x/7.x 為例”。不區(qū)分單機(jī)和生產(chǎn)環(huán)境。面試官問分布式鎖就不要只說SETNX一條命令完事要聊到鎖釋放的原子性、看門狗、集群下的問題。空談高并發(fā)。說“我們項(xiàng)目用了 Redis”時(shí)至少能說出具體存了什么、為什么用 Hash 而不是 String、過期時(shí)間怎么設(shè)置的。9. Redis 面試中容易被忽略的細(xì)節(jié)9.1 Redis 是單線程的為什么還要用連接池雖然是單線程處理命令但每個(gè)客戶端連接都需要占用一個(gè)文件描述符建立和斷開連接也有開銷。連接池的作用是復(fù)用已經(jīng)建立的連接減少 TCP 握手和 Redis 處理連接事件的消耗讓業(yè)務(wù)代碼在高并發(fā)下不至于頻繁創(chuàng)建連接。9.2 大 key 和熱 key 問題大 key 是指 value 非常大例如一個(gè) List 有幾百萬(wàn)個(gè)元素或包含大量元素的 key。大 key 會(huì)造成阻塞、內(nèi)存不均、網(wǎng)絡(luò)擁塞。熱 key 是指被高頻訪問的 key可能單點(diǎn)壓力過大。解決方案大 key 拆分將大對(duì)象的字段拆分到多個(gè) Hash key 中。對(duì)大 key 使用 SCAN 命令掃描避免使用 KEYS。熱 key 加本地緩存或副本分散讀壓力。使用redis-cli --bigkeys掃描大 key。9.3 為什么生產(chǎn)環(huán)境禁止使用 KEYS 命令KEYS 命令會(huì)遍歷所有 key在數(shù)據(jù)量大的情況下阻塞 Redis 主線程導(dǎo)致整個(gè)實(shí)例不可服務(wù)。推薦使用 SCAN 命令分批迭代不會(huì)阻塞。SCAN 0 MATCH user:* COUNT 1009.4 Redis 事務(wù)和 Lua 腳本Redis 事務(wù)通過 MULTI、EXEC、DISCARD 實(shí)現(xiàn)和 MySQL 事務(wù)不同Redis 事務(wù)不支持回滾只是把命令按順序打包執(zhí)行。如果在事務(wù)中發(fā)現(xiàn)命令語(yǔ)法錯(cuò)誤事務(wù)會(huì)中斷如果運(yùn)行時(shí)錯(cuò)誤如對(duì)字符串執(zhí)行 INCR其他命令仍會(huì)執(zhí)行。Lua 腳本則可以通過EVAL和EVALSHA將一段邏輯在服務(wù)端原子執(zhí)行在分布式鎖、限流等場(chǎng)景中非常常用。10. 實(shí)戰(zhàn)踩坑記錄10.1 緩存和數(shù)據(jù)庫(kù)一致性出問題業(yè)務(wù)中曾經(jīng)出現(xiàn)過修改用戶信息后緩存里還是舊數(shù)據(jù)的情況。原因是代碼里先刪緩存再更新數(shù)據(jù)庫(kù)并發(fā)情況下另一個(gè)線程先查數(shù)據(jù)庫(kù)還沒寫完然后更新線程把舊數(shù)據(jù)又寫回緩存。后來統(tǒng)一改成“先更新數(shù)據(jù)庫(kù)再刪除緩存”并加上延遲雙刪兜底才基本解決了問題。10.2 分布式鎖導(dǎo)致的死鎖手寫分布式鎖時(shí)使用 SETNX 加鎖后忘記設(shè)置過期時(shí)間在業(yè)務(wù)出現(xiàn)異常時(shí)鎖沒有被釋放其他線程一直拿不到鎖。排查發(fā)現(xiàn)鎖的 value 沒有區(qū)分線程釋放鎖時(shí)直接 DEL導(dǎo)致誤刪了其他線程的鎖。后來統(tǒng)一改為隨機(jī) UUID 作為 value并用 Lua 腳本校驗(yàn)后刪除。10.3 Redis 連接數(shù)被打滿上線后發(fā)現(xiàn)大量報(bào)錯(cuò)ERR max number of clients reached原因是項(xiàng)目使用redisTemplate時(shí)沒有配置連接池的最大值默認(rèn)連接數(shù)不夠同時(shí)部分請(qǐng)求執(zhí)行很慢連接被長(zhǎng)期占用。解決方式是調(diào)大連接池最大連接數(shù)并優(yōu)化慢查詢排查業(yè)務(wù)代碼中是否有大量不必要的 Redis 操作。11. 常見問題速查表下面這張表匯總了 Redis 面試中最高頻的 12 個(gè)問題可以作為考前最后一天的速查清單問題核心回答要點(diǎn)Redis 為什么快內(nèi)存存儲(chǔ)、單線程、IO 多路復(fù)用、高效數(shù)據(jù)結(jié)構(gòu)Redis 有哪些數(shù)據(jù)類型String、Hash、List、Set、ZSet、Bitmap、HyperLogLog、GEO、StreamString 底層是什么SDSO(1) 獲取長(zhǎng)度、避免緩沖區(qū)溢出、動(dòng)態(tài)擴(kuò)容ZSet 底層為什么要用跳表實(shí)現(xiàn)簡(jiǎn)單、支持范圍查詢、O(log N) 性能RDB 和 AOF 怎么選同時(shí)開啟AOF 恢復(fù)為主RDB 做備份什么是緩存穿透查詢不存在的數(shù)據(jù)布隆過濾器或緩存空值什么是緩存擊穿熱點(diǎn) key 失效互斥鎖或邏輯過期什么是緩存雪崩大量 key 同時(shí)失效或 Redis 宕機(jī)過期時(shí)間隨機(jī)化、集群高可用分布式鎖怎么實(shí)現(xiàn)SET NX EX Lua 解鎖生產(chǎn)用 RedissonRedis 集群有幾種主從、哨兵、Cluster演進(jìn)關(guān)系Cluster 數(shù)據(jù)分片怎么分CRC16(key) % 16384 定位哈希槽Redis 內(nèi)存滿了怎么辦maxmemory-policy 配置淘汰策略推薦 volatile-lru 或 allkeys-lru這份速查表里的每個(gè)問題都應(yīng)該能展開講 3 到 5 分鐘。Redis 面試題表面上看是背考點(diǎn)實(shí)際上考的是對(duì)緩存設(shè)計(jì)和分布式場(chǎng)景的理解。把數(shù)據(jù)結(jié)構(gòu)、持久化、緩存問題、分布式鎖、集群模式這幾條主線串起來配合手寫命令和代碼3 天時(shí)間足夠把 Redis 這一塊準(zhǔn)備得比較扎實(shí)。面試時(shí)如果能隨口說出 LInux 下的 redis-cli 命令以及 Spring Boot 中如何配置連接池會(huì)明顯比只會(huì)背概念的候選人更有競(jìng)爭(zhēng)力。這份清單可以先存下來每天過一遍8 月面試時(shí)不慌。 Redis面試高頻考點(diǎn)全解析：從數(shù)據(jù)結(jié)構(gòu)到分布式鎖的復(fù)習(xí)體系
8月準(zhǔn)備Java面試Redis這一塊是繞不開的高頻考點(diǎn)。無論是校招還是社招Redis 都是面試官最喜歡深挖的方向它不像 MySQL 那樣以背 SQL 為主而是可以通過數(shù)據(jù)結(jié)構(gòu)、緩存設(shè)計(jì)、分布式鎖、集群方案層層遞進(jìn)地考察候選人的實(shí)戰(zhàn)能力。網(wǎng)上關(guān)于 Redis 面試題的資料很零散不少文章只給結(jié)論不給原理看完記住結(jié)論面試官多問一句“為什么”就容易露餡。這篇文章會(huì)把 Redis 面試中最核心的知識(shí)點(diǎn)整理成一套完整的復(fù)習(xí)體系按照“概念-數(shù)據(jù)結(jié)構(gòu)-持久化-緩存問題-分布式鎖-集群-排錯(cuò)-復(fù)習(xí)路線”的順序展開。每部分都會(huì)給出面試中高頻的問題、標(biāo)準(zhǔn)的回答思路、容易踩的坑以及配套的命令和代碼示例。不管你是剛開始準(zhǔn)備面試還是已經(jīng)進(jìn)入沖刺階段都可以直接對(duì)照這篇文章查漏補(bǔ)缺。先把這份內(nèi)容存下面試前翻一遍確實(shí)能少走很多彎路。1. 先搞清楚 Redis 在面試中到底考什么1.1 Redis 是什么為什么面試必考RedisRemote Dictionary Server是一個(gè)基于內(nèi)存的鍵值型 NoSQL 數(shù)據(jù)庫(kù)。它的核心特點(diǎn)是所有數(shù)據(jù)都存儲(chǔ)在內(nèi)存中所以讀寫速度非?？旃俜浇o出的基準(zhǔn)測(cè)試中單實(shí)例 QPS 可以達(dá)到 10 萬(wàn)級(jí)別。同時(shí)它支持持久化、過期策略、發(fā)布訂閱、事務(wù)、Lua 腳本、分布式鎖、集群擴(kuò)展等豐富的功能所以在互聯(lián)網(wǎng)項(xiàng)目中Redis 主要用于緩存、會(huì)話共享、排行榜、分布式鎖、消息隊(duì)列等場(chǎng)景。面試中考察 Redis本質(zhì)上是從三個(gè)維度進(jìn)行面試者是否掌握 Redis 的數(shù)據(jù)模型和常用命令。面試者是否理解 Redis 的底層機(jī)制比如持久化、淘汰策略、線程模型。面試者是否具備在真實(shí)項(xiàng)目中解決緩存問題、設(shè)計(jì)分布式方案的能力。這三個(gè)維度由淺入深正好對(duì)應(yīng)面試官追問的節(jié)奏。如果只是背題不深入很容易在追問環(huán)節(jié)被識(shí)別出來。1.2 Redis 和 MySQL 有什么區(qū)別這是面試開場(chǎng)高頻題。標(biāo)準(zhǔn)的回答思路是MySQL 是關(guān)系型數(shù)據(jù)庫(kù)數(shù)據(jù)存儲(chǔ)在磁盤上支持復(fù)雜的 SQL 查詢、事務(wù) ACID、表關(guān)聯(lián)。Redis 是基于內(nèi)存的鍵值存儲(chǔ)讀寫速度快但一般不作為唯一數(shù)據(jù)源而是作為緩存層加速訪問。Redis 支持的數(shù)據(jù)類型更豐富如 String、Hash、List、Set、ZSet每種類型都有自己的適用場(chǎng)景。MySQL 的數(shù)據(jù)一致性由事務(wù)保證Redis 在持久化上存在丟數(shù)據(jù)的可能取決于持久化策略所以兩者一般是配合使用?；卮饡r(shí)要強(qiáng)調(diào)“Redis 不是用來替代 MySQL 的而是為了提升系統(tǒng)的讀取性能”。如果面試官問“為什么不直接用 Redis 存所有數(shù)據(jù)”可以從成本、內(nèi)存容量、事務(wù)能力、持久化能力等方面回答。1.3 Redis 為什么快這個(gè)問題基本必問回答要點(diǎn)可以歸納為四點(diǎn)純內(nèi)存操作。數(shù)據(jù)放在內(nèi)存中讀寫不涉及磁盤 IO。單線程模型。Redis 網(wǎng)絡(luò)請(qǐng)求處理使用單線程避免了多線程上下文切換和鎖競(jìng)爭(zhēng)的開銷。注意Redis 6.0 之后引入了多線程 IO但核心命令執(zhí)行仍然是單線程的。IO 多路復(fù)用。Redis 基于 epoll 實(shí)現(xiàn) IO 多路復(fù)用可以在一個(gè)線程里處理多個(gè)連接的讀寫事件。高效的數(shù)據(jù)結(jié)構(gòu)。Redis 底層使用 SDS、跳表、壓縮列表、哈希表等高效結(jié)構(gòu)在不同數(shù)據(jù)量和場(chǎng)景下自動(dòng)選擇最優(yōu)編碼。面試官可能會(huì)追問“單線程為什么還這么快”核心原因就是 CPU 不是瓶頸內(nèi)存和網(wǎng)絡(luò)的 IO 才是瓶頸而單線程避免了鎖和上下文切換。2. Redis 核心數(shù)據(jù)結(jié)構(gòu)與常見面試問題2.1 String 字符串String 是 Redis 最基礎(chǔ)的數(shù)據(jù)類型value 最大能存儲(chǔ) 512MB。底層實(shí)現(xiàn)是 SDSSimple Dynamic String相比 C 字符串SDS 可以 O(1) 獲取長(zhǎng)度、避免緩沖區(qū)溢出、減少內(nèi)存重分配次數(shù)。常用命令SET key value GET key INCR key DECR key EXPIRE key seconds SETEX key seconds valueString 的典型應(yīng)用場(chǎng)景緩存用戶信息、配置數(shù)據(jù)。計(jì)數(shù)器如點(diǎn)贊數(shù)、訪問量。分布式 ID 生成利用 INCR 命令生成遞增序列。分布式鎖的SET key value NX EX也是基于 String 實(shí)現(xiàn)的。面試題舉例“String 的底層實(shí)現(xiàn)是什么和傳統(tǒng) C 字符串有什么不同”回答時(shí)把 SDS 的動(dòng)態(tài)擴(kuò)容、二進(jìn)制安全、獲取長(zhǎng)度 O(1) 這三個(gè)特點(diǎn)說出來即可。2.2 Hash 哈希Hash 類型是一個(gè) string 類型的 field 和 value 的映射表適合存儲(chǔ)對(duì)象數(shù)據(jù)。比如一個(gè)用戶對(duì)象包含 id、name、age如果用 String 存儲(chǔ)需要序列化整個(gè)對(duì)象更新某個(gè)字段要重新寫入整個(gè)對(duì)象用 Hash 則可以直接更新某個(gè)字段。常用命令HSET user:1001 name zhangsan HGET user:1001 name HGETALL user:1001 HDEL user:1001 name HINCRBY user:1001 age 1Hash 底層在數(shù)據(jù)量小的時(shí)候使用壓縮列表ziplist數(shù)據(jù)量大時(shí)轉(zhuǎn)為哈希表hashtable。因?yàn)?Redis 3.2 之后引入了 listpack不同版本的編碼細(xì)節(jié)略有差異但面試中掌握“小數(shù)據(jù)量壓縮存儲(chǔ)、大數(shù)據(jù)量哈希表”這個(gè)思路就夠了。面試題舉例“Hash 和 String 都存對(duì)象怎么選”一般推薦對(duì)象字段頻繁修改、只需要部分字段時(shí)用 Hash對(duì)象整體讀取、轉(zhuǎn)發(fā)給前端時(shí)用 String JSON 更省內(nèi)存且直觀。2.3 List 列表List 是簡(jiǎn)單的字符串列表按照插入順序排序可以從頭部或尾部添加元素。底層在元素少時(shí)使用壓縮列表元素多時(shí)轉(zhuǎn)為雙向鏈表quicklist 是 Redis 3.2 之后引入的混合結(jié)構(gòu)。常用命令LPUSH key value [value ...] RPUSH key value [value ...] LPOP key RPOP key LRANGE key start stop LLEN key典型應(yīng)用場(chǎng)景消息隊(duì)列LPUSH BRPOP 實(shí)現(xiàn)簡(jiǎn)單的生產(chǎn)消費(fèi)模型。最新動(dòng)態(tài)列表用 LPUSH 把新數(shù)據(jù)放到頭部用 LRANGE 分頁(yè)查詢。時(shí)間線列表關(guān)注的人發(fā)布動(dòng)態(tài)后推送到自己的 List 中。面試題舉例“List 和 Stream 做消息隊(duì)列有什么區(qū)別”List 結(jié)構(gòu)簡(jiǎn)單但無法支持消費(fèi)組、消息確認(rèn)等特性Redis Stream5.0 引入支持消費(fèi)者組、消息持久化、ACK 確認(rèn)更適合可靠性要求更高的場(chǎng)景。2.4 Set 集合Set 是無序、不可重復(fù)的字符串集合。集合操作支持交集、并集、差集這是它在業(yè)務(wù)中最大的價(jià)值。常用命令SADD key member [member ...] SMEMBERS key SREM key member SISMEMBER key member SINTER key1 key2 # 交集 SUNION key1 key2 # 并集 SDIFF key1 key2 # 差集典型應(yīng)用場(chǎng)景抽獎(jiǎng)去重用戶參與抽獎(jiǎng)SADD 時(shí)自動(dòng)去重。共同關(guān)注用 SINTER 獲取兩個(gè)用戶的共同關(guān)注列表。標(biāo)簽系統(tǒng)給文章打標(biāo)簽用 SMEMBERS 查詢標(biāo)簽用 SINTER 查同時(shí)包含多個(gè)標(biāo)簽的文章。2.5 ZSet 有序集合ZSet 在 Set 的基礎(chǔ)上給每個(gè)成員增加了一個(gè) score分值Redis 根據(jù) score 自動(dòng)排序。底層實(shí)現(xiàn)是跳表skiplist加哈希表。常用命令ZADD key score member ZRANGE key start stop ZREVRANGE key start stop ZSCORE key member ZINCRBY key increment member ZRANK key member典型應(yīng)用場(chǎng)景排行榜。比如游戲積分排行榜、商品銷量榜用 ZINCRBY 增加分?jǐn)?shù)用 ZREVRANGE 獲取 Top N。延遲隊(duì)列。把任務(wù)執(zhí)行時(shí)間作為 score用一個(gè)線程輪詢 ZRANGEBYSCORE 獲取到期的任務(wù)?；瑒?dòng)窗口限流。用 score 存時(shí)間戳通過 ZRANGEBYSCORE 統(tǒng)計(jì)時(shí)間窗口內(nèi)的請(qǐng)求數(shù)。面試中經(jīng)常追問“ZSet 的底層結(jié)構(gòu)為什么用跳表而不是紅黑樹”回答要點(diǎn)跳表實(shí)現(xiàn)簡(jiǎn)單、支持范圍查詢、在有序集合的場(chǎng)景下性能足夠O(log N)而且跳表更適合做范圍查找ZSet 的核心操作就是按分?jǐn)?shù)范圍取數(shù)據(jù)。2.6 其他高級(jí)數(shù)據(jù)類型面試加分項(xiàng)Bitmap位圖用位操作存儲(chǔ)布爾型數(shù)據(jù)典型場(chǎng)景是用戶簽到、在線狀態(tài)。HyperLogLog去重計(jì)數(shù)內(nèi)存極小適合統(tǒng)計(jì) UV。GEO地理位置存儲(chǔ)適合“附近的人”功能。Stream可靠消息隊(duì)列支持消費(fèi)者組。這部分可以展示知識(shí)廣度面試官如果追問能說出“GEO 底層基于 ZSet 實(shí)現(xiàn)每個(gè)位置的經(jīng)緯度會(huì)被編碼為 score”這種程度就夠用了。3. Redis 持久化機(jī)制RDB 和 AOF3.1 為什么需要持久化Redis 是內(nèi)存型數(shù)據(jù)庫(kù)如果進(jìn)程異常退出或服務(wù)器宕機(jī)內(nèi)存中的數(shù)據(jù)會(huì)全部丟失。持久化的目的就是把內(nèi)存中的數(shù)據(jù)保存到磁盤上使 Redis 重啟時(shí)能夠恢復(fù)數(shù)據(jù)。面試中問到持久化通常圍繞兩個(gè)問題RDB 和 AOF 分別是什么如何選擇3.2 RDB 快照持久化RDBRedis DataBase是在指定時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤生成一個(gè)二進(jìn)制的 dump.rdb 文件。觸發(fā)方式# 手動(dòng)觸發(fā) SAVE BGSAVE # 自動(dòng)觸發(fā)在 redis.conf 中配置 save 900 1 save 300 10 save 60 10000SAVE 會(huì)阻塞 Redis 主進(jìn)程BGSAVE 會(huì) fork 子進(jìn)程來生成 RDB主進(jìn)程繼續(xù)處理命令。面試中需要說清楚RDB 的優(yōu)點(diǎn)是文件緊湊、恢復(fù)速度快、適合做備份和災(zāi)難恢復(fù)缺點(diǎn)是可能丟失最后一次快照之后的數(shù)據(jù)同時(shí) fork 子進(jìn)程在大數(shù)據(jù)量下會(huì)有短暫的阻塞。3.3 AOF 追加持久化AOFAppend Of File會(huì)把每次寫命令追加到 aof 文件末尾。Redis 重啟時(shí)通過重新執(zhí)行 AOF 文件中的命令來恢復(fù)數(shù)據(jù)。AOF 默認(rèn)是關(guān)閉的開啟配置appendonly yes appendfilename appendonly.aof appendfsync always appendfsync everysec appendfsync no配置項(xiàng)說明always每次寫入都同步到磁盤數(shù)據(jù)最安全性能最差。everysec每秒同步一次最多丟失 1 秒數(shù)據(jù)是推薦配置。no由操作系統(tǒng)決定什么時(shí)候同步性能好但安全性不可控。為了避免 AOF 文件過大Redis 提供了 AOF 重寫機(jī)制通過BGREWRITEAOF命令或自動(dòng)觸發(fā)用盡可能少的命令來記錄當(dāng)前數(shù)據(jù)集。3.4 RDB 和 AOF 怎么選對(duì)比項(xiàng)RDBAOF文件大小二進(jìn)制壓縮文件小記錄寫命令文件較大恢復(fù)速度快較慢數(shù)據(jù)安全性可能丟較多數(shù)據(jù)最多丟 1 秒everysec對(duì)性能影響fork 子進(jìn)程可能瞬間阻塞寫頻率高時(shí)影響較大生產(chǎn)環(huán)境常用的方案是同時(shí)開啟 RDB 和 AOF。Redis 優(yōu)先使用 AOF 恢復(fù)數(shù)據(jù)因?yàn)?AOF 數(shù)據(jù)更完整同時(shí)利用 RDB 做定期備份。如果對(duì)數(shù)據(jù)丟失容忍度很低必須開啟 AOF 并設(shè)置 appendfsync everysec。4. 緩存設(shè)計(jì)穿透、擊穿、雪崩與解決方案4.1 緩存穿透緩存穿透是指查詢一個(gè)不存在的數(shù)據(jù)緩存中沒有數(shù)據(jù)庫(kù)中也沒有導(dǎo)致每次請(qǐng)求都直接打到數(shù)據(jù)庫(kù)。如果有惡意攻擊者持續(xù)構(gòu)造不存在的 key數(shù)據(jù)庫(kù)壓力驟增。解決方案緩存空值查詢結(jié)果為空也緩存設(shè)置較短的過期時(shí)間。布隆過濾器把所有可能存在的數(shù)據(jù)哈希到一個(gè) bitmap 中請(qǐng)求先經(jīng)過布隆過濾器過濾掉大部分不存在的 key。參數(shù)校驗(yàn)在接口層攔截明顯不合法的請(qǐng)求。示例代碼緩存空值使用 Spring Data Redispublic Object getData(String key) { Object value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } // 模擬從數(shù)據(jù)庫(kù)查詢 Object dbValue queryFromDB(key); if (dbValue null) { // 緩存空值防止穿透過期時(shí)間設(shè)置短一些 redisTemplate.opsForValue().set(key, , 60, TimeUnit.SECONDS); } else { redisTemplate.opsForValue().set(key, dbValue, 30, TimeUnit.MINUTES); } return dbValue; }4.2 緩存擊穿緩存擊穿是指某個(gè)熱點(diǎn) key 剛好在過期時(shí)間失效此時(shí)大量并發(fā)請(qǐng)求同時(shí)查詢這個(gè) key緩存未命中請(qǐng)求全部打到數(shù)據(jù)庫(kù)。解決方案互斥鎖只允許一個(gè)線程查數(shù)據(jù)庫(kù)并重建緩存其他線程等待。邏輯過期緩存中不設(shè)置物理過期時(shí)間而是存儲(chǔ)一個(gè)邏輯過期時(shí)間字段查詢時(shí)判斷是否過期如果過期則異步重建緩存。熱點(diǎn)數(shù)據(jù)永不過期在 value 中保存過期時(shí)間業(yè)務(wù)層判斷后異步更新。這里給出基于互斥鎖的簡(jiǎn)化示例public String getHotData(String key) { String value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } String lockKey lock: key; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 3, TimeUnit.SECONDS); if (locked) { try { value queryFromDB(key); redisTemplate.opsForValue().set(key, value, 30, TimeUnit.MINUTES); return value; } finally { redisTemplate.delete(lockKey); } } else { // 等待其他線程寫入緩存 try { Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return getHotData(key); } }互斥鎖方案簡(jiǎn)單有效代價(jià)是緩存重建期間有少量線程等待。實(shí)際項(xiàng)目中要重點(diǎn)關(guān)注鎖的釋放避免因異常導(dǎo)致鎖無法釋放。4.3 緩存雪崩緩存雪崩是指大量 key 在同一時(shí)間失效或者 Redis 服務(wù)宕機(jī)導(dǎo)致所有請(qǐng)求直接打到數(shù)據(jù)庫(kù)。解決方案過期時(shí)間隨機(jī)化在設(shè)置過期時(shí)間時(shí)加上一個(gè)隨機(jī)值避免同一時(shí)間大面積失效。Redis 集群高可用使用主從復(fù)制、哨兵或 Cluster 模式避免單點(diǎn)故障。多級(jí)緩存本地緩存如 Caffeine Redis 緩存即使 Redis 不可用本地緩存也能扛一部分流量。服務(wù)降級(jí)在數(shù)據(jù)庫(kù)層增加限流和降級(jí)策略保護(hù)數(shù)據(jù)庫(kù)不被壓垮。面試中更好的回答是“緩存雪崩的重點(diǎn)不是如何保證 Redis 不宕機(jī)而是要在 Redis 不可用或緩存大規(guī)模失效時(shí)系統(tǒng)依然能通過降級(jí)、限流、多級(jí)緩存等手段保持可用?！?.4 緩存一致性問題只要用 Redis 做緩存就繞不開“緩存和數(shù)據(jù)庫(kù)數(shù)據(jù)不一致”的問題。常見的方案Cache Aside Pattern旁路緩存讀的時(shí)候先讀緩存緩存沒有則讀數(shù)據(jù)庫(kù)并回填寫的時(shí)候先更新數(shù)據(jù)庫(kù)再刪除緩存。延遲雙刪更新數(shù)據(jù)庫(kù)后刪除緩存等一段時(shí)間再次刪除避免并發(fā)下讀到舊數(shù)據(jù)。基于 Canal 監(jiān)聽 MySQL binlog異步更新緩存。面試中不要只說一個(gè)方案要能分析利弊。比較推薦的回答一般業(yè)務(wù)采用 Cache Aside 模式更新時(shí)“先更新數(shù)據(jù)庫(kù)再刪除緩存”如果要求更高的一致性可以引入分布式事務(wù)或 binlog 異步同步但這會(huì)增加系統(tǒng)復(fù)雜度需要根據(jù)業(yè)務(wù)權(quán)衡。5. Redis 分布式鎖5.1 為什么要用分布式鎖在分布式系統(tǒng)中多個(gè)服務(wù)實(shí)例同時(shí)操作共享資源時(shí)Java 的synchronized和ReentrantLock只能鎖住當(dāng)前 JVM 內(nèi)的線程無法跨進(jìn)程互斥。分布式鎖就是讓多個(gè)進(jìn)程之間通過 Redis 實(shí)現(xiàn)互斥訪問。5.2 基于 Redis 實(shí)現(xiàn)分布式鎖的演進(jìn)最早的方案是使用SETNX加鎖然后EXPIRE設(shè)置過期時(shí)間但這兩個(gè)命令不是原子的如果在 SETNX 之后、EXPIRE 之前進(jìn)程崩潰鎖就會(huì)永遠(yuǎn)不釋放。后來 Redis 官方推薦使用SET key value NX EX seconds一條命令完成加鎖和過期時(shí)間設(shè)置。加鎖命令SET lock:order:1001 uuid_value NX EX 30釋放鎖時(shí)不能直接DEL因?yàn)槿绻i已經(jīng)過期另一個(gè)線程獲取了同一把鎖當(dāng)前線程再執(zhí)行 DEL 就會(huì)誤刪別人的鎖。所以釋放鎖需要先比較 value 是否還是自己的再刪除這個(gè)過程要用 Lua 腳本保證原子性-- 釋放鎖的 Lua 腳本 if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 endJava 中通過 Spring Data Redis 執(zhí)行 Lua 腳本private static final String UNLOCK_SCRIPT if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; public void unlock(String lockKey, String requestId) { DefaultRedisScriptLong script new DefaultRedisScript(UNLOCK_SCRIPT, Long.class); redisTemplate.execute(script, Arrays.asList(lockKey), requestId); }5.3 Redisson 與看門狗機(jī)制手寫分布式鎖需要處理各種邊界條件生產(chǎn)環(huán)境推薦使用 Redisson。Redisson 提供了RLock內(nèi)部通過 Lua 腳本實(shí)現(xiàn)加鎖、解鎖、重入還提供了看門狗機(jī)制如果鎖的持有者沒有顯式釋放鎖看門狗會(huì)每隔一段時(shí)間自動(dòng)續(xù)期防止業(yè)務(wù)沒執(zhí)行完鎖就過期了。RLock lock redissonClient.getLock(lock:order:1001); try { // 嘗試加鎖最多等待 5 秒鎖有效期默認(rèn) 30 秒看門狗會(huì)自動(dòng)續(xù)期 if (lock.tryLock(5, TimeUnit.SECONDS)) { // 業(yè)務(wù)邏輯 } } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }5.4 RedLock 有必要用嗎RedLock 是 Redis 官方提出的多節(jié)點(diǎn)分布式鎖算法要求向多個(gè)獨(dú)立的 Redis 主節(jié)點(diǎn)加鎖超過半數(shù)成功才算加鎖成功。面試中經(jīng)常被問到但實(shí)際項(xiàng)目中較少使用因?yàn)?RedLock 依賴時(shí)鐘同步、網(wǎng)絡(luò)延遲實(shí)現(xiàn)復(fù)雜且在多主切換下仍存在一致性問題。推薦回答思路“單節(jié)點(diǎn) Redis 鎖 Redisson 的看門狗在絕大多數(shù)業(yè)務(wù)中已經(jīng)夠用如果要更強(qiáng)的安全性優(yōu)先考慮 ZooKeeper 或 etcd 的分布式鎖而不是 RedLock?！?. Redis 集群與可用性6.1 主從復(fù)制Redis 主從復(fù)制是指一臺(tái)主節(jié)點(diǎn)Master將數(shù)據(jù)同步到多臺(tái)從節(jié)點(diǎn)Slave實(shí)現(xiàn)讀寫分離和容災(zāi)。主節(jié)點(diǎn)負(fù)責(zé)寫操作從節(jié)點(diǎn)負(fù)責(zé)讀操作數(shù)據(jù)由主節(jié)點(diǎn)單向同步到從節(jié)點(diǎn)。順序上主從復(fù)制分為兩個(gè)階段全量復(fù)制從節(jié)點(diǎn)首次同步時(shí)主節(jié)點(diǎn)生成 RDB 快照并發(fā)送給從節(jié)點(diǎn)。增量復(fù)制后續(xù)主節(jié)點(diǎn)把寫命令發(fā)送給從節(jié)點(diǎn)。從節(jié)點(diǎn)斷開重連后主節(jié)點(diǎn)通過復(fù)制積壓緩沖區(qū)同步斷連期間的數(shù)據(jù)。配置方式# 從節(jié)點(diǎn)配置 replicaof 127.0.0.1 63796.2 哨兵模式主從復(fù)制解決了數(shù)據(jù)備份和讀寫分離但主節(jié)點(diǎn)宕機(jī)后需要人工把某個(gè)從節(jié)點(diǎn)提升為主節(jié)點(diǎn)。哨兵Sentinel可以自動(dòng)監(jiān)控主節(jié)點(diǎn)和從節(jié)點(diǎn)的健康狀態(tài)在主節(jié)點(diǎn)故障時(shí)自動(dòng)完成故障轉(zhuǎn)移從剩余從節(jié)點(diǎn)中選舉新的主節(jié)點(diǎn)。哨兵的關(guān)鍵作用監(jiān)控檢查主從節(jié)點(diǎn)的運(yùn)行狀態(tài)。通知節(jié)點(diǎn)故障時(shí)通知其他實(shí)例。自動(dòng)故障轉(zhuǎn)移主節(jié)點(diǎn)不可用時(shí)自動(dòng)選舉新的主節(jié)點(diǎn)。配置中心客戶端通過哨兵獲取當(dāng)前主節(jié)點(diǎn)地址。6.3 Cluster 集群模式Redis Cluster 是 Redis 3.0 引入的分布式解決方案能夠?qū)?shù)據(jù)自動(dòng)分片到多個(gè)節(jié)點(diǎn)上每個(gè)節(jié)點(diǎn)保存一部分?jǐn)?shù)據(jù)。Redis Cluster 采用無中心化架構(gòu)節(jié)點(diǎn)之間通過 Gossip 協(xié)議通信。分片原理整個(gè)數(shù)據(jù)空間被劃分為 16384 個(gè)哈希槽slot。每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分 slot例如三主節(jié)點(diǎn)分別負(fù)責(zé) 0~5460、5461~10922、10923~16383。計(jì)算 key 的 CRC16 值然后對(duì) 16384 取模得到該 key 應(yīng)該存儲(chǔ)到哪個(gè) slot。Cluster 模式的優(yōu)勢(shì)是支持水平擴(kuò)展性能隨節(jié)點(diǎn)增加而提升。需要注意的坑是 Cluster 模式下不支持多 key 操作除非這些 key 在同一個(gè) slot因此需要使用 Hash Tag 技術(shù)讓相關(guān) key 落到同一個(gè)槽位。面試常見問題“為什么 Redis Cluster 是 16384 個(gè)槽”常見的解釋是16384 個(gè)槽在保證數(shù)據(jù)分布均勻的同時(shí)可以使節(jié)點(diǎn)間心跳消息中的位圖更小減少帶寬消耗且對(duì)于常用規(guī)模的集群已經(jīng)足夠。6.4 一致性哈希和哈希槽可能被追問“Redis 為什么不用一致性哈?！?。一致性哈希是分布式緩存中常用的分片算法如 Memcached但 Redis Cluster 選擇哈希槽的原因主要有哈希槽將數(shù)據(jù)分成固定數(shù)量的槽位節(jié)點(diǎn)增減時(shí)只需要遷移部分槽位數(shù)據(jù)遷移范圍可控。槽位和節(jié)點(diǎn)的映射關(guān)系明確客戶端可以精確計(jì)算 key 所在節(jié)點(diǎn)。數(shù)據(jù)遷移時(shí)是以槽為單位進(jìn)行操作粒度更清晰。7. Redis 內(nèi)存淘汰與常見問題排查7.1 過期刪除策略Redis 的過期刪除策略是“惰性刪除 定期刪除”的結(jié)合惰性刪除訪問 key 時(shí)檢查是否過期過期則刪除。優(yōu)點(diǎn)是不占用額外 CPU缺點(diǎn)是過期 key 可能長(zhǎng)期占用內(nèi)存。定期刪除Redis 每隔一段時(shí)間隨機(jī)抽取一部分設(shè)置了過期時(shí)間的 key刪除其中已過期的 key。7.2 內(nèi)存淘汰策略當(dāng) Redis 內(nèi)存達(dá)到maxmemory限制后會(huì)根據(jù)配置的maxmemory-policy進(jìn)行淘汰。常見配置項(xiàng)策略含義noeviction不淘汰寫入時(shí)報(bào)錯(cuò)allkeys-lru從所有 key 中按 LRU 淘汰volatile-lru從設(shè)置了過期時(shí)間的 key 中按 LRU 淘汰allkeys-lfu從所有 key 中按 LFU 淘汰volatile-lfu從設(shè)置了過期時(shí)間的 key 中按 LFU 淘汰allkeys-random從所有 key 中隨機(jī)淘汰volatile-ttl從設(shè)置了過期時(shí)間且剩余時(shí)間最短的 key 中淘汰面試中回答“生產(chǎn)環(huán)境推薦哪種策略”時(shí)不要直接說“用 allkeys-lru”。正確的思路是優(yōu)先給每個(gè) key 設(shè)置合理的過期時(shí)間根據(jù)業(yè)務(wù)是否允許緩存丟失決定使用 volatile-lru 還是 allkeys-lru如果業(yè)務(wù)數(shù)據(jù)要求嚴(yán)格不淘汰則使用 noeviction 并做好告警。7.3 內(nèi)存不足報(bào)錯(cuò) OutOfMemoryErrorJVM 項(xiàng)目和 Redis 都會(huì)出現(xiàn)內(nèi)存不足的報(bào)錯(cuò)。熱詞中出現(xiàn)的java: outofmemoryerror: insufficient memory屬于 JVM 啟動(dòng)時(shí)內(nèi)存不足常見原因是啟動(dòng) JVM 時(shí)指定的 -Xmx 大于物理內(nèi)存。服務(wù)器內(nèi)存被其他進(jìn)程占用剩余可用內(nèi)存不足。系統(tǒng)沒有足夠交換空間。排查方法# 查看系統(tǒng)內(nèi)存 free -h # 查看 Java 進(jìn)程內(nèi)存占用 ps aux | grep java jmap -heap pid如果 Redis 本身內(nèi)存不足可以檢查maxmemory配置、大 key、連接數(shù)、內(nèi)存碎片率必要時(shí)擴(kuò)容或清理大 key。7.4 連接失敗和超時(shí)Redis 連接失敗通常表現(xiàn)為ERR max number of clients reached或RedisConnectionFailureException。排查思路檢查 Redis 服務(wù)是否啟動(dòng)redis-cli ping。檢查端口連通性telnet 127.0.0.1 6379。檢查客戶端最大連接數(shù)配置CONFIG GET maxclients。檢查防火墻和遠(yuǎn)程訪問配置bind、protected-mode。檢查業(yè)務(wù)代碼是否存在連接池泄漏用完連接沒有釋放。Spring Boot 中可以通過配置連接池參數(shù)優(yōu)化spring.redis.hostlocalhost spring.redis.port6379 spring.redis.lettuce.pool.max-active50 spring.redis.lettuce.pool.max-idle20 spring.redis.lettuce.pool.min-idle5 spring.redis.lettuce.pool.max-wait3000ms7.5 熱詞背后的 Redis 高頻面試題庫(kù)根據(jù)搜索熱詞高頻被搜的還有redis 下載、windows 安裝 redis、docker 安裝 redis 主從、redis desktop manager 可視化客戶端、redis 緩存治理。這些屬于環(huán)境搭建和運(yùn)維工具建議在復(fù)習(xí)基礎(chǔ)知識(shí)的同時(shí)把本機(jī)環(huán)境搭好用 Redis Desktop Manager 或 Another Redis Desktop Manager 連一次能加深對(duì) Redis 數(shù)據(jù)結(jié)構(gòu)的印象。8. 三天沖刺計(jì)劃與復(fù)習(xí)建議8.1 第 1 天數(shù)據(jù)結(jié)構(gòu)與基礎(chǔ)命令把 String、Hash、List、Set、ZSet 的常用命令全部敲一遍。理解每個(gè)類型的底層編碼和適用場(chǎng)景。用 Spring Data Redis 寫一個(gè)增刪改查的小 Demo。當(dāng)天結(jié)束前完成自測(cè)能默寫每種數(shù)據(jù)類型至少兩個(gè)應(yīng)用場(chǎng)景。8.2 第 2 天持久化、緩存問題與分布式鎖配置 RDB 和 AOF觀察 dump.rdb 和 appendonly.aof 文件的生成。手寫緩存穿透、擊穿、雪崩的解決方案示例。手寫 SET NX EX 分布式鎖和 Lua 解鎖腳本?？赐?Redisson 官方文檔了解 RLock 基本用法。8.3 第 3 天集群、運(yùn)維與面試模擬用 Docker 搭建一主兩從、哨兵或 Cluster 環(huán)境。檢查 Redis 日志分析主從復(fù)制和故障轉(zhuǎn)移的過程。把高頻面試題制作成卡片按“先結(jié)論后原理再舉例”的方式模擬作答。# Docker 搭建 Redis 主從示例 docker run -d --name redis-master -p 6379:6379 redis:latest docker run -d --name redis-slave1 -p 6380:6379 --link redis-master \ redis:latest redis-server --replicaof redis-master 6379 docker run -d --name redis-slave2 -p 6381:6379 --link redis-master \ redis:latest redis-server --replicaof redis-master 63798.4 面試答題的通用模板面試中回答 Redis 相關(guān)問題時(shí)推薦采用“結(jié)論先行展開原理結(jié)合實(shí)際場(chǎng)景”的結(jié)構(gòu)先給結(jié)論用一兩句話說清楚是什么比如“緩存雪崩是指大量 key 同時(shí)過期導(dǎo)致請(qǐng)求打到數(shù)據(jù)庫(kù)”。展開原因和原理說明為什么會(huì)出現(xiàn)。給出解決方案結(jié)合自己的項(xiàng)目經(jīng)驗(yàn)描述實(shí)際是怎么處理的。如果被追問說明方案的優(yōu)缺點(diǎn)和備選方案。8.5 面試中避免踩的坑只背結(jié)論不解釋原理。面試官只要追問“為什么”就會(huì)暴露。忽略版本差異。Redis 6.0 引入了多線程 IO5.0 引入了 Stream不同版本支持的配置和行為有差異回答時(shí)注明“以 Redis 6.x/7.x 為例”。不區(qū)分單機(jī)和生產(chǎn)環(huán)境。面試官問分布式鎖就不要只說SETNX一條命令完事要聊到鎖釋放的原子性、看門狗、集群下的問題。空談高并發(fā)。說“我們項(xiàng)目用了 Redis”時(shí)至少能說出具體存了什么、為什么用 Hash 而不是 String、過期時(shí)間怎么設(shè)置的。9. Redis 面試中容易被忽略的細(xì)節(jié)9.1 Redis 是單線程的為什么還要用連接池雖然是單線程處理命令但每個(gè)客戶端連接都需要占用一個(gè)文件描述符建立和斷開連接也有開銷。連接池的作用是復(fù)用已經(jīng)建立的連接減少 TCP 握手和 Redis 處理連接事件的消耗讓業(yè)務(wù)代碼在高并發(fā)下不至于頻繁創(chuàng)建連接。9.2 大 key 和熱 key 問題大 key 是指 value 非常大例如一個(gè) List 有幾百萬(wàn)個(gè)元素或包含大量元素的 key。大 key 會(huì)造成阻塞、內(nèi)存不均、網(wǎng)絡(luò)擁塞。熱 key 是指被高頻訪問的 key可能單點(diǎn)壓力過大。解決方案大 key 拆分將大對(duì)象的字段拆分到多個(gè) Hash key 中。對(duì)大 key 使用 SCAN 命令掃描避免使用 KEYS。熱 key 加本地緩存或副本分散讀壓力。使用redis-cli --bigkeys掃描大 key。9.3 為什么生產(chǎn)環(huán)境禁止使用 KEYS 命令KEYS 命令會(huì)遍歷所有 key在數(shù)據(jù)量大的情況下阻塞 Redis 主線程導(dǎo)致整個(gè)實(shí)例不可服務(wù)。推薦使用 SCAN 命令分批迭代不會(huì)阻塞。SCAN 0 MATCH user:* COUNT 1009.4 Redis 事務(wù)和 Lua 腳本Redis 事務(wù)通過 MULTI、EXEC、DISCARD 實(shí)現(xiàn)和 MySQL 事務(wù)不同Redis 事務(wù)不支持回滾只是把命令按順序打包執(zhí)行。如果在事務(wù)中發(fā)現(xiàn)命令語(yǔ)法錯(cuò)誤事務(wù)會(huì)中斷如果運(yùn)行時(shí)錯(cuò)誤如對(duì)字符串執(zhí)行 INCR其他命令仍會(huì)執(zhí)行。Lua 腳本則可以通過EVAL和EVALSHA將一段邏輯在服務(wù)端原子執(zhí)行在分布式鎖、限流等場(chǎng)景中非常常用。10. 實(shí)戰(zhàn)踩坑記錄10.1 緩存和數(shù)據(jù)庫(kù)一致性出問題業(yè)務(wù)中曾經(jīng)出現(xiàn)過修改用戶信息后緩存里還是舊數(shù)據(jù)的情況。原因是代碼里先刪緩存再更新數(shù)據(jù)庫(kù)并發(fā)情況下另一個(gè)線程先查數(shù)據(jù)庫(kù)還沒寫完然后更新線程把舊數(shù)據(jù)又寫回緩存。后來統(tǒng)一改成“先更新數(shù)據(jù)庫(kù)再刪除緩存”并加上延遲雙刪兜底才基本解決了問題。10.2 分布式鎖導(dǎo)致的死鎖手寫分布式鎖時(shí)使用 SETNX 加鎖后忘記設(shè)置過期時(shí)間在業(yè)務(wù)出現(xiàn)異常時(shí)鎖沒有被釋放其他線程一直拿不到鎖。排查發(fā)現(xiàn)鎖的 value 沒有區(qū)分線程釋放鎖時(shí)直接 DEL導(dǎo)致誤刪了其他線程的鎖。后來統(tǒng)一改為隨機(jī) UUID 作為 value并用 Lua 腳本校驗(yàn)后刪除。10.3 Redis 連接數(shù)被打滿上線后發(fā)現(xiàn)大量報(bào)錯(cuò)ERR max number of clients reached原因是項(xiàng)目使用redisTemplate時(shí)沒有配置連接池的最大值默認(rèn)連接數(shù)不夠同時(shí)部分請(qǐng)求執(zhí)行很慢連接被長(zhǎng)期占用。解決方式是調(diào)大連接池最大連接數(shù)并優(yōu)化慢查詢排查業(yè)務(wù)代碼中是否有大量不必要的 Redis 操作。11. 常見問題速查表下面這張表匯總了 Redis 面試中最高頻的 12 個(gè)問題可以作為考前最后一天的速查清單問題核心回答要點(diǎn)Redis 為什么快內(nèi)存存儲(chǔ)、單線程、IO 多路復(fù)用、高效數(shù)據(jù)結(jié)構(gòu)Redis 有哪些數(shù)據(jù)類型String、Hash、List、Set、ZSet、Bitmap、HyperLogLog、GEO、StreamString 底層是什么SDSO(1) 獲取長(zhǎng)度、避免緩沖區(qū)溢出、動(dòng)態(tài)擴(kuò)容ZSet 底層為什么要用跳表實(shí)現(xiàn)簡(jiǎn)單、支持范圍查詢、O(log N) 性能RDB 和 AOF 怎么選同時(shí)開啟AOF 恢復(fù)為主RDB 做備份什么是緩存穿透查詢不存在的數(shù)據(jù)布隆過濾器或緩存空值什么是緩存擊穿熱點(diǎn) key 失效互斥鎖或邏輯過期什么是緩存雪崩大量 key 同時(shí)失效或 Redis 宕機(jī)過期時(shí)間隨機(jī)化、集群高可用分布式鎖怎么實(shí)現(xiàn)SET NX EX Lua 解鎖生產(chǎn)用 RedissonRedis 集群有幾種主從、哨兵、Cluster演進(jìn)關(guān)系Cluster 數(shù)據(jù)分片怎么分CRC16(key) % 16384 定位哈希槽Redis 內(nèi)存滿了怎么辦maxmemory-policy 配置淘汰策略推薦 volatile-lru 或 allkeys-lru這份速查表里的每個(gè)問題都應(yīng)該能展開講 3 到 5 分鐘。Redis 面試題表面上看是背考點(diǎn)實(shí)際上考的是對(duì)緩存設(shè)計(jì)和分布式場(chǎng)景的理解。把數(shù)據(jù)結(jié)構(gòu)、持久化、緩存問題、分布式鎖、集群模式這幾條主線串起來配合手寫命令和代碼3 天時(shí)間足夠把 Redis 這一塊準(zhǔn)備得比較扎實(shí)。面試時(shí)如果能隨口說出 LInux 下的 redis-cli 命令以及 Spring Boot 中如何配置連接池會(huì)明顯比只會(huì)背概念的候選人更有競(jìng)爭(zhēng)力。這份清單可以先存下來每天過一遍8 月面試時(shí)不慌。