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