2026吃透Redis面試奪命連環(huán)85問3天學會redis分布式鎖redis緩存redis集群redis面試題這絕對是Redis面試天花板核心能力速覽能力項說明主題類別Redis 分布式鎖、緩存設(shè)計、集群架構(gòu)、底層原理、面試問答適用人群Java/后端開發(fā)、系統(tǒng)架構(gòu)師、準備 Redis 面試的候選人核心技能分布式鎖實現(xiàn)與原理、緩存穿透/擊穿/雪崩治理、Redis Cluster/哨兵/主從架構(gòu)必備基礎(chǔ)Redis 基本命令、一種編程語言以 Java 為例、基礎(chǔ)網(wǎng)絡(luò)知識推薦環(huán)境Linux 服務(wù)器或本地虛擬機Redis 6.x/7.xJava 8啟動方式Redis 源碼編譯 / Docker 容器 / 云 Redis 實例是否支持 API支持Redis 提供 RESPE 協(xié)議標準接口批量任務(wù)支持可通過 Pipeline、Lua 腳本、SCAN 實現(xiàn)批量操作先看結(jié)論2026 年的 Redis 面試已經(jīng)從“會不會用”進化到“能不能講清楚為什么”。面試官不再滿足于聽到“Redis 是單線程的”“緩存能抗壓”這種結(jié)論而是一層層追問Why 單線程還快分布式鎖到底怎么保證原子性Cluster 擴縮容時槽位怎么遷移緩存擊穿和緩存雪崩的解決思路有什么區(qū)別這篇文章把 Redis 面試中最常出現(xiàn)的 85 個問題整理成一張知識網(wǎng)絡(luò)按“分布式鎖、緩存、集群、底層原理、面試突擊”五個方向切分配合可執(zhí)行的本地環(huán)境搭建步驟和 Java 實戰(zhàn)代碼讓你在 3 天內(nèi)形成自己的面試答題體系而不是死背八股。1. Redis 面試準備的前提先把環(huán)境跑起來1.1 本地安裝 Redis準備面試和寫 demo 之前先把 Redis 跑在本地。最省事的方式是用 Docker也可以直接用源碼編譯。# 方式一使用 Docker 啟動 Redis 7.x docker run -d --name redis-local \ -p 6379:6379 \ -v redis-data:/data \ redis:7-alpine # 方式二編譯安裝 Redis 7.x wget https://download.redis.io/releases/redis-7.0.14.tar.gz tar -xzf redis-7.0.14.tar.gz cd redis-7.0.14 make make install # 啟動 redis-server --port 6379 --daemonize yes redis-cli -p 6379 ping1.2 確認 Redis 版本安裝完成后用redis-cli --version查看版本。2026 年的面試里Redis 6.x 已經(jīng)開始淘汰Redis 7.x 是主流Redis Stack帶 JSON、Bloom Filter、Search 模塊也在很多互聯(lián)網(wǎng)公司落地。如果只背舊版知識點面試時很容易被版本迭代問題問住。1.3 準備一個 Java 工程Java 后端面試中Redis 相關(guān)題目基本繞不開 Jedis 和 Lettuce以及 Spring Data Redis。準備一個 Spring Boot 項目引入依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.27.2/version /dependency這個工程后續(xù)用來實戰(zhàn)分布式鎖、緩存和 Pipeline 用例。2. 2026 Redis 面試核心題型分布先把 85 問做成一張分類地圖后面按模塊展開。模塊常考問題數(shù)量占比典型問題Redis 數(shù)據(jù)結(jié)構(gòu)和底層實現(xiàn)20%SDS、跳表、壓縮列表、quicklist、listpack 的區(qū)別緩存設(shè)計25%緩存穿透、擊穿、雪崩、一致性、失效策略分布式鎖20%SET NX、Redisson、Redlock、鎖續(xù)期、可重入高可用與集群20%主從復(fù)制、哨兵、Cluster 槽位、腦裂持久化與性能優(yōu)化10%RDB/AOF、Pipeline、事務(wù)、Lua 腳本綜合設(shè)計題5%電商秒殺、排行榜、好友關(guān)注、滑動窗口限流從熱搜詞“Redis分布式鎖、緩存失效、分布式緩存、服務(wù)器集群”能看出面試大概率不會只問孤立的命令而是把 Redis 放進一個業(yè)務(wù)場景里比如“秒殺系統(tǒng)怎么防止超賣”“訂單緩存怎么保證一致性”“Redis 集群擴容后數(shù)據(jù)怎么遷移”。這要求你既有底層原理基礎(chǔ)又有方案設(shè)計能力。3. Redis 底層數(shù)據(jù)結(jié)構(gòu)與字符串實現(xiàn)3.1 為什么 Redis 快Redis 常用“單線程 多路復(fù)用”來解釋核心優(yōu)勢。嚴格來說Redis 的網(wǎng)絡(luò) IO 和命令執(zhí)行主線程是單線程但對持久化、異步刪除、部分模塊任務(wù)用了額外線程。單線程避免了多線程上下文切換和鎖競爭但這只是表象。真正讓 Redis 快的是純內(nèi)存操作。高效的數(shù)據(jù)結(jié)構(gòu)設(shè)計例如 SDS 和跳表。IO 多路復(fù)用機制基于 epoll 處理大量連接。命令執(zhí)行長度短且大部分命令是 O(1) 或 O(logN)。面試時不要只說“單線程”要往下拆為什么單線程還能支撐高并發(fā)答案是基于內(nèi)存和 IO 多路復(fù)用。為什么 6.0 以后引入多線程答案是為了優(yōu)化網(wǎng)絡(luò) IO 的讀寫性能但命令執(zhí)行仍然是單線程所以不會因為多線程引入數(shù)據(jù)競爭。3.2 String 字符串SDS 而不是 C 字符串Redis 的 String 底層叫 SDSSimple Dynamic String它不是 C 語言的 char 數(shù)組。SDS 的設(shè)計解決了三個問題獲取字符串長度的時間復(fù)雜度從 O(N) 變成 O(1)。避免緩沖區(qū)溢出SDS 會自動擴容。減少修改字符串時頻繁分配內(nèi)存通過空間預(yù)分配和惰性空間釋放做優(yōu)化。面試時如果能畫出 SDS 結(jié)構(gòu)struct sdshdr { int len; // 已使用的長度 int alloc; // 已分配的總長度 char buf[]; // 字節(jié)數(shù)組 };3.3 字符串面試高頻場景緩存對象把對象序列化為 JSON 存到 String。計數(shù)器INCR、DECR、INCRBY用于點贊數(shù)、訪問量。分布式 IDINCR 時間戳。限流SET key value EX seconds配合計數(shù)。4. List、Hash、Set、ZSet 與底層實現(xiàn)4.1 ListList 在 Redis 3.2 之前的底層的 ziplist之后是 quicklist。quicklist 本質(zhì)上是雙向鏈表 多個壓縮列表節(jié)點組成減少鏈表的指針開銷也降低內(nèi)存碎片。List 高頻面試題怎么用 List 實現(xiàn)消息隊列LPUSH生產(chǎn)者BRPOP消費者阻塞讀取。怎么取固定窗口內(nèi)的最新內(nèi)容LRANGE key 0 N。為什么 Redis 的 List 做消息隊列不靠譜因為消息可能丟失、沒有確認機制、沒有回溯和死信隊列專業(yè)場景還是要用 MQ。4.2 HashHash 底層是 ziplist 或 hashtable。當 field 數(shù)量少且 value 長度短時用 ziplist 當超過閾值后轉(zhuǎn)為 hashtable。Hash 高頻場景存儲對象屬性比如用戶信息HSET user:1001 name zhangsan age 25。減少序列化轉(zhuǎn)換開銷比 String 存 JSON 更便于修改單個字段。電商購物車每個用戶一整個 Hashfield 是商品 IDvalue 是數(shù)量。面試常問Hash 和 String 存對象怎么選如果對象經(jīng)常需要整體讀取String 更合適如果只修改其中某個字段Hash 更省內(nèi)存和帶寬。4.3 SetSet 底層是 intset 或 hashtable。它的核心特性是無序、不允許重復(fù)、支持集合運算。高頻考題用戶標簽、興趣推薦SADD添加SINTER求共同標簽。抽獎去重SPOP隨機彈出。點贊去重SADD保證一個用戶只能點贊一次。4.4 ZSetZSet 是面試重災(zāi)區(qū)。底層是跳表skiplist dict。dict 用于存儲 member 到 score 的映射跳表用于按 score 排序和范圍查詢。高頻考題排行榜ZADD leaderboard 100 user1ZREVRANGE leaderboard 0 9 WITHSCORES。延遲隊列score 存未來執(zhí)行時間戳消費端用ZRANGEBYSCORE取到期任務(wù)?；瑒哟翱谙蘖鱯core 用時間戳每次請求前刪除窗口外數(shù)據(jù)再統(tǒng)計窗口內(nèi)數(shù)量。面試官常問為什么 ZSet 用跳表而不用紅黑樹答案是跳表實現(xiàn)簡單區(qū)間查找性能穩(wěn)定而且 Redis 需要支持ZRANGE這類范圍操作。Redis 的作者 antirez 在源碼注釋中提到跳表比紅黑樹更易實現(xiàn)、更易調(diào)試這是官方層面的理由。5. Redis 持久化RDB 與 AOF5.1 RDB 快照RDB 是全量快照將某一時刻的數(shù)據(jù)寫入二進制文件。默認觸發(fā)策略是save 900 1、save 300 10、save 60 10000意味著 900 秒內(nèi)至少 1 次修改就觸發(fā)快照。RDB 的優(yōu)點文件緊湊適合備份和災(zāi)難恢復(fù)。恢復(fù)速度快。子進程做 fork主進程不阻塞磁盤 IO。RDB 的缺點可能會丟失上一次快照之后的數(shù)據(jù)。fork 時如果內(nèi)存量巨大短暫阻塞風險存在。面試題RDB 怎么做到不阻塞主進程答案是使用 fork 寫時復(fù)制Copy On Write機制。fork 瞬間子進程共享父進程內(nèi)存之后主進程修改某頁內(nèi)存時才會復(fù)制出一個副本因此 RDB 過程中主進程通?？梢岳^續(xù)提供寫服務(wù)但 fork 本身需要消耗時間。5.2 AOF 日志AOF 記錄每個寫命令以追加方式寫入文件通過appendfsync策略控制磁盤同步配置項說明安全性always每次寫入都刷盤最安全性能低everysec每秒刷一次默認最多丟 1 秒數(shù)據(jù)no由操作系統(tǒng)決定性能高安全性低AOF 重寫當文件過大時Redis 會根據(jù)當前數(shù)據(jù)生成最小命令集合并寫成一個新文件。重寫過程也是通過子進程完成同時主進程將新寫命令緩存下來重寫結(jié)束后再追加。5.3 怎么選2026 年的面試好的回答是“生產(chǎn)環(huán)境通常兩種都開AOF 保證數(shù)據(jù)安全RDB 做快速恢復(fù)。Redis 重啟時優(yōu)先加載 AOF因為 AOF 數(shù)據(jù)完整性更高。如果允許丟幾分鐘數(shù)據(jù)只開 RDB 也可以?！?. Redis 緩存三大問題穿透、擊穿、雪崩這是 Redis 面試題中命中率最高的模塊。熱搜詞“緩存失效、緩存治理、線上緩存”都和這一塊密切相關(guān)。6.1 緩存穿透概念查詢一個不存在的數(shù)據(jù)Redis 查不到數(shù)據(jù)庫也查不到請求直接打到數(shù)據(jù)庫。如果有惡意攻擊者不斷構(gòu)造不存在的 key數(shù)據(jù)庫會被拖垮。解決思路緩存空值不存在的 key 也緩存一個空值設(shè)置短過期時間比如 60 秒。布隆過濾器在緩存前加一層 Bloom Filter判斷 key 是否可能存在。參數(shù)校驗接口層攔截非法請求。代碼示例public String getUserById(String userId) { // 1. 查 Redis String user redisTemplate.opsForValue().get(user: userId); if (user ! null) { return user; } // 2. 緩存中沒有查數(shù)據(jù)庫 UserDO userDO userMapper.selectById(userId); if (userDO null) { // 3. 緩存空值防止穿透 redisTemplate.opsForValue().set(user: userId, , 60, TimeUnit.SECONDS); return null; } // 4. 回寫緩存 String json JSON.toJSONString(userDO); redisTemplate.opsForValue().set(user: userId, json, 30, TimeUnit.MINUTES); return json; }6.2 緩存擊穿概念某個熱 key 在緩存過期的一瞬間大量并發(fā)請求同時打到數(shù)據(jù)庫。它和穿透的區(qū)別是key 在數(shù)據(jù)庫里存在只是緩存剛好過期。解決思路互斥鎖重建緩存時加鎖只讓一個線程查數(shù)據(jù)庫并寫緩存其他線程等待重試。邏輯過期不給 key 設(shè)置物理過期時間而是在 value 里保存邏輯過期時間后臺異步更新。熱點 key 永不過期物理上不設(shè)置過期時間但在邏輯層做定時刷新。互斥鎖代碼示例分布式鎖的應(yīng)用場景public String queryHotData(String key) { String value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } String lockKey lock: key; String lockValue UUID.randomUUID().toString(); Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, lockValue, 10, TimeUnit.SECONDS); if (Boolean.TRUE.equals(locked)) { try { // 雙重檢查 value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } // 查數(shù)據(jù)庫 value queryDatabase(key); redisTemplate.opsForValue().set(key, value, 30, TimeUnit.MINUTES); return value; } finally { // 釋放鎖使用 Lua 腳本保證原子性 String script if redis.call(get,KEYS[1]) ARGV[1] then return redis.call(del,KEYS[1]) else return 0 end; redisTemplate.execute(new DefaultRedisScript(script, Long.class), Collections.singletonList(lockKey), lockValue); } } // 沒有獲取到鎖等待后重試 try { Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return queryHotData(key); }6.3 緩存雪崩概念大量 key 在同一時間集中過期或者 Redis 整個實例宕機導(dǎo)致大量請求直接壓到數(shù)據(jù)庫。解決思路過期時間加隨機值讓過期時間分散避免“集體過期”。多級緩存本地緩存Caffeine Redis 分布式緩存。Redis 高可用主從 哨兵或者 Cluster 模式。服務(wù)降級與熔斷數(shù)據(jù)庫壓力過大時快速失敗或返回空數(shù)據(jù)。構(gòu)建緩存加鎖參考緩存擊穿的互斥鎖方案。代碼示例// 給過期時間加隨機值 int baseTimeout 60 * 60; int randomTimeout new Random().nextInt(600); redisTemplate.opsForValue() .set(key, value, baseTimeout randomTimeout, TimeUnit.SECONDS);6.4 緩存一致性先更新數(shù)據(jù)庫還是先刪緩存這是個“沒有唯一標準答案”的問題但面試官要看你能不能把兩種方案的利弊講清。方案一先更新數(shù)據(jù)庫再刪除緩存。優(yōu)點簡單。缺點刪除緩存失敗時緩存里是舊數(shù)據(jù)。方案二先刪緩存再更新數(shù)據(jù)庫。缺點并發(fā)下存在“先刪緩存后寫數(shù)據(jù)庫中間有請求把舊數(shù)據(jù)寫回緩存”的問題。方案三延遲雙刪。public void updateUser(UserDO userDO) { // 1. 先刪緩存 redisTemplate.delete(user: userDO.getId()); // 2. 更新數(shù)據(jù)庫 userMapper.updateById(userDO); // 3. 延遲 500ms 后再次刪除 scheduledExecutor.schedule(() - { redisTemplate.delete(user: userDO.getId()); }, 500, TimeUnit.MILLISECONDS); }方案四訂閱 binlog如 Canal 刪除緩存。最穩(wěn)妥適合對一致性要求極高的場景。面試回答的口徑是緩存一致性無法做到完全強一致只能根據(jù)業(yè)務(wù)容忍度選擇最終一致性方案。核心是“緩存只是加速層數(shù)據(jù)庫才是最終數(shù)據(jù)源”。7. Redis 分布式鎖從 SET NX 到 Redisson 到 Redlock7.1 什么是分布式鎖分布式鎖是為了解決多個進程或服務(wù)實例之間互斥訪問共享資源的問題。Java 里的synchronized和ReentrantLock只能鎖單機分布式環(huán)境下必須借助外部存儲。Redis 分布式鎖的基本原則互斥性任意時刻只有一個實例能持有鎖。原子性加鎖和釋放鎖要保證原子操作。超時釋放避免鎖持有者宕機導(dǎo)致死鎖?？芍厝胄酝粋€線程可以重復(fù)獲取鎖。自動續(xù)期業(yè)務(wù)執(zhí)行時間超過鎖超時時間時能夠自動續(xù)期。7.2 基礎(chǔ)實現(xiàn)SET NX EX最簡單的加鎖命令SET lock:order:1001 uuid-xxx NX EX 30NX表示只有當 key 不存在時才設(shè)置成功EX 30表示鎖 30 秒后自動過期。對應(yīng)的 Java 代碼SetParams params SetParams.setParams().nx().ex(Duration.ofSeconds(30)); String result jedis.set(lock:order:1001, requestId, params); if (OK.equals(result)) { // 獲取鎖成功 }釋放鎖不是簡單的DEL而是要驗證 value 是自己的然后執(zhí)行刪除。如果直接DEL可能刪掉別人的鎖。正確釋放鎖必須用 Lua 腳本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end這段 Lua 腳本保證了“判斷 key 的 value 是否等于當前持有鎖的標識”和“刪除 key”兩個操作的原子性。面試時請背誦這段腳本并解釋為什么不能先用GET判斷再用DEL因為GET和DEL是兩條命令中間可能發(fā)生其他線程持有鎖或者鎖已經(jīng)過期并已被別人獲取直接DEL會誤刪別人的鎖。7.3 原生命令方案有哪些缺陷沒有自動續(xù)期。如果業(yè)務(wù)執(zhí)行超過鎖過期時間鎖自動失效其他線程會進入臨界區(qū)。不具備可重入能力。加鎖失敗后需要自己實現(xiàn)輪詢等待。解決方式使用 Redisson 客戶端。它內(nèi)置了看門狗WatchDog機制和可重入鎖實現(xiàn)。7.4 Redisson 分布式鎖實戰(zhàn)Autowired private RedissonClient redissonClient; public void createOrder(OrderDTO orderDTO) { String lockKey lock:order: orderDTO.getOrderId(); RLock lock redissonClient.getLock(lockKey); boolean isLocked false; try { // 嘗試加鎖最多等待 5 秒自動釋放 30 秒 isLocked lock.tryLock(5, 30, TimeUnit.SECONDS); if (!isLocked) { throw new RuntimeException(系統(tǒng)繁忙請稍后重試); } // 業(yè)務(wù)邏輯檢查庫存、創(chuàng)建訂單、扣減庫存 doCreateOrder(orderDTO); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(獲取鎖被中斷, e); } finally { if (isLocked lock.isHeldByCurrentThread()) { lock.unlock(); } } }Redisson 的 WatchDog 默認在鎖過期前自動續(xù)期默認續(xù)期時間是 30 秒。如果你沒有顯式設(shè)置 leaseTime看門狗就會啟動。如果你在tryLock中指定了leaseTime看門狗不會自動續(xù)期。面試官常問看門狗的實現(xiàn)原理是什么回答思路是Redisson 在獲取鎖成功后會啟動一個定時任務(wù)每隔leaseTime / 3時間也就是默認 10 秒檢查鎖是否仍然被自己持有如果是就重置鎖的過期時間到 30 秒。任務(wù)在當前線程釋放鎖后停止。7.5 Redlock多節(jié)點高可用分布式鎖Redlock 是 Redis 官方提出的算法核心是“獲取鎖請求依次發(fā)給 N 個獨立 Redis Master超過半數(shù)節(jié)點加鎖成功且加鎖總耗時小于鎖過期時間才算獲取鎖成功”。Config config new Config(); config.useSentinelServers() .addSentinelAddress(redis://node1:6379, redis://node2:6379, redis://node3:6379) .setMasterName(mymaster); RedissonClient client Redisson.create(config); RLock lock client.getLock(redlock:order);Redlock 的爭議點存在 Redis 節(jié)點時鐘跳躍導(dǎo)致的鎖失效問題。客戶端持有鎖期間發(fā)生 GC 停頓可能導(dǎo)致鎖過期但業(yè)務(wù)還在執(zhí)行。并不適合所有場景不少架構(gòu)師認為它不如“數(shù)據(jù)庫唯一索引 事務(wù)”。面試回答建議先講清楚 Redlock 的算法過程再補充它的應(yīng)用邊界。能提到“Martin Kleppmann 和 antirez 關(guān)于 Redlock 的爭論”是加分項這證明你不僅會背框架還了解分布式系統(tǒng)領(lǐng)域的經(jīng)典討論。7.6 分布式鎖面試必背清單分布式鎖要滿足哪些條件SET NX EX 和 SETNX 的區(qū)別是什么為什么釋放鎖要用 Lua 腳本Redisson 看門狗的工作原理是什么Redlock 怎么解決主節(jié)點宕機問題Redlock 有什么缺點分布式鎖和數(shù)據(jù)庫悲觀鎖、樂觀鎖怎么選秒殺場景中分布式鎖和 Redis 原子操作DECR誰更好鎖重入怎么實現(xiàn)鎖的粒度怎么設(shè)計建議按用戶維度、訂單維度拆鎖而不是全局鎖。8. Redis 事務(wù)與 Lua 腳本8.1 Redis 事務(wù)的基本機制Redis 事務(wù)通過MULTI、EXEC、DISCARD、WATCH實現(xiàn)。MULTI開啟事務(wù)。EXEC執(zhí)行事務(wù)隊列中的所有命令。DISCARD丟棄事務(wù)。WATCH樂觀鎖監(jiān)聽 key如果執(zhí)行時 key 被其他客戶端修改事務(wù)失敗。Redis 事務(wù)不支持回滾。如果事務(wù)執(zhí)行過程中某條命令出錯前面的命令已經(jīng)生效后面的命令繼續(xù)執(zhí)行不會回滾。面試題Redis 事務(wù)為什么不能回滾官方文檔的觀點是Redis 命令只有在語法錯誤或類型錯誤時才會失敗大部分錯誤可以通過開發(fā)階段發(fā)現(xiàn)引入回滾會顯著增加復(fù)雜度與 Redis 追求簡單高效的設(shè)計原則沖突。8.2 Lua 腳本真正的原子性Redis 2.6 開始支持 Lua 腳本EVAL命令會原子執(zhí)行腳本整個腳本執(zhí)行期間不會插入其他命令。這是分布式鎖釋放、限流、批量操作的底層基礎(chǔ)。-- 簡單的庫存扣減腳本 local stock redis.call(GET, KEYS[1]) if not stock then return -1 end if tonumber(stock) tonumber(ARGV[1]) then return 0 end redis.call(DECRBY, KEYS[1], ARGV[1]) return 1調(diào)用腳本redis-cli -p 6379 EVAL ... 1 stock:1001 1在 Redisson 源碼中很多操作都用 Lua 腳本封裝。比如 tryLock 的加鎖邏輯就是一段 Luaif (redis.call(exists, KEYS[1]) 0) then redis.call(hset, KEYS[1], ARGV[2], 1); redis.call(pexpire, KEYS[1], ARGV[1]); return nil; end if (redis.call(hexists, KEYS[1], ARGV[2]) 1) then redis.call(hincrby, KEYS[1], ARGV[2], 1); redis.call(pexpire, KEYS[1], ARGV[1]); return nil; end return redis.call(pttl, KEYS[1]);這里的hset說明 Redisson 可重入鎖是用 Hash 結(jié)構(gòu)實現(xiàn)的field 是線程唯一標識value 是重入計數(shù)。8.3 Pipeline 與批量操作Pipeline 不是事務(wù)。它通過一次網(wǎng)絡(luò)請求發(fā)送多條命令減少 RTT往返時延適用于批量寫入場景。Redis Cluster 模式下Pipeline 要求命令的 key 必須落在同一個槽位否則可能報錯。ListObject results redisTemplate.executePipelined((RedisCallbackObject) connection - { for (int i 0; i 10000; i) { connection.stringCommands().set( (pipeline:key: i).getBytes(), (value: i).getBytes()); } return null; });9. Redis 集群架構(gòu)主從、哨兵、Cluster9.1 主從復(fù)制主從復(fù)制是 Redis 高可用的基礎(chǔ)。一個 Master 可以掛多個 SlaveSlave 只提供讀服務(wù)。同步過程簡要描述Slave 發(fā)送PSYNC命令。Master 執(zhí)行BGSAVE生成 RDB 文件同時把后續(xù)寫命令緩存到緩沖區(qū)。將 RDB 文件發(fā)給 SlaveSlave 加載。把緩沖區(qū)的寫命令發(fā)送給 SlaveSlave 回放最終達到一致。主從復(fù)制的坑復(fù)制風暴多個 Slave 同時全量復(fù)制Master 壓力大。主從延遲從節(jié)點讀取到舊數(shù)據(jù)。腦裂網(wǎng)絡(luò)分區(qū)時Master 和 Slave 都能對外提供寫服務(wù)恢復(fù)后數(shù)據(jù)沖突。9.2 哨兵模式哨兵Sentinel負責監(jiān)控主節(jié)點狀態(tài)主節(jié)點宕機后自動從從節(jié)點中選舉出一個新的主節(jié)點。工作流程每個哨兵周期性向所有節(jié)點發(fā)送PING。主觀下線某個哨兵發(fā)現(xiàn)主節(jié)點超時?？陀^下線多個哨兵投票確認主節(jié)點真的不可用。選舉 Leader 哨兵。從從節(jié)點中選出新主節(jié)點。通知其他從節(jié)點和新客戶端更新主節(jié)點地址。哨兵模式解決了主從復(fù)制中的“主節(jié)點宕機后無法自動切換”的問題但整個集群仍然只有一個主節(jié)點寫寫能力有限。9.3 Redis Cluster真正的分布式Redis Cluster 采用無中心化架構(gòu)數(shù)據(jù)通過哈希槽Hash Slot分布。整個集群默認有 16384 個槽位每個節(jié)點負責一部分槽位。# 創(chuàng)建集群三個主節(jié)點 三個從節(jié)點 redis-cli --cluster create \ 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \ 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \ --cluster-replicas 1槽位計算公式hash_slot CRC16(key) % 16384Cluster 模式下客戶端連接任意節(jié)點都能訪問。如果 key 不在當前節(jié)點節(jié)點會返回MOVED重定向指令客戶端根據(jù)返回信息重新請求正確的節(jié)點。(error) MOVED 866 127.0.0.1:7002Cluster 的面試核心點為什么是 16384 個槽因為 CRC16 算法產(chǎn)生 16 位二進制數(shù)取值范圍是 0 到 65535。Redis 作者經(jīng)過評估認為 16384 個槽在集群規(guī)模、心跳消息傳輸大小和遷移復(fù)雜度之間達到了合理平衡。為什么不把每個節(jié)點上的數(shù)據(jù)用一致性哈希一致性哈希需要客戶端做哈希環(huán)計算Cluster 的槽位機制讓數(shù)據(jù)遷移更精確。Cluster 擴容過程新節(jié)點加入從其他節(jié)點遷移部分槽位數(shù)據(jù)。整個遷移過程中客戶端訪問被遷移的 key會收到ASK重定向。9.4 集群模式下的分布式鎖Redis Cluster 模式下使用 Redisson 仍然可行但它的鎖天然綁定了某個 key通過GETSLOT找到對應(yīng)節(jié)點。Redlock 方案在 Cluster 環(huán)境中依然有適用場景但復(fù)雜度會上升。更穩(wěn)妥的做法是結(jié)合業(yè)務(wù)把鎖的 key 設(shè)計成同一個槽位比如lock:{order}:{orderId}利用哈希標簽保證同一個訂單的鎖落在同一節(jié)點。10. Redis 高級用法與常見設(shè)計題10.1 基于 Redis 的限流方案固定窗口限流String key rate:limit: userId; Long count redisTemplate.opsForValue().increment(key); if (count 1) { redisTemplate.expire(key, 60, TimeUnit.SECONDS); } if (count 100) { throw new RuntimeException(請求過于頻繁); }滑動窗口限流用 ZSetString key rate:sliding: userId; long now System.currentTimeMillis(); long windowSize 60_000L; int maxCount 100; redisTemplate.opsForZSet().removeRangeByScore(key, 0, now - windowSize); Long count redisTemplate.opsForZSet().zCard(key); if (count ! null count maxCount) { throw new RuntimeException(請求過于頻繁); } redisTemplate.opsForZSet().add(key, String.valueOf(now), now); redisTemplate.expire(key, 60, TimeUnit.SECONDS);令牌桶算法更適合需要突發(fā)流量控制的場景但在純 Redis 實現(xiàn)中需要維護令牌數(shù)和上次補充時間通常用 Lua 腳本完成。10.2 排行榜// 添加分數(shù) redisTemplate.opsForZSet().add(rank:game:1001, player:1, 1000); redisTemplate.opsForZSet().incrementScore(rank:game:1001, player:2, 500); // 獲取前 10 SetZSetOperations.TypedTupleObject top10 redisTemplate.opsForZSet().reverseRangeWithScores(rank:game:1001, 0, 9); // 獲取某個玩家的排名 Long rank redisTemplate.opsForZSet().reverseRank(rank:game:1001, player:1);10.3 延遲隊列String key delay:order:timeout; // 生產(chǎn)端訂單創(chuàng)建 30 分鐘后自動取消 redisTemplate.opsForZSet().add(key, orderId, System.currentTimeMillis() 30 * 60 * 1000); // 消費端輪詢到期元素 SetObject expiredOrders redisTemplate.opsForZSet() .rangeByScore(key, 0, System.currentTimeMillis(), 0, 100);10.4 秒殺系統(tǒng)設(shè)計秒殺場景的核心是“防止超賣 限制并發(fā)”。Redis 方案預(yù)熱庫存到 Redis用DECR扣減。攔截重復(fù)請求用 Set 保存用戶 ID。異步下單扣減成功后發(fā)送 MQ數(shù)據(jù)庫異步完成訂單寫入。public boolean seckill(String userId, String goodsId) { // 1. 判斷是否已經(jīng)購買過 Boolean hasUser redisTemplate.opsForSet().isMember(seckill:users: goodsId, userId); if (Boolean.TRUE.equals(hasUser)) { return false; } // 2. 扣減庫存 Long stock redisTemplate.opsForValue().decrement(seckill:stock: goodsId); if (stock null || stock 0) { // 恢復(fù)庫存并返回失敗 redisTemplate.opsForValue().increment(seckill:stock: goodsId); return false; } // 3. 記錄用戶 redisTemplate.opsForSet().add(seckill:users: goodsId, userId); return true; }真實生產(chǎn)環(huán)境中DECR扣減后如果數(shù)據(jù)庫寫失敗需要回補庫存整個鏈路還需要配合事務(wù)消息做最終一致性。面試時注意點只講 Redis 扣庫存是不夠的要講清楚“Redis 做前置攔截數(shù)據(jù)庫做最終確認”。11. Redis 性能優(yōu)化與常見問題排查11.1 大 Key 問題大 Key 指的是 String 類型 value 過大或集合類型元素數(shù)量過多。大 Key 會導(dǎo)致刪除時阻塞主線程。遷移時占用大量帶寬。慢查詢增多。排查方式redis-cli --bigkeys處理方式拆分大 key。對 Hash 使用HSCAN分批刪除。使用UNLINK異步刪除。11.2 熱 Key 問題熱 Key 指某個 key 訪問量極高單節(jié)點成為瓶頸。解決思路本地緩存 Redis。訪問打散hotkey_1、hotkey_2多個副本讀請求隨機讀任一副本寫時更新所有副本。熱點 key 永不過期 后臺刷新。11.3 慢查詢通過SLOWLOG GET查看慢查詢命令。redis-cli -p 6379 slowlog get 10常見的慢命令KEYS *、HGETALL、SMEMBERS、ZRANGEBYSCORE在一個超大的 key 上執(zhí)行。生產(chǎn)環(huán)境禁止使用KEYS *應(yīng)該用SCAN代替。11.4 內(nèi)存碎片與淘汰策略Redis 刪除過期 key 使用惰性刪除 定期刪除。內(nèi)存達到maxmemory上限后觸發(fā)淘汰策略策略含義noeviction不淘汰直接報錯allkeys-lru對全部 key 使用 LRU 算法volatile-lru對設(shè)置了過期時間的 key 使用 LRUallkeys-random隨機淘汰volatile-random對設(shè)置過期時間的 key 隨機淘汰volatile-ttl對設(shè)置過期時間的 key 中剩余壽命更短的 key 優(yōu)先淘汰高頻面試題Redis 的 LRU 是真正的 LRU 嗎不是。Redis 的近似 LRU 通過抽樣方式淘汰默認采樣 5 個 key從中選出最近最少使用的 key 淘汰因此它不是完全精確的 LRU。11.5 Redis 連接數(shù)打滿怎么辦排查思路INFO clients查看當前連接數(shù)。CONFIG GET maxclients查看最大連接數(shù)限制。檢查客戶端是否有連接泄漏?？紤]使用連接池。Spring Data Redis 的 Lettuce 默認基于 Netty連接是共享的連接數(shù)通常不是瓶頸。如果是 Jedis務(wù)必配置 JedisPool。12. 2026 Redis 面試答題通用框架12.1 是什么 - 解決了什么問題 - 底層機制 - 優(yōu)缺點 - 使用場景這套五段式結(jié)構(gòu)幾乎適用所有 Redis 面試題。比如被問到“Redis 主從復(fù)制”不要只答“主節(jié)點寫從節(jié)點讀”按下面的順序組織回答是什么主從復(fù)制是一臺主節(jié)點和一臺或多臺從節(jié)點之間的數(shù)據(jù)副本同步機制。解決什么問題讀寫分離、故障轉(zhuǎn)移的節(jié)點基礎(chǔ)、橫向擴展讀能力。底層機制全量同步 增量同步復(fù)制積壓緩沖區(qū)PSYNC 命令。優(yōu)缺點實現(xiàn)簡單、讀擴展方便但主從延遲存在故障自動轉(zhuǎn)移需要哨兵。使用場景讀多寫少、一致性要求不高的場景。12.2 緩存一致性問題的萬能套路先確認一致性等級強一致還是最終一致。給出技術(shù)方案Cache Aside、延遲雙刪、binlog 訂閱。指出潛在問題刪除緩存失敗、并發(fā)窗口。給出補償方案消息隊列重試本地消息表。挑明結(jié)論分布式環(huán)境沒有免費的強一致最終一致是常態(tài)。12.3 像面試官一樣總結(jié)核心技術(shù)面試官問 Redis 時會格外看重你對“為什么”的把握。隨便抽一個知識點比如“為什么 Redis 使用單線程執(zhí)行命令”你如果能從 IO 多路復(fù)用、內(nèi)存訪問時延、避免鎖競爭、命令原子性四個角度回答基本上就能讓面試官認可你的基礎(chǔ)。13. 3 天突擊路線規(guī)劃第 1 天數(shù)據(jù)結(jié)構(gòu)、持久化、緩存問題上午Redis 五大數(shù)據(jù)結(jié)構(gòu) 底層實現(xiàn)SDS、跳表、quicklist。下午RDB/AOF 緩存穿透、擊穿、雪崩 緩存一致性。晚上用 Java 寫緩存三大問題的 demo把緩存空值、互斥鎖、延遲雙刪的代碼跑通。第 2 天分布式鎖、事務(wù)、Lua上午SET NX EX、Lua 腳本、Redisson 可重入鎖。下午Redlock、看門狗、鎖續(xù)期、鎖粒度、鎖誤刪。晚上用 Redisson 實現(xiàn)一個庫存扣減服務(wù)模擬并發(fā)場景測試超賣。第 3 天集群、性能、綜合設(shè)計上午主從復(fù)制 哨兵模式搭建用redis-cli --cluster搭建 Cluster。下午大 Key、熱 Key、慢查詢、淘汰策略、Pipeline。晚上刷題。覆蓋 85 問特別是設(shè)計題秒殺、排行榜、延遲隊列、好友關(guān)系。14. 常見問題與排查清單問題現(xiàn)象可能原因排查方式解決方案分布式鎖失效業(yè)務(wù)執(zhí)行時間超過鎖過期時間檢查業(yè)務(wù)耗時和鎖 leaseTime使用 Redisson 看門狗自動續(xù)期緩存擊穿熱點 key 過期瞬間大量并發(fā)請求觀察 Redis QPS 和數(shù)據(jù)庫慢 SQL互斥鎖、邏輯過期緩存雪崩大量 key 同一時間過期檢查過期時間配置過期時間加隨機值Redis 內(nèi)存暴漲大 Key 或配置未限制redis-cli --bigkeysINFO memory拆分 key、設(shè)置 maxmemory 策略主從數(shù)據(jù)不一致網(wǎng)絡(luò)延遲導(dǎo)致復(fù)制延遲INFO replication查看 offset優(yōu)化網(wǎng)絡(luò)、考慮強一致場景不用緩存Cluster 寫入報 MOVED客戶端沒有做重定向處理檢查客戶端版本使用支持 Cluster 的客戶端如 Lettuce、Redisson連接數(shù)打滿客戶端沒有使用連接池INFO clients增加連接池配置或限制非法連接15. 最佳實踐與合規(guī)提醒任何緩存方案首先明確業(yè)務(wù)容忍度允許丟多久數(shù)據(jù)、允許多大延遲。分布式鎖不是萬能的DECR、Lua、ZSet 都能在特定場景取代鎖。生產(chǎn)環(huán)境謹慎使用KEYS、FLUSHALL、CONFIG SET。維護好 Redis 的監(jiān)控指標包括INFO stats、INFO replication、INFO memory、SLOWLOG。涉及用戶隱私數(shù)據(jù)緩存時必須設(shè)置合理過期時間并做數(shù)據(jù)脫敏。不要用 Redis 存放明文密碼、身份證號等敏感信息必須加密存儲且符合個人信息保護相關(guān)法規(guī)要求。對業(yè)務(wù)中使用的 Redis 命令和腳本做權(quán)限控制避免未授權(quán)訪問。線上 Redis 實例必須配置密碼禁止綁定公網(wǎng) IP。發(fā)布新任務(wù)或做壓測前先在小規(guī)模環(huán)境驗證觀察內(nèi)存和 CPU 變化不要直接在生產(chǎn)環(huán)境執(zhí)行批量腳本。16. 總結(jié)與下一步Redis 面試在 2026 年真正拉開差距的地方在于你能否把分布式鎖、緩存和集群三個模塊打通理解。分布式鎖背后的原子性、Redis 事務(wù)和 Lua 腳本是一套東西緩存穿透、擊穿、雪崩背后是緩存和數(shù)據(jù)庫的一致性模型集群的背后是數(shù)據(jù)分片、復(fù)制和高可用的權(quán)衡。建議你先把基礎(chǔ)環(huán)境搭好再按第一天、第二天、第三天的小步任務(wù)逐個驗證。最容易踩的坑不是不會背概念而是花大量時間背八股卻連SET NX EX和 Lua 腳本都沒跑過一遍。真正的勝利是把代碼跑通、把現(xiàn)象記錄下來、把差異講清楚這樣面試時你說出來的每一個結(jié)論才落得了地。