最近跟幾個準備跳槽的朋友聊大家一致的感覺是2026年的Java后端面試里Redis幾乎是躲不掉的一關(guān)。不論你面的是初級還是資深數(shù)據(jù)類型、緩存穿透、分布式鎖這老三樣基本必考區(qū)別只在于追問的深度。這篇內(nèi)容是我結(jié)合近期各大廠面試記錄整理出的30道Redis高頻題每題都從Java實戰(zhàn)的角度給到答題思路和關(guān)鍵細節(jié)不是讓你干背八股而是讓你在面試現(xiàn)場接得住追問。題目的組織方式是按主題走的從底層數(shù)據(jù)結(jié)構(gòu)到持久化、高可用、緩存治理、分布式鎖最后到面試官最愛追問的加分細節(jié)。建議你別只把它當題庫刷最好每一題都能用自己的話講一遍面試的時候才不會被當成背答案。1. 數(shù)據(jù)類型與底層結(jié)構(gòu)先搞清楚Redis到底怎么存數(shù)據(jù)1.1 五種基礎(chǔ)類型與底層實現(xiàn)String、List、Hash、Set、ZSet分別是什么第1題Redis有哪些數(shù)據(jù)類型底層分別用什么結(jié)構(gòu)實現(xiàn)這是Redis面試最開場的問題也最容易被低估。簡單回答五種基本類型String、List、Hash、Set、ZSet加上Bitmaps、HyperLogLog、Geo、Stream是最起碼的。但面試官真正想聽的是底層結(jié)構(gòu)。我用表格總結(jié)一下各類型的底層實現(xiàn)這樣你在腦子里會有一個整體圖景。類型底層數(shù)據(jù)結(jié)構(gòu)老版本底層數(shù)據(jù)結(jié)構(gòu)新版本演進說明Stringint / SDSint / SDS整數(shù)用int編碼非整數(shù)用SDS動態(tài)字符串Listziplist linkedlistquicklistquicklist是多個ziplist組成的雙向鏈表Hashziplist / hashtablelistpack / hashtable小哈希用listpack節(jié)省內(nèi)存Setintset / hashtableintset / hashtable全整數(shù)且量小時用intsetZSetziplist / skiplistlistpack / skiplist有序集合跳表哈希表組合回答時需要提到Redis 7.0之后ziplist逐步被listpack替代主要是因為ziplist在極端情況下的連鎖更新問題。你要是能主動提這個版本差異面試官會明顯覺得你是跟進過新版的。數(shù)據(jù)結(jié)構(gòu)的選擇不是固定的Redis內(nèi)部會按元素數(shù)量和元素大小做編碼轉(zhuǎn)換。比如Hash當鍵值對數(shù)量不到512默認hash-max-listpack-entries且單個key/value長度不超過64字節(jié)時用listpack超了就轉(zhuǎn)成真正的hashtable。這個小用緊湊結(jié)構(gòu)大用高效結(jié)構(gòu)的思路本質(zhì)是內(nèi)存和性能的權(quán)衡。1.2 String的SDS設(shè)計為什么不直接用C語言的字符串第2題Redis的String底層為什么用SDS而不是直接存C字符串這道題考的是C語言功底和設(shè)計思維。傳統(tǒng)C字符串用char[]存儲以\0作為結(jié)束符隨之而來有三個問題第一獲取長度是O(n)需要從頭遍歷。SDS在結(jié)構(gòu)體頭里維護了一個len字段獲取長度是O(1)。這在Redis這種追求極致的場景里很重要因為STRLEN這種命令會非常頻繁。第二C字符串二進制不安全。只要內(nèi)容里包含\0字符串就會被截斷。SDS用len來判斷長度而不是靠結(jié)束符所以可以存\0、圖片、序列化對象等任意二進制數(shù)據(jù)。做緩存的時候我們經(jīng)常會把Java對象序列化后放進去這個二進制安全特性就特別關(guān)鍵。第三緩沖區(qū)溢出的風險。C字符串拼接前需要手動分配足夠內(nèi)存否則會越界覆蓋相鄰內(nèi)存。SDS的API會檢查剩余空間不夠就自動擴容同時對字符串的修改還帶空間預分配和惰性空間釋放的優(yōu)化避免頻繁申請內(nèi)存?？疾祛l率很高因為這條鏈路可以一直從SDS問到內(nèi)存分配器jemalloc再問到內(nèi)存碎片治理屬于典型的一道題問穿一整個知識面。1.3 跳表與紅黑樹之爭ZSet底層為什么選跳表第3題ZSet的底層為什么用跳表而不是紅黑樹這題我?guī)缀趺看文M面試都會問。先說結(jié)論跳表和紅黑樹的平均查找復雜度都是O(logN)但Redis的場景里跳表有幾個優(yōu)勢。跳表實現(xiàn)起來簡單得多區(qū)間查詢的時候跳表只需要沿著next指針往下走就行而紅黑樹做范圍查詢需要中序遍歷實現(xiàn)復雜。ZSet最核心的操作就是排序和范圍查詢比如ZRANGEBYSCORE跳表是天然貼合這個場景的。還有一個容易被忽略的點跳表的插入、刪除只需要調(diào)整指針不需要像紅黑樹那樣為了維持平衡做旋轉(zhuǎn)和變色。雖然兩者的平均復雜度一樣但跳表在并發(fā)修改場景下的實際開銷更穩(wěn)定。需要補充的是ZSet不是單獨只用跳表而是哈希表跳表的組合哈希表負責按member快速定位分數(shù)跳表負責按分數(shù)排序和范圍查詢。另外Redis還用了dict里面的順序指針這個細節(jié)你要是能說出來面試官會很加分。1.4 高級數(shù)據(jù)類型Bitmap、HyperLogLog、Geo能解決什么問題第4題Bitmap、HyperLogLog、Geo的底層原理和適用場景是什么先說Bitmap。它不是一個獨立的Redis數(shù)據(jù)結(jié)構(gòu)本質(zhì)還是String只是把它當成位數(shù)組來用。底層是SDS存儲的二進制位串可以執(zhí)行SETBIT、GETBIT、BITCOUNT、BITOP這類位操作。一個億級用戶的在線狀態(tài)用Bitmap只需要100000000/8/1024/1024≈12MB左右非常省內(nèi)存。HyperLogLog是基數(shù)統(tǒng)計神器?；诟怕仕惴藴收`差0.81%最典型的場景是UV統(tǒng)計。一個HyperLogLog最多占用12KB內(nèi)存卻能統(tǒng)計2^64級別的基數(shù)。你不能拿到具體是誰只能拿到大約有多少個不重復的。用Java做UV統(tǒng)計的時候一個億級用戶量也不會吃太多Redis內(nèi)存。Geo底層用的是GeoHash把經(jīng)緯度二維坐標編碼成一維的字符串前綴越接近說明地理位置越近。配合GEORADIUS命令可以快速算出附近的人、附近的店鋪。要注意的是Geo在極端情況比如極點附近附近查詢準確率會下降生產(chǎn)上一般不會拿它做厘米級精確定位更多是做LBS的粗篩。第5題你項目里實際用過哪些高級類型這題是送分題但也最容易翻車。我自己的經(jīng)驗是用HyperLogLog做每日UV統(tǒng)計在金數(shù)據(jù)報表上直接展示用Bitmap做用戶簽到一年365天就是365個bit一個人一年簽到記錄不到46字節(jié)用Stream做異步任務(wù)隊列比直接依賴MQ輕量得多你要是能把這些場景結(jié)合你簡歷上的業(yè)務(wù)講出來比單純背定義強十倍。1.5 熱Key和大Key面試官最愛追問的場景題第6題什么叫熱Key線上遇到熱Key怎么處理熱Key指某個key的訪問量QPS極高比如一個爆款商品的詳情緩存、一個明星的粉絲列表。單臺Redis實例上一個key的訪問量一旦超過實例能承受的極限整個實例都會出問題因為Redis是單線程模型一個key過熱會拖垮其他key。應對手段我梳理過核心就四類熱Key打散在key后面拼隨機后綴拆成多個副本分別分布在不同的分片節(jié)點上本地緩存把熱點數(shù)據(jù)短暫緩存到JVM內(nèi)存里比如用Caffeine做一級緩存請求先打本地再打Redis讀寫分離把讀流量分流到從節(jié)點限流降級對讀取熱Key的接口做熔斷防止流量全部壓到Redis面試時最好舉個例子。比如我做商品詳情頁的時候發(fā)現(xiàn)某個秒殺商品的詳情查詢QPS直接飆到幾十萬就是靠JVM本地緩存Redis多副本扛住的。這里有一個細節(jié)本地緩存一定要設(shè)置較短的過期時間比如10秒否則數(shù)據(jù)新鮮度會出問題。第7題什么是大Key如何發(fā)現(xiàn)和治理大Key通常指單個key存儲的value很大。業(yè)界比較接受的判斷標準是String類型的value超過10KB或者集合類型的元素數(shù)量單key超過5000個。大Key危害明顯刪除的時候可能阻塞Redis主線程網(wǎng)絡(luò)傳輸?shù)臅r候耗費帶寬內(nèi)存不均勻?qū)е录荷蠠狳c分片。發(fā)現(xiàn)的手段主要有三種redis-cli --bigkeys命令掃描通過INFO memory觀察內(nèi)存分布在客戶端做DEBUG OBJECT查看序列化長度治理的話String類型可以考慮壓縮比如Snappy或者拆成多個小key集合類型可以按業(yè)務(wù)維度拆分為多個子集合比如按用戶ID哈希到不同的key上。刪除大Key不要直接DEL極端情況下會阻塞實例要用UNLINK異步刪除或者分批SCAN刪除。這部分一定要結(jié)合你自己的運維經(jīng)驗來講比如你曾經(jīng)因為刪一個大KeyRedis發(fā)生短暫卡頓最后怎么排查出來的——這種真實故事面試官非常買賬。2. 持久化與主從復制Redis重啟了數(shù)據(jù)還在不在2.1 RDB和AOF取舍背后的原理第8題Redis的持久化方式有哪些RDB和AOF分別適合什么場景Redis默認單機部署也有持久化目的是防止重啟丟數(shù)據(jù)。兩種方式RDB是快照式持久化。BGSAVE或者自動觸發(fā)的時候Redis fork一個子進程把當前內(nèi)存里的全量數(shù)據(jù)寫入一個二進制dump文件。RDB文件的恢復速度非?？爝m合做冷備也適合做災備恢復。但它的缺點是會丟失兩次快照之間的數(shù)據(jù)丟失量取決于你配置的save策略極端情況可能丟幾分鐘的數(shù)據(jù)。AOF是追加式日志。它把每一條寫命令以Redis協(xié)議格式追加到文件末尾重啟時重放命令來恢復數(shù)據(jù)。AOF保證數(shù)據(jù)安全性的能力更強因為你可以配置成appendfsync always每個命令都刷盤或者appendfsync everysec每秒刷一次。生產(chǎn)上我見過太多人在這塊含糊其辭。你至少要會回答AOF文件體積一般比RDB大恢復速度比RDB慢AOF會出現(xiàn)文件膨脹的問題需要依賴重寫機制壓縮。很多公司做了不做持久化的配置來換極致性能但如果業(yè)務(wù)不能接受重啟丟數(shù)據(jù)千萬別這么玩。第9題AOF重寫機制是干嘛的為什么需要重寫AOF文件記錄的是每條寫命令同一個key可能被反復寫很多次。比如SET a 1、SET a 2、SET a 3AOF文件里存了三條記錄但實際上最終只需要SET a 3這一條。重寫就是把這些冗余的命令壓縮成恢復當前數(shù)據(jù)集所需的最少命令集合。這里有個底層機制值得單獨講AOF重寫不是基于現(xiàn)有AOF文件做的而是基于當前內(nèi)存中的數(shù)據(jù)狀態(tài)生成的。BGREWRITEAOF觸發(fā)后Redis fork子進程用子進程遍歷內(nèi)存數(shù)據(jù)生成新AOF。與此同時主線程的新寫命令會被記錄到AOF重寫緩沖區(qū)子進程完成后把緩沖區(qū)的增量命令追加到新文件尾部。如果你能把這個流程說清楚說明你真的讀過源碼。2.2 混合持久化RDB和AOF的結(jié)合優(yōu)勢第10題什么是混合持久化為什么Redis 4.0之后推薦開啟混合持久化是Redis 4.0引入的方案配置項是aof-use-rdb-preamble yes。它的做法是AOF文件頭部放一個RDB快照RDB之后追加AOF增量日志。這樣做的好處直接解決了AOF恢復慢的問題。因為加載的時候先讀RDB部分就能把大部分數(shù)據(jù)快速恢復剩下的增量日志再重放一下就完了。同時它還解決了RDB丟失數(shù)據(jù)多的問題兩次持久化之間的寫命令依然落地為AOF日志。生產(chǎn)建議是只要你的Redis不是純緩存場景我都建議開混合持久化。配合appendfsync everysec絕大部分場景能做到每秒級別的數(shù)據(jù)可靠性同時恢復速度又不太受影響。第11題RDB持久化的時候Redis會阻塞嗎fork子進程有什么坑SAVE命令會阻塞主線程BGSAVE則不會。后端開發(fā)同學常被追問的就是BGSAVE了。BGSAVE會調(diào)用fork創(chuàng)建一個子進程由子進程負責寫RDB文件。fork這個操作本身是有開銷的尤其在內(nèi)存很大比如20GB的實例上fork瞬間要拷貝頁表會短暫阻塞主線程。這個阻塞時間通常幾十到幾百毫秒取決于內(nèi)存大小和CPU性能。更深一層的機制是寫時復制Copy On Write。子進程生成RDB期間主線程收到的寫請求會修改頁表對應的內(nèi)存頁才會復制一份出來所以子進程生成的RDB文件代表的是fork那一刻的數(shù)據(jù)快照不會因為后來的修改而變化。這就意味著如果子進程生成RDB期間主線程的寫入量大額外的內(nèi)存開銷會很大。面試時能說到這個層次這道題基本就穩(wěn)了。2.3 主從復制全量同步與增量同步的內(nèi)幕第12題Redis主從復制的原理是什么全量復制和增量復制分別發(fā)生在什么時候主從復制靠的是PSYNC協(xié)議。從節(jié)點啟動后向主節(jié)點發(fā)送PSYNC命令帶上主節(jié)點的runid和自己的復制進度offset。全量復制的場景是第一次復制或者主節(jié)點發(fā)現(xiàn)從節(jié)點的復制積壓緩沖repl_backlog)里已經(jīng)沒有它需要的偏移量了。流程是主節(jié)點執(zhí)行BGSAVE生成RDB快照同時把新寫命令緩存到緩沖區(qū)然后通過socket傳給從節(jié)點從節(jié)點清空自己的舊數(shù)據(jù)加載RDB再追加重放緩沖區(qū)里的命令。增量復制發(fā)生在從節(jié)點斷線重連之后只要偏移量還落在主節(jié)點的repl_backlog_buffer里主節(jié)點就只把缺失的命令發(fā)過去不需要重新全量。這里有一個容易被問到但很多資料沒講清楚的當從節(jié)點斷開時間太長積壓緩沖被覆蓋了就會退化為全量復制。所以生產(chǎn)上repl-backlog-size不能設(shè)置太小建議至少設(shè)置為10MB到64MB具體看寫入量。第13題主從復制會有延遲嗎怎么處理一定有延遲。因為復制是異步的主節(jié)點寫完就返回客戶端從節(jié)點靠repl-backlog異步拉取。對于讀多寫少的業(yè)務(wù)從節(jié)點可能讀到舊數(shù)據(jù)。處理方案有幾種強制走主庫讀把關(guān)鍵數(shù)據(jù)讀操作路由到master或者在代碼層面做短暫等待后再讀還有一種實用做法是設(shè)置min-replicas-max-lag來限制從節(jié)點的滯后上限。實際項目里我們做訂單詳情查詢主從架構(gòu)下就直接要求讀主庫因為訂單數(shù)據(jù)一致性優(yōu)先級最高。第14題怎么用Docker部署一套Redis主從你踩過什么坑這個題最近在面試里出現(xiàn)的頻率上升了尤其是那些簡歷里寫了Docker的候選人。我用一個簡單命令說明常用做法# 先拉鏡像 docker pull redis:7.0-alpine # 啟動主節(jié)點 docker run -d --name redis-master -p 6379:6379 -v /data/redis-master:/data redis:7.0-alpine redis-server --appendonly yes # 啟動從節(jié)點并指定主節(jié)點地址 docker run -d --name redis-slave -p 6380:6379 -v /data/redis-slave:/data redis:7.0-alpine redis-server --slaveof redis-master 6379注意這里有個經(jīng)典的坑如果在容器間用--slaveof redis-master 6379必須保證從節(jié)點容器能和主節(jié)點容器互相通信所以你需要提前建一個Docker網(wǎng)絡(luò)docker network create redis-net docker network connect redis-net redis-master redis-slave否則從節(jié)點會一直報MASTER - REPLICA sync started: Cant connect to master。另一個坑是數(shù)據(jù)目錄權(quán)限Redis容器內(nèi)的redis-server默認以redis用戶運行宿主機掛載的目錄如果權(quán)限是root容器會寫不進去日志會一直報權(quán)限錯誤。我在本地驗證的時候直接掛載目錄后忘加--user排查了半天才發(fā)現(xiàn)是權(quán)限問題。Docker部署本身不難難的是網(wǎng)絡(luò)、權(quán)限、持久化這三個點。你面試時能主動講出這些坑說明你確實在生產(chǎn)環(huán)境里操作過。3. 高可用與集群單點掛了怎么辦3.1 哨兵機制如何自動故障轉(zhuǎn)移第15題Redis哨兵機制的原理是什么它會自動切換主從嗎哨兵Sentinel是一個獨立運行的進程用來監(jiān)控主從節(jié)點的健康狀況。多個哨兵會組成一個哨兵集群即使一個哨兵掛了整個監(jiān)控體系依然能工作。流程是這樣的哨兵每秒給主節(jié)點發(fā)送PING如果主節(jié)點在down-after-milliseconds時間內(nèi)沒響應當前哨兵就把它標記為主觀下線。接著它向其他哨兵發(fā)起投票當多個哨兵都認為主節(jié)點下線了超過quorum就升級為客觀下線。然后哨兵集群選舉出一臺leader注意是哨兵之間的選舉由它執(zhí)行故障轉(zhuǎn)移從候選從節(jié)點中選一個提升為新主節(jié)點配置其他從節(jié)點改為復制新主。整個過程對外沒有手動干預。這里有一個容易混淆的概念哨兵的作用不是讓客戶端直連哨兵讀寫而是客戶端通過哨兵獲取當前主節(jié)點的地址。Java項目里用Lettuce或者Jedis接入哨兵模式是直接連接Sentinel的節(jié)點列表讓它返回master的地址。第16題主從切換時出現(xiàn)腦裂怎么辦腦裂是指網(wǎng)絡(luò)分區(qū)導致主節(jié)點和從節(jié)點各自獨立存活比如主節(jié)點所在機器網(wǎng)絡(luò)異常但節(jié)點進程還活著。哨兵認為主掛了從節(jié)點被提升為新的主節(jié)點但老主節(jié)點恢復網(wǎng)絡(luò)后又變回一個獨立的master兩個master同時接收寫入。如果業(yè)務(wù)對數(shù)據(jù)一致性要求高腦裂帶來的影響是災難性的。Redis官方給出的方案是配置兩個參數(shù)min-replicas-to-write 1主節(jié)點接收寫請求前至少要有1個健康從節(jié)點min-replicas-max-lag 10從節(jié)點復制延遲超過10秒主節(jié)點拒絕寫入這樣當網(wǎng)絡(luò)分區(qū)導致主節(jié)點和從節(jié)點失聯(lián)后主節(jié)點的寫入能力會被快速降級把腦裂期間產(chǎn)生的臟數(shù)據(jù)量限制到最小。面試時能說出官方這兩個配置項并且能解釋為什么要限制主節(jié)點寫入而不是一味追求可用性說明你理解分布式系統(tǒng)的權(quán)衡。3.2 集群模式16384個槽位到底怎么分第17題Redis Cluster為什么把數(shù)據(jù)分成16384個槽位為什么不是65536Redis Cluster采用一致性哈希的改良方案——固定槽位。集群把整個數(shù)據(jù)集映射到0~16383共16384個槽位每個節(jié)點負責一部分槽位。寫入一個key時客戶端計算CRC16(key)%16384得到槽位再根據(jù)槽位找到對應的節(jié)點。為什么偏偏是16384有幾個原因。第一Redis實例之間的心跳包需要攜帶自己負責的槽位信息16384個槽位對應的bitmap是16384/82048字節(jié)2KB心跳包可以控制在非常小的體積如果改成65536個槽位bitmap變成8KB心跳包會增大很多。第二集群的節(jié)點規(guī)模通常不會超過1000個16384個槽位用來做數(shù)據(jù)分布已經(jīng)足夠均勻再多沒有實際收益。第三槽位越少節(jié)點重新分片和遷移的粒度就越大維護成本越低。這個題回答好了是區(qū)分背八股和真正理解設(shè)計的分水嶺。第18題客戶端訪問集群時如果key不在當前節(jié)點會怎么樣當客戶端向任意節(jié)點發(fā)送請求節(jié)點會通過CRC16(key)%16384算出槽位判斷是否為本地槽位。如果不是向客戶端返回MOVED 槽位號 目標節(jié)點IP:端口錯誤。這里有一個關(guān)鍵點Java客戶端比如JedisCluster在收到MOVED之后會更新本地路由緩存下次請求直接走正確的節(jié)點。還有一種情況是槽位正在遷移節(jié)點會返回ASK錯誤表示數(shù)據(jù)正在從源節(jié)點遷往目標節(jié)點客戶端需要先向目標節(jié)點發(fā)送ASKING命令再執(zhí)行真正的操作。MOVED是永久性重定向ASK是臨時性重定向這兩個概念區(qū)分不開面試基本扣分。3.3 集群部署的實操心得與常見坑第19題部署Redis Cluster有哪些注意點生產(chǎn)環(huán)境至少要幾個節(jié)點官方推薦集群最少要3個主節(jié)點每個主節(jié)點配一個從節(jié)點也就是3主3從。因為Redis Cluster要求至少3個master才能形成可用的集群而主節(jié)點掛掉時從節(jié)點能頂上來做主備切換。部署時最容易踩的坑包括集群節(jié)點之間需要開放兩個端口一個是客戶端通信端口另一個是集群內(nèi)部總線端口默認端口10000防火墻不放開會導致Gossip通信失敗cluster-enabled yes必須顯式開啟默認是單機模式槽位分配需要覆蓋全部16384個槽位否則集群狀態(tài)是FAIL無法提供服務(wù)節(jié)點之間要保證時鐘基本同步NTP時間偏移過大可能導致主從切換判斷異常我之前在生產(chǎn)環(huán)境用redis-cli --cluster create一次創(chuàng)建完成后把cluster-node-timeout調(diào)成默認值5000毫秒。后來業(yè)務(wù)高峰出現(xiàn)一次節(jié)點抖動集群花了快10秒才完成故障轉(zhuǎn)移業(yè)務(wù)側(cè)明顯感覺到了超時。后來把超時參數(shù)調(diào)小、并加了每個節(jié)點的告警監(jiān)控才把故障影響控制住。做高可用不只是把集群搭起來就完事故障轉(zhuǎn)移耗時也要納入設(shè)計。4. 緩存治理穿透、擊穿、雪崩和數(shù)據(jù)一致性4.1 經(jīng)典三大緩存問題穿透、擊穿、雪崩第20題什么是緩存穿透如何解決大量請求查一個一定不存在的key請求繞過緩存直接打到DB數(shù)據(jù)庫壓力陡增。最常見的是惡意攻擊故意用不存在的ID刷接口。第一種方案是緩存空結(jié)果。查詢DB為空時在Redis里存一個空值TTL設(shè)短一些比如60秒這樣同樣的查詢不會直接打DB。缺點是緩存了大量空值而且數(shù)據(jù)變了之后空值緩存可能還沒過期。第二種方案是布隆過濾器。啟動時把所有合法ID加載進布隆過濾器請求過來先判斷ID是否可能存在不存在就直接返回根本不打DB和Redis。注意布隆過濾器的特性它只能判斷絕對不存在不能判斷一定存在存在誤判。我項目里一般用Redisson的RBloomFilter初始化時指定預計插入量和誤判率。這個方案對緩存穿透的防御最徹底。第21題緩存擊穿和雪崩的區(qū)別是什么怎么應對緩存擊穿指一個熱點key過期瞬間大量并發(fā)請求同時打到了DB就像一根針把緩存打了個洞。緩存雪崩則是大量key同時過期導致大量請求同時打到DB。兩者的核心都是緩存失效瞬間的并發(fā)沖擊區(qū)別在于涉及的范圍擊穿是單個熱點key雪崩是大面積key。擊穿的解法互斥鎖Mutex緩存失效時先嘗試SETNX獲取重建鎖只有一個線程能去查詢DB并回填緩存其他線程短暫等待后重新讀取緩存。邏輯過期緩存里不設(shè)置TTL而是存一個邏輯過期時間。后臺異步線程負責檢測到邏輯過期后重建緩存所有請求直接返回舊緩存不會打到DB。雪崩的解法TTL加隨機值把緩存過期時間設(shè)置為基礎(chǔ)值隨機偏移量避免所有key在同一時刻過期。比如固定5分鐘隨機加0到60秒。多級緩存Redis之上加一層本地緩存CaffeineDB之上加Redis層層擋。熔斷限流極端情況下直接配置Sentinel熔斷保護DB不死。面試的時候最好別只背方案而是說清楚我們當時為什么選互斥鎖而不是邏輯過期。比如邏輯過期適合數(shù)據(jù)一致性要求不太高的場景允許短暫讀到舊數(shù)據(jù)如果業(yè)務(wù)要求盡可能一致就要用互斥鎖雖然多了一點阻塞時間但不會讀到舊值。4.2 緩存與數(shù)據(jù)庫一致性先更新庫還是先刪緩存第22題Cache Aside模式下為什么是先更新數(shù)據(jù)庫再刪除緩存而不是先刪緩存Cache Aside是最常用的緩存模式讀的時候先讀緩存不命中再讀DB并回填寫的時候更新DB然后刪除緩存。先更新DB再刪緩存邏輯上是安全的因為如果先刪緩存而隨后更新DB失敗緩存是空的讀到的是舊DB數(shù)據(jù)嗎其實這里存在窗口問題。我直接給結(jié)論先刪緩存再更新DB如果更新DB失敗DB是舊值緩存又是空的下一次讀會把舊DB值重新寫進緩存不一致的時間窗口非常長。先更新DB再刪緩存即使刪緩存失敗頂多緩存里是舊值但下一次讀還會嘗試刪一次緩存不一致窗口縮短為一個操作的時間。在Java高并發(fā)項目里重點不是選哪個順序而是刪緩存失敗了怎么辦。生產(chǎn)上我們最終的兜底方案有兩層一是利用MQ異步重試刪除緩存二是通過監(jiān)聽數(shù)據(jù)庫的Binlog比如Canal來觸發(fā)緩存刪除。第23題延遲雙刪是什么為什么需要延遲延遲雙刪是處理并發(fā)場景的一種補償方案。流程是先刪除緩存再更新DB休眠一小段時間比如500毫秒再次刪除緩存。這么做的原因是第一次刪除和DB更新之間可能有其他線程讀了DB舊值并回填到緩存導致緩存里變成舊值。如果第二次刪除能把這些寫進去的舊緩存清掉就能規(guī)避這個問題。但延遲雙刪有幾個硬傷休眠時間是拍腦袋定的不好保證覆蓋所有并發(fā)窗口刪緩存是異步的如果第二次刪除失敗依然會不一致。所以別把延遲雙刪當銀彈它是“成本低但效果有限”的兜底。更可靠的做法是Canal訂閱Binlog MQ消息 監(jiān)聽刪除緩存雖然鏈路長但一致性窗口可以控制得很小。面試時能這樣分層次說會顯得你真調(diào)研過。4.3 緩存預熱與Redis序列化的Java坑第24題怎么做緩存預熱系統(tǒng)啟動時緩存全空怎么辦緩存預熱是把熱點數(shù)據(jù)在系統(tǒng)啟動前一次性加載到緩存中。最簡單的方式是Spring Boot項目里用一個ApplicationRunner或CommandLineRunner啟動時執(zhí)行數(shù)據(jù)加載邏輯。Component public class CachePreheatRunner implements CommandLineRunner { Autowired private StringRedisTemplate stringRedisTemplate; Override public void run(String... args) { ListItem items itemMapper.selectAllHotItems(); for (Item item : items) { String key item:hot: item.getId(); // 用JSON序列化成String后寫入預留2小時過期時間 stringRedisTemplate.opsForValue().set(key, JSON.toJSONString(item), 2, TimeUnit.HOURS); } } }需要注意的是預熱時要分批執(zhí)行比如每次500條避免一次性寫入大量key導致Redis主線程阻塞。更穩(wěn)妥的做法是把預熱做成一個獨立任務(wù)在流量進入之前提前5到10分鐘預熱完成而不是等服務(wù)剛啟動就跟業(yè)務(wù)流量搶資源。第25題Java項目里Redis序列化經(jīng)常踩什么坑這個問題實戰(zhàn)價值極高幾乎每次面試都會被問到。Spring Data Redis默認的序列化器是JDK序列化它的后果是key和value在Redis客戶端里看著都是亂碼比如\xAC\xED\x00\x05t\x00\x0...。排查問題和人工清理key的時候會非常痛苦。常見的序列化方案有StringRedisSerializervalue必須是String適合純字符串緩存Jackson2JsonRedisSerializer序列化成JSON可讀性好但反序列化時需要帶上類型信息跨系統(tǒng)時要注意GenericJackson2JsonRedisSerializer會在JSON里寫入class字段反序列化時能還原成具體類型但會額外占一點空間我自己項目里的選擇是key統(tǒng)一用StringRedisSerializervalue用GenericJackson2JsonRedisSerializer。這樣key在客戶端里可讀value又能還原成Java對象。如果你用Redis Desktop Manager這類可視化客戶端查看數(shù)據(jù)會發(fā)現(xiàn)人類能讀懂的JSON排查問題輕松很多。5. 分布式鎖從SET NX到Redisson源碼級拆解5.1 手寫一個可靠的分布式鎖第26題Redis分布式鎖最基本、可靠的實現(xiàn)方式是什么面試必考。最基本也最正確的寫法用一條命令完成加鎖String lockKey lock:order: orderId; String lockValue UUID.randomUUID().toString(); Boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, lockValue, 30, TimeUnit.SECONDS);關(guān)鍵點有三個。第一setIfAbsent就是SET key value NX PXNX保證只有不存在時才寫入px設(shè)置過期時間。必須用一條原子命令否則如果先SETNX再EXPIRE中間進程崩潰會把鎖變成永不過時的死鎖。第二value必須是一個隨機唯一值通常用UUID。這保證了解鎖的時候只刪除自己持有的鎖不會誤刪別人的鎖。第三釋放鎖要用Lua腳本判斷value一致后再刪除String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; stringRedisTemplate.execute( new DefaultRedisScript(script, Long.class), Arrays.asList(lockKey), lockValue );為什么不能先GET再DEL因為這兩步不是原子的。線程A拿到鎖后還沒執(zhí)行完鎖過期了線程B拿到了新鎖此時線程A執(zhí)行完業(yè)務(wù)去DEL就會把線程B的鎖誤刪。有了Lua腳本里的value判斷這個隱患就消除了。第27題鎖過期了但業(yè)務(wù)還沒執(zhí)行完怎么辦這是分布式鎖最經(jīng)典的續(xù)期問題。鎖設(shè)置30秒過期但業(yè)務(wù)執(zhí)行了40秒鎖已經(jīng)失效另一個線程進來了等于鎖形同虛設(shè)。手寫方案是搞一個后臺守護線程定期檢查鎖是否還在自己手里如果還在就執(zhí)行PEXPIRE續(xù)期。但自己寫這個邏輯容易出錯所以生產(chǎn)上更建議直接用Redisson。Redisson的看門狗Watch Dog機制會自動處理續(xù)期默認鎖超時時間30秒加鎖成功后后臺線程每10秒檢查一次如果鎖還在就自動續(xù)期到30秒。業(yè)務(wù)執(zhí)行完釋放鎖看門狗線程也隨之取消。源碼層面主要看RedissonLock的renewExpiration和unlockAsync面試能把這個機制講清楚基本上就能回應為什么引入Redisson。5.2 Redisson鎖的實現(xiàn)與Redlock爭議第28題Redisson是怎么實現(xiàn)分布式鎖的Redlock在多節(jié)點場景下真的可靠嗎Redisson的鎖實現(xiàn)基于RedissonLock底層還是用Lua腳本保證原子性。獲取鎖的腳本會執(zhí)行hset和pexpire而且它支持可重入同一個線程可以重復獲取同一把鎖內(nèi)部會維護一個計數(shù)器。可重入在Java里是非常重要的特性因為一個帶鎖的方法里可能又調(diào)用了另一個帶鎖的方法。Redlock是Redis官方提出的多節(jié)點分布式鎖算法向5個獨立的Redis master依次加鎖只有超過半數(shù)節(jié)點比如3個加鎖成功并且加鎖總耗時小于鎖有效時間才算加鎖成功。Redlock的爭議一直很大尤其是分布式系統(tǒng)專家Martin Kleppmann撰文批評過它的安全性問題它依賴時鐘假設(shè)在GC停頓、進程暫停場景下會產(chǎn)生兩個客戶端同時持有鎖的情況。antirezRedis作者也專門反駁過雙方至今沒有完全達成一致。面到這個級別面試官其實不是在考標準答案而是看你能不能理解分布式鎖在可用性和一致性之間的權(quán)衡。我的總結(jié)是單機或主從場景下基于Redisson的官方實現(xiàn)完全夠用多節(jié)點Redlock一般用于對鎖安全性極度敏感的場景但工程上引入Redlock的復雜度很高大部分業(yè)務(wù)是不需要的。5.3 分布式鎖在秒殺與冪等場景中的應用第29題如何用Redis做秒殺場景的庫存扣減怎樣保證不超賣秒殺最核心的問題是高并發(fā)下庫存只能減到0不能為負。用Java的synchronized或JVM鎖解決不了分布式場景的問題得用Redis的原子操作。最推薦的方式是直接用Lua腳本把庫存判斷和扣減合在一起執(zhí)行因為Redis執(zhí)行Lua腳本是原子性的不存在并發(fā)間隙。-- KEYS[1] 是庫存key例如 stock:1001 local stock tonumber(redis.call(get, KEYS[1])) if not stock or stock 0 then return -1 end redis.call(decr, KEYS[1]) return 1Java側(cè)調(diào)用String script local stock tonumber(redis.call(get, KEYS[1])) if not stock or stock 0 then return -1 end redis.call(decr, KEYS[1]) return 1; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result stringRedisTemplate.execute(redisScript, Arrays.asList(stock: skuId));當result 1時表示扣減成功接下來再異步落庫生成訂單。如果DB操作失敗再用補償腳本回滾庫存。這里有一個高頻追問既然Redis已經(jīng)扣減成功了為什么還要DB庫存答案是Redis只是一個前置校驗和預扣最終的訂單和庫存數(shù)據(jù)必須落到數(shù)據(jù)庫作為事實依據(jù)Redis扣減失敗可以直接攔截但不能替代數(shù)據(jù)庫。真正的秒殺系統(tǒng)還會加隊列削峰、限流、搶購標記等設(shè)計這是另外一個很大的話題了。第30題如何用Redis做接口冪等重復請求怎么攔截接口冪等的經(jīng)典實現(xiàn)是令牌Redis的SETNX。用戶提交訂單時服務(wù)端先為這個請求生成一個唯一的冪等ID比如UUID或分布式ID客戶端提交請求時帶著它。服務(wù)端處理前執(zhí)行Boolean firstRequest stringRedisTemplate.opsForValue() .setIfAbsent(idempotent: idempotentKey, 1, 5, TimeUnit.MINUTES); if (!firstRequest) { // 之前已經(jīng)處理過直接返回重復提交提示 return 請勿重復提交; }SETNX成功說明這個請求是第一次來后續(xù)同樣的冪等ID會直接命中已存在key從而被攔截。這種方案在防止用戶重復點擊、接口重放時非常有效實現(xiàn)成本極低不需要額外的數(shù)據(jù)庫表。需要提醒的是冪等ID的過期時間要結(jié)合業(yè)務(wù)最長處理時間來設(shè)置過期太短會出現(xiàn)第一次請求還沒處理完第二次請求就穿進來了的情況。6. 面試追問與避坑技巧怎么把答案講得不像背的6.1 Redis為什么單線程還能這么快這個問題經(jīng)常脫離30道題單獨被追問我建議你準備一個完整的回答鏈路。Redis的核心處理模型是單線程事件循環(huán)網(wǎng)絡(luò)IO模塊基于多路復用技術(shù)Linux上是epollmacOS上是kqueue能在一個線程里監(jiān)聽成千上萬個socket連接做到有事件才處理沒有事件就阻塞等待。單線程帶來的最大優(yōu)勢是避免了多線程上下文切換和鎖競爭同時執(zhí)行命令本身就是原子性的。需要補充的是Redis 6.0之后引入了多線程IO主要用于處理網(wǎng)絡(luò)讀寫但核心命令執(zhí)行仍然是單線程的。面試官如果追問多線程IO解決了什么問題你要能答出解決的是大流量下網(wǎng)絡(luò)帶寬和內(nèi)核socket讀寫對CPU的消耗而不是把命令執(zhí)行并行化。6.2 排除問題時的加分技巧日志、INFO和可視化客戶端面試聊項目時如果能順帶提一嘴排查Redis問題的具體工具鏈會顯得很務(wù)實。我常用的是這幾個手段INFO命令看內(nèi)存、命中率、客戶端的連接數(shù)。重點是INFO memory里的used_memory和mem_fragmentation_ratio內(nèi)存碎片率碎片率大于1.5需要考慮重啟或調(diào)整jemallocSLOWLOG查看慢命令。執(zhí)行SLOWLOG GET 10如果發(fā)現(xiàn)大量KEYS *、HGETALL這種大key操作系統(tǒng)性能必然受影響MONITOR實時監(jiān)控所有命令用來定位突發(fā)key訪問可以但生產(chǎn)環(huán)境千萬不要長時間開啟它會讓吞吐量斷崖式下跌可視化客戶端Redis Desktop Manager和Another Redis Desktop Manager都很常用我自己的偏好是后者界面更簡潔支持連接池和JSON格式化選客戶端唯一的標準就是支持SSH隧道方便查看key的TTL和序列化類型還有一個容易出現(xiàn)的問題Java項目里日志打出來的命令和實際Redis收到的命令不一致。常見原因是Spring Data Redis的RedisTemplate自帶一些額外操作比如在opsForValue().set()的value是對象時沒有配置序列化器就默認走JDK序列化。日志里看的是調(diào)用代碼Redis看的是序列化后的字節(jié)流所以排查時要先確認序列化器配置。6.3 關(guān)于Redis復習規(guī)劃的一點個人體會整理完這30道題之后我自己的一個強烈感受是Redis面試題早就不是靠背能過關(guān)的了。現(xiàn)在面試官更愿意從一個點切入比如你聊分布式鎖他會一路追問到Lua腳本、原子性、續(xù)期、時鐘、網(wǎng)絡(luò)分區(qū)幾十個問題順著就出來了。所以建議大家在復習時不要按題號一個接一個背而是按應用場景來串線緩存一致性場景下面掛哪些題高可用場景下面掛哪些題分布式鎖場景下面掛哪些題這樣面試時思路才不會斷層。最后再分享一個面試時的實操心得遇到不會的問題千萬別直接說不知道試著從自己的經(jīng)驗出發(fā)推導。比如沒接觸過Redlock你可以說我知道它的基本思路是向多節(jié)點加鎖但沒在線上驗證過所以不好評價它的可靠性。這種回答比你硬編一個答案要真誠得多面試官通常也愿意引導你繼續(xù)往下聊。Redis的內(nèi)容深不見底把自己的知識體系梳理成一條線比收藏100道題有用得多。