實踐：緩存一致性、分布式鎖與主從復制避坑)
Redis 幾乎是后端面試的必考科目緩存一致性、分布式鎖、持久化、主從復制、內存淘汰網(wǎng)上成套的八股文背下來二十分鐘能把面試官答得頻頻點頭。但我?guī)н^的新人里面試分數(shù)最高的那個把 Redis 接進項目第一周就出了一次線上事故用戶改完昵稱刷新頁面又變回舊的過了十幾秒才恢復。排查下來代碼里寫的正是八股文標準答案——先更新數(shù)據(jù)庫再刪除緩存。問題不在結論而在于他把結論當成了萬能公式完全沒有考慮主從延遲、并發(fā)讀寫和刪除失敗的場景。這篇東西不打算再給你抄一遍面試題答案。我更想做的是把那些被壓縮成一句話的標準答案重新展開還原它們成立的前提條件再補上真正落到生產(chǎn)環(huán)境時會遇到的邊界情況。內容覆蓋數(shù)據(jù)類型選擇、緩存一致性方案、分布式鎖的實現(xiàn)演進、RDB/AOF 與主從復制細節(jié)、大 key 熱 key 治理以及安裝部署和監(jiān)控這些動手環(huán)節(jié)。不管你是正在準備面試還是已經(jīng)接手了一個跑著 Redis 的項目都能從里面找到能直接用的判斷依據(jù)。1. 背得滾瓜爛熟的答案為什么一上生產(chǎn)就變形1.1 八股答案的通用毛病結論正確前提被吃掉了八股文最大的問題是它把結論和前提一起壓成了一句話而背誦的人往往只記住了后半截。比如Redis 是單線程的所以快這句話在 Redis 6.0 之前基本成立但真正的快來自內存操作、IO 多路復用和高效的數(shù)據(jù)結構而不是單線程這個屬性本身Redis 6.0 之后網(wǎng)絡 IO 已經(jīng)多線程化了命令執(zhí)行仍然是單線程。如果你在面試里只答單線程所以快遇到追問就答不上來如果在生產(chǎn)里按單線程所以不會并發(fā)問題去做設計那更危險——單線程指的是命令執(zhí)行不是你的業(yè)務邏輯。再舉一個例子Redis 支持事務。八股文里背的是 MULTI、EXEC、DISCARD、WATCH 四個命令。但真實的語義是Redis 事務不支持回滾某條命令執(zhí)行失敗其余命令照樣執(zhí)行它只是把命令打包一次性、按順序執(zhí)行中間不會被其他客戶端插隊。很多人第一次用事務是因為想實現(xiàn)檢查余額再扣減這類邏輯結果發(fā)現(xiàn)并發(fā)下依然超賣。原因很簡單事務的原子性是執(zhí)行原子不是檢查與執(zhí)行之間的隔離。這類理解偏差就是八股答案最常見的失真方式。我自己的經(jīng)驗是每背一條 Redis 結論就強迫自己問三個問題這條結論依賴什么前提前提被破壞時會發(fā)生什么我在代碼里怎么檢測前提是否被破壞這三個問題問下來八股就變成了工程判斷。1.2 我遇到的第一次翻車更新數(shù)據(jù)庫和更新緩存的順序回到開頭那次事故。當時的代碼邏輯是標準的 Cache Aside寫請求先更新 MySQL再DEL對應的緩存 key讀請求先查緩存未命中再查 MySQL 并回填。單機壓測完全沒問題線上卻出現(xiàn)了舊值復活。原因藏在主從復制里。我們的 MySQL 是一主兩從寫走主庫讀走從庫。寫請求更新主庫成功后立刻刪緩存緊接著一個讀請求進來緩存未命中去從庫讀——而從庫的復制還沒追上來讀到的仍然是舊值然后這個舊值被回填進了緩存。之后所有讀請求都命中這個舊值直到下一次寫入把它刪掉。整個過程不超過 100 毫秒但影響持續(xù)了十幾秒。這個坑八股文里通常不會提因為八股文默認數(shù)據(jù)庫讀寫都在同一個節(jié)點。一旦引入主從刪除緩存和讀庫回填之間的窗口就被放大了。解決辦法也不復雜要么讀寫相關的請求強制走主庫犧牲一點擴展性要么給緩存設置一個較短的兜底 TTL讓臟數(shù)據(jù)自己過期要么引入 binlog 訂閱做緩存失效比如 Canal 這類方案。我最后選的是回填時加短 TTL 關鍵業(yè)務讀寫走主庫的組合改動小風險可控。1.3 一份自查清單把八股答案翻譯成生產(chǎn)約束踩過幾次坑之后我整理了一份對照表每次評審涉及 Redis 的代碼都會過一遍。它不復雜但能擋住大部分低級事故。八股說法生產(chǎn)里必須補上的前提常見的兜底手段先更新 DB 再刪緩存讀寫是否走同一節(jié)點、刪除是否可能失敗短 TTL、binlog 訂閱、重試刪除Redis 是單線程的指的是命令執(zhí)行業(yè)務邏輯仍并發(fā)用 Lua 或SET NX保證操作原子分布式鎖用SETNX必須原子設置過期時間改用SET key val NX PX msAOF 更安全取決于appendfsync的取值一般用everysec權衡性能緩存能提升性能前提是命中率足夠高監(jiān)控命中率低于閾值就排查 key 設計主從能提高可用性存在復制延遲且不是自動故障轉移主從 哨兵或直接上集群注意表格里的兜底手段沒有一個是萬能的它們的共同點是降低故障持續(xù)時間而不是杜絕故障。做緩存設計時先接受一定會有不一致窗口這個事實再考慮窗口有多長、能不能被業(yè)務容忍。2. 五種基礎類型背后的真實選擇邏輯2.1 先想清楚數(shù)據(jù)長什么樣再決定用哪種類型八股文講數(shù)據(jù)類型通常是一句String 存字符串Hash 存對象List 存列表Set 存集合ZSet 存有序集合。背是背下來了用的時候還是全用 String把對象序列化成 JSON 塞進去。這樣也能跑但會白白浪費 Redis 的一個核心優(yōu)勢部分讀寫。舉個具體場景。用戶信息有 id、昵稱、頭像、積分、等級等十幾個字段如果整體序列化成 JSON 存在 String 里要改一個昵稱就得把整個 JSON 讀出來、反序列化、改字段、再序列化寫回去。這段時間里如果另一個請求改了積分就會互相覆蓋。換成 Hash 之后HSET user:1001 nickname 新昵稱只動一個字段互不干擾而且內存占用通常比 JSON 更小小 Hash 會使用緊湊編碼。再比如排行榜。用 List 也能實現(xiàn)但每次查詢排名都要遍歷ZSet 天生帶 score 和排名ZADD更新、ZREVRANGE取 Top N、ZREVRANK查排名都是 O(log N)。再比如統(tǒng)計某篇文章的獨立訪客這種去重需求Set 能做但用戶量大了內存會爆HyperLogLog 更合適——誤差 0.81%內存固定 12KB 左右。我的判斷順序是這樣的先看數(shù)據(jù)是不是整體讀寫String、字段級讀寫Hash、有順序且需要兩端操作List / Stream、需要去重Set、需要按分數(shù)排序或范圍查詢ZSet。定下類型之后再考慮底層編碼和內存。2.2 底層編碼的切換閾值決定了你的內存賬單同樣是 ZSet元素少的時候用的是 ziplistRedis 7 里改叫 listpack元素多或者單個元素超過閾值就轉成 skiplist。這兩者的內存差距可能有三到五倍。八股文一般只會說小數(shù)據(jù)量用壓縮列表大數(shù)據(jù)量用跳表但不會告訴你閾值在哪、怎么調。相關配置項在 redis.conf 里是這樣的# ZSet 使用 listpack 編碼的條件Redis 7.x 稱謂 zset-max-listpack-entries 128 zset-max-listpack-value 64 # Hash hash-max-listpack-entries 128 hash-max-listpack-value 64 # List list-max-listpack-size 128 # Set元素全是整數(shù)且數(shù)量不超過閾值時用 intset set-max-intset-entries 512這些值不是越大越好。調大閾值小對象的內存占用會下降但單次操作時因為要整體重新分配內存延遲會上升。我做過一次實測把hash-max-listpack-entries從 128 調到 512某業(yè)務的內存下降了約 18%但 P99 寫延遲從 0.4ms 漲到了 0.9ms。對延遲不敏感、內存緊張的場景值得調對延遲敏感的場景就別動。提示轉換是單向的一旦從緊湊編碼轉成跳表或哈希表即使后來元素減少也不會自動轉回去除非刪除并重建 key。所以如果某個 key 會周期性膨脹考慮給它加上定時重建的邏輯。2.3 被八股文漏掉的那幾個類型Bitmap、HyperLogLog、GEO、Stream基礎五類型之外Redis 還提供了幾個特殊結構它們在特定場景下能把復雜度和內存都降一個量級。Bitmap 本質是 String但可以用位操作。簽到場景特別典型一個用戶一年 365 天用 Bitmap 只需要 46 字節(jié)SETBIT sign:1001 20240315 1打卡BITCOUNT統(tǒng)計總天數(shù)BITOP做多用戶聚合。如果用 Set 存日期字符串一個用戶一年就要幾十 KB。HyperLogLog 用來做基數(shù)統(tǒng)計PFADD添加、PFCOUNT估算。它的特點是內存固定、有誤差、不支持刪除單個元素。適合UV 統(tǒng)計搜索結果去重計數(shù)這類不要求精確的場景。要注意的是PFCOUNT在多 key 合并時會比較慢因為它要把多個 HLL 結構合并計算。GEO 是建立在 ZSet 之上的地理位置結構GEOADD存經(jīng)緯度GEOSEARCH按半徑或矩形查詢。做附近的店鋪這類功能不用自己算球面距離了。Stream 是 5.0 引入的消息隊列結構有消費者組、消息 ID、ACK 機制。它比 List 實現(xiàn)的簡易隊列更完整但也不是專業(yè) MQ 的替代品——沒有復雜的重試策略、死信隊列需要自己實現(xiàn)。這幾個結構八股文里出現(xiàn)頻率不高但面試里一旦問到你還知道哪些數(shù)據(jù)結構能講清楚它們的適用邊界比背定義有用得多。3. 緩存一致性三種方案的真實差異3.1 三種更新順序的失效概率到底差在哪關于緩存和數(shù)據(jù)庫的一致性網(wǎng)上流傳的方案主要有三種先更新 DB 再刪緩存、先刪緩存再更新 DB、先更新 DB 再更新緩存。八股文的結論一般是用第一種但很少解釋為什么。先看先更新緩存在更新 DB。這個方案的問題最明顯兩個并發(fā)寫請求A 先更新緩存為值 2B 后更新緩存為值 3但數(shù)據(jù)庫層面 B 可能先落庫、A 后落庫最終數(shù)據(jù)庫是 2、緩存是 3長期不一致。而且如果緩存更新成功、數(shù)據(jù)庫更新失敗臟數(shù)據(jù)就留在緩存里了。再看先刪緩存再更新 DB。這個方案在并發(fā)下有個經(jīng)典漏洞請求 A 刪除緩存然后去更新數(shù)據(jù)庫在 A 更新完成之前請求 B 進來讀緩存未命中讀到數(shù)據(jù)庫里的舊值回填緩存之后 A 才更新完數(shù)據(jù)庫。結果緩存里是舊值數(shù)據(jù)庫里是新值。要堵住這個漏洞需要在 A 更新完之后再刪一次緩存也就是延遲雙刪。最后是先更新 DB 再刪緩存。這個方案的失效窗口更小但依然存在就是我前面遇到的主從延遲問題刪除緩存之后、主從同步完成之前的讀請求會把舊值回填。理論上要出現(xiàn)這個情況需要讀請求恰好在這個窗口內到達概率不高但現(xiàn)實中確實會發(fā)生。方案主要風險失效窗口是否需要額外機制先更新 DB 再更新緩存并發(fā)寫覆蓋、更新緩存的成本高大不建議采用先刪緩存再更新 DB讀請求回填舊值大需要延遲雙刪先更新 DB 再刪緩存主從延遲導致回填舊值小短 TTL 或 binlog 訂閱3.2 延遲雙刪的延遲時間怎么算不是拍腦袋很多人寫延遲雙刪延遲時間直接寫 500 毫秒或者 1 秒問他為什么答網(wǎng)上都這么寫。這個值其實是可以算的。延遲時間要覆蓋的是從第一次刪緩存到數(shù)據(jù)庫更新完成并被讀到新值這段時間主要包括三部分主從復制的延遲、業(yè)務更新數(shù)據(jù)庫本身的耗時、以及可能的網(wǎng)絡抖動。前兩項可以監(jiān)控MySQL 的Seconds_Behind_Master或者SHOW SLAVE STATUS里的延遲加上業(yè)務 SQL 的 P99 耗時。假設主從延遲 P99 是 30ms更新 SQL 的 P99 是 20ms那么一次延遲刪除至少要覆蓋 50ms取兩倍余量就是 100ms。如果主從延遲經(jīng)常抖到幾百毫秒那延遲雙刪本身就不適合因為你要延遲很久才能刪第二次而且第二次刪除還可能失敗。我的做法是分兩檔主從延遲穩(wěn)定的業(yè)務用 200ms 左右的延遲刪除配合 5 到 10 分鐘的緩存 TTL 兜底主從延遲不穩(wěn)定的業(yè)務干脆把讀請求強制路由到主庫用一點性能換一致性。另外第二次刪除一定要放在異步線程或者延時隊列里做不能阻塞主流程并且刪除失敗要能重試。3.3 穿透、擊穿、雪崩三個病的藥方不能混用這三個詞長得像但成因完全不同方案也不能互換。緩存穿透是查詢一個數(shù)據(jù)庫里也不存在的 key每次請求都穿過緩存打到數(shù)據(jù)庫。典型來源是惡意刷接口或者業(yè)務上用了自增 ID 之外的隨機標識。方案有兩個一是把空結果也緩存起來設置較短的 TTL比如 60 秒二是用布隆過濾器提前攔截把所有可能存在的 key 預先放進去查詢前先判斷。注意布隆過濾器有誤判率判斷存在時可能出錯判斷不存在時一定準確。所以它的正確用法是說沒有就一定沒有說有不一定有。另外它不支持刪除元素如果要支持刪除得換成計數(shù)布隆過濾器或者定期重建。緩存擊穿是某個熱點 key 突然過期高并發(fā)請求同時打到數(shù)據(jù)庫。方案有兩個互斥鎖只讓一個請求去查庫回填其他請求短暫等待或返回舊值邏輯過期key 本身不設 TTL而是把過期時間寫在 value 里命中后判斷是否過期過期則異步更新當前請求先返回舊值。緩存雪崩是大批 key 在同一時刻過期或者 Redis 實例整體不可用。前者通過給 TTL 加隨機擾動解決比如基礎 30 分鐘加上 0 到 5 分鐘的隨機值后者要靠多級緩存、集群部署、限流熔斷來解決本質上是可用性問題不是緩存設計問題。4. 分布式鎖從 SETNX 到 Redlock 的實際演進4.1 從 SETNX 到 SET NX PX原子性這一步省不得分布式鎖的經(jīng)典八股寫法是SETNX lock:order:1001 1 EXPIRE lock:order:1001 30這兩條命令分開執(zhí)行中間如果服務重啟或者網(wǎng)絡斷開EXPIRE沒執(zhí)行成功鎖就永遠不過期后續(xù)所有請求全部阻塞。這個坑很多資料都會提正確寫法是把兩條合并成一條原子命令SET lock:order:1001 requestId NX PX 30000這里有幾個細節(jié)值得展開。第一value 必須是唯一標識比如 UUID 或者機器標識 線程 ID因為解鎖的時候要校驗這把鎖是不是自己加的。第二用PX而不是EX毫秒粒度更適合控制鎖的過期時間。第三NX保證只有 key 不存在時才設置成功。4.2 鎖續(xù)期、看門狗以及業(yè)務沒執(zhí)行完鎖先過期設置了 30 秒過期如果業(yè)務執(zhí)行了 40 秒鎖會在第 30 秒自動釋放此時其他線程就能拿到鎖進入臨界區(qū)兩個線程同時操作共享資源鎖形同虛設。這個問題有兩種應對方式。第一種是給業(yè)務加超時控制保證執(zhí)行時間遠小于鎖的過期時間。這種做法簡單但前提是業(yè)務耗時可控涉及外部調用、批量處理時很難保證。第二種是鎖續(xù)期。啟動一個后臺線程在鎖快過期時比如剩余三分之一時間檢查業(yè)務是否還在執(zhí)行如果是就重新設置過期時間。Redisson 的看門狗機制就是這個思路默認鎖過期時間 30 秒每隔 10 秒續(xù)期一次。用起來方便但要注意如果應用進程被 kill續(xù)期線程也跟著消失鎖最多再存活 30 秒這是可以接受的但如果發(fā)生了長時間的 GC 停頓續(xù)期線程可能來不及執(zhí)行鎖提前過期這就是所謂的鎖失效窗口。4.3 主從切換與 Redlock 的爭議落到實踐是什么樣單節(jié)點 Redis 加鎖有個致命問題如果主節(jié)點在鎖還沒同步到從節(jié)點時就宕機了故障轉移后從節(jié)點升為主節(jié)點鎖信息丟失第二個客戶端就能拿到同一把鎖。圍繞這個問題Redis 作者提出了 Redlock 算法向多個獨立節(jié)點加鎖超過半數(shù)成功才算拿到鎖。但 Redlock 也受到過質疑核心論點是它依賴各節(jié)點的時間假設在時鐘漂移、進程停頓的情況下仍然可能失效而且它解決的是鎖的互斥性解決不了持鎖者對共享資源的操作是否安全。落到工程實踐我的選擇順序是這樣的場景推薦方案理由同一進程內的并發(fā)控制本地鎖無需網(wǎng)絡開銷性能最好單實例、容忍極低概率失效單節(jié)點 Redis 鎖 唯一 value Lua 解鎖簡單可靠滿足絕大多數(shù)業(yè)務對一致性要求極高數(shù)據(jù)庫唯一索引 / 樂觀鎖版本號依賴數(shù)據(jù)庫事務不依賴緩存可用性跨機房、強一致基于共識算法的協(xié)調服務復雜度高但語義明確我自己的項目里訂單創(chuàng)建這類不能重復的操作最終用的是數(shù)據(jù)庫唯一索引兜底 Redis 鎖做快速失敗。Redis 鎖擋掉 99% 的重復請求剩下的漏網(wǎng)之魚由唯一索引攔截觸發(fā)異常后返回請勿重復提交。這樣即使 Redis 出問題業(yè)務也不會出錯只是壓力會打到數(shù)據(jù)庫。4.4 Lua 校驗解鎖為什么不能直接 DEL解鎖最容易被忽略的一點是不能直接DEL。因為如果 A 的業(yè)務超時了鎖自動過期B 拿到了鎖這時 A 執(zhí)行完業(yè)務來解鎖直接DEL就把 B 的鎖刪了。所以必須校驗 value 是不是自己的而校驗 刪除這兩步必須是原子的只能用 Lua-- KEYS[1]: 鎖的 key -- ARGV[1]: 當前請求的唯一標識 if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end在 Java 里通過RedisTemplate.execute(RedisScript, keys, args)執(zhí)行。很多人用if (get(key).equals(id)) del(key)這種寫法在并發(fā)下依然會出問題因為GET和DEL之間鎖可能剛好過期并被別人搶走。提示Redis 集群模式下執(zhí)行 Lua 腳本所有 key 必須落在同一個槽位。如果鎖的 key 是按業(yè)務 ID 拼的一般沒問題但如果腳本里同時操作多個 key需要用 hash tag比如{order:1001}:lock強制它們同槽。5. RDB 與 AOF分工、代價和主從復制鏈路5.1 RDB 與 AOF 不是二選一而是分工八股文的對比表通常是RDB 快、文件小、可能丟數(shù)據(jù)AOF 安全、文件大、恢復慢。結論生產(chǎn)環(huán)境建議同時開啟。這句話沒錯但沒解釋為什么同時開啟更好。RDB 是某個時間點的數(shù)據(jù)快照適合做備份和全量恢復也適合主從復制的首次同步。AOF 記錄的是寫命令能保證更高的數(shù)據(jù)安全性但它會隨著時間不斷增長需要重寫來壓縮。Redis 4.0 之后引入了混合持久化AOF 重寫時會把當前數(shù)據(jù)以 RDB 格式寫到 AOF 文件開頭后續(xù)增量命令以 AOF 格式追加。這樣恢復時先加載 RDB 部分再重放增量命令速度比純 AOF 快很多。關于appendfsync這個參數(shù)三種取值的安全性和性能差異很明顯取值行為最多丟多少數(shù)據(jù)性能影響always每條命令都 fsync幾乎不丟明顯下降everysec每秒 fsync 一次約 1 秒影響很小no交給操作系統(tǒng)決定可能幾十秒幾乎無影響絕大多數(shù)業(yè)務用everysec就夠了。只有對數(shù)據(jù)安全性要求極高的場景才考慮always而且要先用壓測確認性能能扛住。5.2 fork 與寫時復制內存為什么在 bgsave 時突然翻倍執(zhí)行BGSAVE時Redis 會 fork 一個子進程來寫文件主進程繼續(xù)處理請求。很多人以為 fork 之后內存會翻倍其實不會立刻翻倍因為 fork 用的是寫時復制Copy-On-Write父子進程共享同一份物理內存只有當某一方修改了某個內存頁才會復制那一頁。問題在于寫入量。如果 fork 之后主進程的寫入非常頻繁被修改的頁越來越多操作系統(tǒng)復制的內存就越來越多極端情況下內存占用會接近翻倍。這就是為什么在寫入高峰期做BGSAVE容易觸發(fā) OOM。我踩過一次一個 20GB 的實例設置了每 10 分鐘觸發(fā)的自動快照某天流量翻倍內存直接沖到了 38GB觸發(fā)了容器內存上限被殺。后來把自動快照的頻率調低改成業(yè)務低峰期執(zhí)行并且把實例內存從 32GB 提到了 64GB留出足夠的 COW 余量。經(jīng)驗是實際內存峰值大約等于當前數(shù)據(jù)量乘以 1.5 到 2規(guī)劃容量時別只看數(shù)據(jù)本身。注意vm.overcommit_memory這個內核參數(shù)需要設置為 1否則內核可能拒絕 fork 請求導致后臺保存失敗。5.3 主從復制的 runid、offset 與全量、增量同步主從復制的完整流程分三步。第一步從節(jié)點連接主節(jié)點發(fā)送PSYNC因為是首次同步主節(jié)點回復FULLRESYNC runid offset然后執(zhí)行BGSAVE生成 RDB 文件發(fā)給從節(jié)點從節(jié)點清空自身數(shù)據(jù)后加載。這個過程中主節(jié)點的新寫入會被記錄在復制緩沖區(qū)里RDB 發(fā)送完之后再把這部分命令補發(fā)給從節(jié)點。第二步全量同步完成后進入命令傳播階段主節(jié)點每執(zhí)行一個寫命令就發(fā)給從節(jié)點同時維護一個 Offset 計數(shù)器主從雙方通過比較 Offset 判斷是否一致。第三步如果網(wǎng)絡中斷后重連從節(jié)點發(fā)送PSYNC runid offset主節(jié)點檢查這個 runid 是不是自己的以及 offset 是否還在復制積壓緩沖區(qū)repl-backlog范圍內。都滿足就只發(fā)缺失的那部分命令也就是增量同步否則退化成全量同步。這里有個關鍵參數(shù)repl-backlog-size默認 1MB在高寫入量下很容易不夠。一旦斷開時間稍長offset 超出了緩沖區(qū)范圍就會觸發(fā)全量同步——主節(jié)點 fork、生成 RDB、傳輸、從節(jié)點加載整個過程對主節(jié)點壓力很大。估算方式是平均寫入速率 × 期望能容忍的斷連時長比如寫入 5MB/s 還想容忍 60 秒斷連那至少要 300MB。5.4 主從搭建的實操順序與幾個必改參數(shù)以一臺主、一臺從為例從節(jié)點的配置里加上replicaof 192.168.1.10 6379 masterauth 主節(jié)點密碼 replica-read-only yes repl-backlog-size 256mb repl-backlog-ttl 3600 repl-timeout 60啟動后檢查狀態(tài)redis-cli -h 192.168.1.11 info replication # 關注 role:slave, master_link_status:up, master_repl_offset, slave_repl_offset幾個容易忽略的點。第一masterauth一定不能漏否則連接會卡在master_link_status:down日志里會看到NOAUTH Authentication required。第二從節(jié)點默認read-only yes別為了圖方便改成 no否則可能出現(xiàn)雙向寫入導致數(shù)據(jù)混亂。第三主節(jié)點也要設置repl-backlog-size這個參數(shù)配置在主節(jié)點上不是從節(jié)點。第四防火墻和安全組要放開 6379 端口的互訪但這個端口絕對不能暴露到公網(wǎng)。如果要做自動故障轉移單靠主從不夠需要引入哨兵或者直接使用集群模式。哨兵負責監(jiān)控、選主和通知客戶端客戶端通過哨兵獲取當前主節(jié)點地址。6. 大 key、熱 key 與內存治理6.1 過期刪除與內存淘汰兩組策略不是一回事這兩個概念經(jīng)常被混在一起。過期刪除處理的是設置了 TTL 的 key 到期后怎么刪內存淘汰處理的是內存達到 maxmemory 后刪哪些 key。前者是定時任務后者是內存不足時的被動行為。過期刪除用的是惰性刪除 定期刪除的組合訪問 key 時檢查是否過期過期就刪同時每秒若干次隨機抽查一部分設置了 TTL 的 key刪掉其中過期的。這樣設計是為了避免遍歷所有 key 造成卡頓代價是有些過期 key 會短暫滯留。內存淘汰策略由maxmemory-policy決定策略淘汰范圍適用場景noeviction不淘汰寫入報錯當數(shù)據(jù)庫用不能丟數(shù)據(jù)allkeys-lru所有 key按最近最少使用純緩存場景推薦allkeys-lfu所有 key按訪問頻率熱點數(shù)據(jù)明顯、有長期低頻 keyvolatile-lru只淘汰設置了 TTL 的 key緩存和持久數(shù)據(jù)混用volatile-ttl優(yōu)先淘汰剩余時間短的對過期時間敏感的場景allkeys-random隨機淘汰訪問分布均勻時可用LRU 在 Redis 里是近似實現(xiàn)通過maxmemory-samples控制采樣數(shù)量默認 5。調大采樣數(shù)會讓淘汰更接近真實 LRU但會消耗更多 CPU。我們線上一般設成 10效果和開銷比較平衡。注意把maxmemory-policy設成noeviction而maxmemory又設得偏小時寫入會直接返回OOM command not allowed錯誤業(yè)務側會報異常。要么給足內存要么選淘汰策略。6.2 大 key 怎么找、怎么拆大 key 的危害是多方面的單次操作耗時長可能阻塞其他請求刪除時如果用的是DEL會同步釋放內存造成卡頓主從復制和持久化時也會放大影響。找大 key 最直接的方式是redis-cli --bigkeys redis-cli --memkeys redis-cli -h host -p 6379 memory usage key--bigkeys是按類型采樣統(tǒng)計的不會掃全庫對線上影響可控。MEMORY USAGE可以精確查看單個 key 的內存占用默認采樣 5 個元素估算。拆分思路要看數(shù)據(jù)結構。如果是 Hash可以按字段前綴拆成多個小 Hash如果是 List可以按時間或 ID 區(qū)間分段如果是 String先確認是不是存了序列化的大對象能拆成 Hash 就拆。刪除大 key 一定要用UNLINK而不是DELUNLINK是異步釋放不會阻塞主線程。另外如果業(yè)務里會批量掃描比如KEYS *或者HGETALL大 Hash一定要換成SCAN系列命令分批遍歷。KEYS在生產(chǎn)環(huán)境應該被完全禁用有的團隊甚至會在配置里改掉命令名來防止誤用。6.3 熱 key 與本地緩存熱 key 指的是訪問量極度集中的 key比如秒殺活動里的庫存 key、首頁配置 key。單個 key 的 QPS 太高會集中打到一個 Redis 節(jié)點上集群模式下成為瓶頸。發(fā)現(xiàn)熱 key 可以用redis-cli --hotkeys但前提是淘汰策略為 LFU否則統(tǒng)計不到。也可以自己做客戶端埋點統(tǒng)計每個 key 的訪問次數(shù)。應對方式有幾層。第一層是本地緩存用 Caffeine 這類工具在應用進程內緩存熱點數(shù)據(jù)設置很短的 TTL比如 1 到 3 秒大部分請求根本不會到 Redis。這一層的代價是數(shù)據(jù)一致性會有秒級延遲要評估業(yè)務能否接受。第二層是 key 分散把hot:key復制成hot:key:1到hot:key:10讀的時候隨機選一個寫的時候全部更新把壓力分散到多個節(jié)點。第三層是限流降級當 Redis 響應變慢時直接走本地兜底數(shù)據(jù)保證核心鏈路可用。我們做秒殺時用的是第一層 第三層庫存預熱到本地緩存Redis 只承擔扣減和最終校驗Redis 出現(xiàn)抖動時直接拒絕新請求而不是排隊等待。7. 安裝部署與監(jiān)控幾個容易踩的實操點7.1 安裝方式怎么選源碼、包管理還是容器編排在 Linux 上裝 Redis常見有三種方式。包管理器安裝apt install redis-server或yum install redis最省事但版本通常偏舊而且默認配置不一定適合生產(chǎn)。源碼編譯安裝可以指定版本和編譯參數(shù)適合需要特定版本的場景缺點是升級麻煩。容器方式適合已經(jīng)有編排平臺的環(huán)境配置和版本都能用鏡像固化下來。Windows 環(huán)境需要說明一下Redis 官方并不提供 Windows 版本官方文檔里明確建議在 Windows 上通過 WSL2 運行 Linux 版本。網(wǎng)上流傳的一些 Windows 移植版本通常停留在較老的版本功能和安全更新都跟不上只適合本地學習不要用在正式環(huán)境。如果用 Docker Compose 部署主從一個可參考的寫法是services: redis-master: image: redis:7.2 container_name: redis-master command: [redis-server, /etc/redis/redis.conf] volumes: - ./master/redis.conf:/etc/redis/redis.conf - ./master/data:/data ports: - 6379:6379 restart: always redis-replica: image: redis:7.2 container_name: redis-replica command: [redis-server, /etc/redis/redis.conf] volumes: - ./replica/redis.conf:/etc/redis/redis.conf - ./replica/data:/data depends_on: - redis-master restart: always從節(jié)點的配置文件里寫上replicaof redis-master 6379和masterauth。注意容器里用的是服務名而不是 IP因為容器重啟后 IP 會變。數(shù)據(jù)目錄一定要掛載出來否則容器重建后數(shù)據(jù)就沒了。7.2 一份生產(chǎn)可用的配置骨架配置項很多但核心的就那些。下面這份是我從幾個項目里提煉出來的骨架具體數(shù)值要按業(yè)務壓測調整bind 0.0.0.0 protected-mode yes port 6379 requirepass 強密碼 timeout 300 tcp-keepalive 300 # 持久化 save 900 1 save 300 10 appendonly yes appendfsync everysec aof-use-rdb-preamble yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 內存 maxmemory 8gb maxmemory-policy allkeys-lru maxmemory-samples 10 # 慢查詢 slowlog-log-slower-than 10000 slowlog-max-len 512 # 危險命令重命名 rename-command KEYS rename-command FLUSHALL 幾個必須強調的點bind不要寫成0.0.0.0之后又把端口暴露到公網(wǎng)這是最常見的被入侵原因requirepass一定要設而且密碼不能太弱rename-command把KEYS、FLUSHALL這類高危命令禁用掉能避免很多誤操作slowlog-log-slower-than單位是微秒10000 表示 10 毫秒超過這個耗時的命令會被記錄下來。7.3 可視化工具與監(jiān)控指標命令行夠用但排查問題時有個可視化工具會快很多。RedisInsight 是官方出品的界面清晰支持內存分析、慢查詢查看和命令行。Another Redis Desktop Manager 是社區(qū)里口碑不錯的客戶端跨平臺、啟動快、支持集群和哨兵日常用起來很順手。監(jiān)控方面最重要的幾個指標是命中率keyspace_hits / (keyspace_hits keyspace_misses)低于 80% 就要排查 key 設計或 TTL 設置內存使用率used_memory / maxmemory長期高于 80% 要警惕慢查詢數(shù)量slowlog_len持續(xù)增長說明有耗時命令連接數(shù)connected_clients突增可能是連接池泄漏或客戶端沒復用連接主從延遲master_repl_offset - slave_repl_offset被拒絕的命令rejected_connections、errorstats里的各類錯誤計數(shù)這些指標通過INFO命令就能拿到接進 Prometheus 之后用 Grafana 做看板。我個人習慣是在看板上加一條內存增長曲線如果曲線斜率在業(yè)務低峰期也不下降基本可以確定有 key 沒設 TTL 或者大 key 在堆積。最后分享一個我在排查線上問題時常用的小技巧當懷疑是某個 key 導致的問題先用redis-cli --bigkeys和--hotkeys快速定位再用MONITOR短時間抓一下命令流一定要短MONITOR本身開銷很大長時間開啟會拖慢實例最后用SLOWLOG GET 20看最近最慢的二十條命令。這三步走下來大部分 Redis 相關的線上問題都能定位到具體原因。如果后續(xù)要擴展我會優(yōu)先把 binlog 訂閱做緩存失效這條鏈路補上它比延遲雙刪更長治久安只是需要額外的中間件和運維成本。 Redis生產(chǎn)實踐：緩存一致性、分布式鎖與主從復制避坑
Redis 幾乎是后端面試的必考科目緩存一致性、分布式鎖、持久化、主從復制、內存淘汰網(wǎng)上成套的八股文背下來二十分鐘能把面試官答得頻頻點頭。但我?guī)н^的新人里面試分數(shù)最高的那個把 Redis 接進項目第一周就出了一次線上事故用戶改完昵稱刷新頁面又變回舊的過了十幾秒才恢復。排查下來代碼里寫的正是八股文標準答案——先更新數(shù)據(jù)庫再刪除緩存。問題不在結論而在于他把結論當成了萬能公式完全沒有考慮主從延遲、并發(fā)讀寫和刪除失敗的場景。這篇東西不打算再給你抄一遍面試題答案。我更想做的是把那些被壓縮成一句話的標準答案重新展開還原它們成立的前提條件再補上真正落到生產(chǎn)環(huán)境時會遇到的邊界情況。內容覆蓋數(shù)據(jù)類型選擇、緩存一致性方案、分布式鎖的實現(xiàn)演進、RDB/AOF 與主從復制細節(jié)、大 key 熱 key 治理以及安裝部署和監(jiān)控這些動手環(huán)節(jié)。不管你是正在準備面試還是已經(jīng)接手了一個跑著 Redis 的項目都能從里面找到能直接用的判斷依據(jù)。1. 背得滾瓜爛熟的答案為什么一上生產(chǎn)就變形1.1 八股答案的通用毛病結論正確前提被吃掉了八股文最大的問題是它把結論和前提一起壓成了一句話而背誦的人往往只記住了后半截。比如Redis 是單線程的所以快這句話在 Redis 6.0 之前基本成立但真正的快來自內存操作、IO 多路復用和高效的數(shù)據(jù)結構而不是單線程這個屬性本身Redis 6.0 之后網(wǎng)絡 IO 已經(jīng)多線程化了命令執(zhí)行仍然是單線程。如果你在面試里只答單線程所以快遇到追問就答不上來如果在生產(chǎn)里按單線程所以不會并發(fā)問題去做設計那更危險——單線程指的是命令執(zhí)行不是你的業(yè)務邏輯。再舉一個例子Redis 支持事務。八股文里背的是 MULTI、EXEC、DISCARD、WATCH 四個命令。但真實的語義是Redis 事務不支持回滾某條命令執(zhí)行失敗其余命令照樣執(zhí)行它只是把命令打包一次性、按順序執(zhí)行中間不會被其他客戶端插隊。很多人第一次用事務是因為想實現(xiàn)檢查余額再扣減這類邏輯結果發(fā)現(xiàn)并發(fā)下依然超賣。原因很簡單事務的原子性是執(zhí)行原子不是檢查與執(zhí)行之間的隔離。這類理解偏差就是八股答案最常見的失真方式。我自己的經(jīng)驗是每背一條 Redis 結論就強迫自己問三個問題這條結論依賴什么前提前提被破壞時會發(fā)生什么我在代碼里怎么檢測前提是否被破壞這三個問題問下來八股就變成了工程判斷。1.2 我遇到的第一次翻車更新數(shù)據(jù)庫和更新緩存的順序回到開頭那次事故。當時的代碼邏輯是標準的 Cache Aside寫請求先更新 MySQL再DEL對應的緩存 key讀請求先查緩存未命中再查 MySQL 并回填。單機壓測完全沒問題線上卻出現(xiàn)了舊值復活。原因藏在主從復制里。我們的 MySQL 是一主兩從寫走主庫讀走從庫。寫請求更新主庫成功后立刻刪緩存緊接著一個讀請求進來緩存未命中去從庫讀——而從庫的復制還沒追上來讀到的仍然是舊值然后這個舊值被回填進了緩存。之后所有讀請求都命中這個舊值直到下一次寫入把它刪掉。整個過程不超過 100 毫秒但影響持續(xù)了十幾秒。這個坑八股文里通常不會提因為八股文默認數(shù)據(jù)庫讀寫都在同一個節(jié)點。一旦引入主從刪除緩存和讀庫回填之間的窗口就被放大了。解決辦法也不復雜要么讀寫相關的請求強制走主庫犧牲一點擴展性要么給緩存設置一個較短的兜底 TTL讓臟數(shù)據(jù)自己過期要么引入 binlog 訂閱做緩存失效比如 Canal 這類方案。我最后選的是回填時加短 TTL 關鍵業(yè)務讀寫走主庫的組合改動小風險可控。1.3 一份自查清單把八股答案翻譯成生產(chǎn)約束踩過幾次坑之后我整理了一份對照表每次評審涉及 Redis 的代碼都會過一遍。它不復雜但能擋住大部分低級事故。八股說法生產(chǎn)里必須補上的前提常見的兜底手段先更新 DB 再刪緩存讀寫是否走同一節(jié)點、刪除是否可能失敗短 TTL、binlog 訂閱、重試刪除Redis 是單線程的指的是命令執(zhí)行業(yè)務邏輯仍并發(fā)用 Lua 或SET NX保證操作原子分布式鎖用SETNX必須原子設置過期時間改用SET key val NX PX msAOF 更安全取決于appendfsync的取值一般用everysec權衡性能緩存能提升性能前提是命中率足夠高監(jiān)控命中率低于閾值就排查 key 設計主從能提高可用性存在復制延遲且不是自動故障轉移主從 哨兵或直接上集群注意表格里的兜底手段沒有一個是萬能的它們的共同點是降低故障持續(xù)時間而不是杜絕故障。做緩存設計時先接受一定會有不一致窗口這個事實再考慮窗口有多長、能不能被業(yè)務容忍。2. 五種基礎類型背后的真實選擇邏輯2.1 先想清楚數(shù)據(jù)長什么樣再決定用哪種類型八股文講數(shù)據(jù)類型通常是一句String 存字符串Hash 存對象List 存列表Set 存集合ZSet 存有序集合。背是背下來了用的時候還是全用 String把對象序列化成 JSON 塞進去。這樣也能跑但會白白浪費 Redis 的一個核心優(yōu)勢部分讀寫。舉個具體場景。用戶信息有 id、昵稱、頭像、積分、等級等十幾個字段如果整體序列化成 JSON 存在 String 里要改一個昵稱就得把整個 JSON 讀出來、反序列化、改字段、再序列化寫回去。這段時間里如果另一個請求改了積分就會互相覆蓋。換成 Hash 之后HSET user:1001 nickname 新昵稱只動一個字段互不干擾而且內存占用通常比 JSON 更小小 Hash 會使用緊湊編碼。再比如排行榜。用 List 也能實現(xiàn)但每次查詢排名都要遍歷ZSet 天生帶 score 和排名ZADD更新、ZREVRANGE取 Top N、ZREVRANK查排名都是 O(log N)。再比如統(tǒng)計某篇文章的獨立訪客這種去重需求Set 能做但用戶量大了內存會爆HyperLogLog 更合適——誤差 0.81%內存固定 12KB 左右。我的判斷順序是這樣的先看數(shù)據(jù)是不是整體讀寫String、字段級讀寫Hash、有順序且需要兩端操作List / Stream、需要去重Set、需要按分數(shù)排序或范圍查詢ZSet。定下類型之后再考慮底層編碼和內存。2.2 底層編碼的切換閾值決定了你的內存賬單同樣是 ZSet元素少的時候用的是 ziplistRedis 7 里改叫 listpack元素多或者單個元素超過閾值就轉成 skiplist。這兩者的內存差距可能有三到五倍。八股文一般只會說小數(shù)據(jù)量用壓縮列表大數(shù)據(jù)量用跳表但不會告訴你閾值在哪、怎么調。相關配置項在 redis.conf 里是這樣的# ZSet 使用 listpack 編碼的條件Redis 7.x 稱謂 zset-max-listpack-entries 128 zset-max-listpack-value 64 # Hash hash-max-listpack-entries 128 hash-max-listpack-value 64 # List list-max-listpack-size 128 # Set元素全是整數(shù)且數(shù)量不超過閾值時用 intset set-max-intset-entries 512這些值不是越大越好。調大閾值小對象的內存占用會下降但單次操作時因為要整體重新分配內存延遲會上升。我做過一次實測把hash-max-listpack-entries從 128 調到 512某業(yè)務的內存下降了約 18%但 P99 寫延遲從 0.4ms 漲到了 0.9ms。對延遲不敏感、內存緊張的場景值得調對延遲敏感的場景就別動。提示轉換是單向的一旦從緊湊編碼轉成跳表或哈希表即使后來元素減少也不會自動轉回去除非刪除并重建 key。所以如果某個 key 會周期性膨脹考慮給它加上定時重建的邏輯。2.3 被八股文漏掉的那幾個類型Bitmap、HyperLogLog、GEO、Stream基礎五類型之外Redis 還提供了幾個特殊結構它們在特定場景下能把復雜度和內存都降一個量級。Bitmap 本質是 String但可以用位操作。簽到場景特別典型一個用戶一年 365 天用 Bitmap 只需要 46 字節(jié)SETBIT sign:1001 20240315 1打卡BITCOUNT統(tǒng)計總天數(shù)BITOP做多用戶聚合。如果用 Set 存日期字符串一個用戶一年就要幾十 KB。HyperLogLog 用來做基數(shù)統(tǒng)計PFADD添加、PFCOUNT估算。它的特點是內存固定、有誤差、不支持刪除單個元素。適合UV 統(tǒng)計搜索結果去重計數(shù)這類不要求精確的場景。要注意的是PFCOUNT在多 key 合并時會比較慢因為它要把多個 HLL 結構合并計算。GEO 是建立在 ZSet 之上的地理位置結構GEOADD存經(jīng)緯度GEOSEARCH按半徑或矩形查詢。做附近的店鋪這類功能不用自己算球面距離了。Stream 是 5.0 引入的消息隊列結構有消費者組、消息 ID、ACK 機制。它比 List 實現(xiàn)的簡易隊列更完整但也不是專業(yè) MQ 的替代品——沒有復雜的重試策略、死信隊列需要自己實現(xiàn)。這幾個結構八股文里出現(xiàn)頻率不高但面試里一旦問到你還知道哪些數(shù)據(jù)結構能講清楚它們的適用邊界比背定義有用得多。3. 緩存一致性三種方案的真實差異3.1 三種更新順序的失效概率到底差在哪關于緩存和數(shù)據(jù)庫的一致性網(wǎng)上流傳的方案主要有三種先更新 DB 再刪緩存、先刪緩存再更新 DB、先更新 DB 再更新緩存。八股文的結論一般是用第一種但很少解釋為什么。先看先更新緩存在更新 DB。這個方案的問題最明顯兩個并發(fā)寫請求A 先更新緩存為值 2B 后更新緩存為值 3但數(shù)據(jù)庫層面 B 可能先落庫、A 后落庫最終數(shù)據(jù)庫是 2、緩存是 3長期不一致。而且如果緩存更新成功、數(shù)據(jù)庫更新失敗臟數(shù)據(jù)就留在緩存里了。再看先刪緩存再更新 DB。這個方案在并發(fā)下有個經(jīng)典漏洞請求 A 刪除緩存然后去更新數(shù)據(jù)庫在 A 更新完成之前請求 B 進來讀緩存未命中讀到數(shù)據(jù)庫里的舊值回填緩存之后 A 才更新完數(shù)據(jù)庫。結果緩存里是舊值數(shù)據(jù)庫里是新值。要堵住這個漏洞需要在 A 更新完之后再刪一次緩存也就是延遲雙刪。最后是先更新 DB 再刪緩存。這個方案的失效窗口更小但依然存在就是我前面遇到的主從延遲問題刪除緩存之后、主從同步完成之前的讀請求會把舊值回填。理論上要出現(xiàn)這個情況需要讀請求恰好在這個窗口內到達概率不高但現(xiàn)實中確實會發(fā)生。方案主要風險失效窗口是否需要額外機制先更新 DB 再更新緩存并發(fā)寫覆蓋、更新緩存的成本高大不建議采用先刪緩存再更新 DB讀請求回填舊值大需要延遲雙刪先更新 DB 再刪緩存主從延遲導致回填舊值小短 TTL 或 binlog 訂閱3.2 延遲雙刪的延遲時間怎么算不是拍腦袋很多人寫延遲雙刪延遲時間直接寫 500 毫秒或者 1 秒問他為什么答網(wǎng)上都這么寫。這個值其實是可以算的。延遲時間要覆蓋的是從第一次刪緩存到數(shù)據(jù)庫更新完成并被讀到新值這段時間主要包括三部分主從復制的延遲、業(yè)務更新數(shù)據(jù)庫本身的耗時、以及可能的網(wǎng)絡抖動。前兩項可以監(jiān)控MySQL 的Seconds_Behind_Master或者SHOW SLAVE STATUS里的延遲加上業(yè)務 SQL 的 P99 耗時。假設主從延遲 P99 是 30ms更新 SQL 的 P99 是 20ms那么一次延遲刪除至少要覆蓋 50ms取兩倍余量就是 100ms。如果主從延遲經(jīng)常抖到幾百毫秒那延遲雙刪本身就不適合因為你要延遲很久才能刪第二次而且第二次刪除還可能失敗。我的做法是分兩檔主從延遲穩(wěn)定的業(yè)務用 200ms 左右的延遲刪除配合 5 到 10 分鐘的緩存 TTL 兜底主從延遲不穩(wěn)定的業(yè)務干脆把讀請求強制路由到主庫用一點性能換一致性。另外第二次刪除一定要放在異步線程或者延時隊列里做不能阻塞主流程并且刪除失敗要能重試。3.3 穿透、擊穿、雪崩三個病的藥方不能混用這三個詞長得像但成因完全不同方案也不能互換。緩存穿透是查詢一個數(shù)據(jù)庫里也不存在的 key每次請求都穿過緩存打到數(shù)據(jù)庫。典型來源是惡意刷接口或者業(yè)務上用了自增 ID 之外的隨機標識。方案有兩個一是把空結果也緩存起來設置較短的 TTL比如 60 秒二是用布隆過濾器提前攔截把所有可能存在的 key 預先放進去查詢前先判斷。注意布隆過濾器有誤判率判斷存在時可能出錯判斷不存在時一定準確。所以它的正確用法是說沒有就一定沒有說有不一定有。另外它不支持刪除元素如果要支持刪除得換成計數(shù)布隆過濾器或者定期重建。緩存擊穿是某個熱點 key 突然過期高并發(fā)請求同時打到數(shù)據(jù)庫。方案有兩個互斥鎖只讓一個請求去查庫回填其他請求短暫等待或返回舊值邏輯過期key 本身不設 TTL而是把過期時間寫在 value 里命中后判斷是否過期過期則異步更新當前請求先返回舊值。緩存雪崩是大批 key 在同一時刻過期或者 Redis 實例整體不可用。前者通過給 TTL 加隨機擾動解決比如基礎 30 分鐘加上 0 到 5 分鐘的隨機值后者要靠多級緩存、集群部署、限流熔斷來解決本質上是可用性問題不是緩存設計問題。4. 分布式鎖從 SETNX 到 Redlock 的實際演進4.1 從 SETNX 到 SET NX PX原子性這一步省不得分布式鎖的經(jīng)典八股寫法是SETNX lock:order:1001 1 EXPIRE lock:order:1001 30這兩條命令分開執(zhí)行中間如果服務重啟或者網(wǎng)絡斷開EXPIRE沒執(zhí)行成功鎖就永遠不過期后續(xù)所有請求全部阻塞。這個坑很多資料都會提正確寫法是把兩條合并成一條原子命令SET lock:order:1001 requestId NX PX 30000這里有幾個細節(jié)值得展開。第一value 必須是唯一標識比如 UUID 或者機器標識 線程 ID因為解鎖的時候要校驗這把鎖是不是自己加的。第二用PX而不是EX毫秒粒度更適合控制鎖的過期時間。第三NX保證只有 key 不存在時才設置成功。4.2 鎖續(xù)期、看門狗以及業(yè)務沒執(zhí)行完鎖先過期設置了 30 秒過期如果業(yè)務執(zhí)行了 40 秒鎖會在第 30 秒自動釋放此時其他線程就能拿到鎖進入臨界區(qū)兩個線程同時操作共享資源鎖形同虛設。這個問題有兩種應對方式。第一種是給業(yè)務加超時控制保證執(zhí)行時間遠小于鎖的過期時間。這種做法簡單但前提是業(yè)務耗時可控涉及外部調用、批量處理時很難保證。第二種是鎖續(xù)期。啟動一個后臺線程在鎖快過期時比如剩余三分之一時間檢查業(yè)務是否還在執(zhí)行如果是就重新設置過期時間。Redisson 的看門狗機制就是這個思路默認鎖過期時間 30 秒每隔 10 秒續(xù)期一次。用起來方便但要注意如果應用進程被 kill續(xù)期線程也跟著消失鎖最多再存活 30 秒這是可以接受的但如果發(fā)生了長時間的 GC 停頓續(xù)期線程可能來不及執(zhí)行鎖提前過期這就是所謂的鎖失效窗口。4.3 主從切換與 Redlock 的爭議落到實踐是什么樣單節(jié)點 Redis 加鎖有個致命問題如果主節(jié)點在鎖還沒同步到從節(jié)點時就宕機了故障轉移后從節(jié)點升為主節(jié)點鎖信息丟失第二個客戶端就能拿到同一把鎖。圍繞這個問題Redis 作者提出了 Redlock 算法向多個獨立節(jié)點加鎖超過半數(shù)成功才算拿到鎖。但 Redlock 也受到過質疑核心論點是它依賴各節(jié)點的時間假設在時鐘漂移、進程停頓的情況下仍然可能失效而且它解決的是鎖的互斥性解決不了持鎖者對共享資源的操作是否安全。落到工程實踐我的選擇順序是這樣的場景推薦方案理由同一進程內的并發(fā)控制本地鎖無需網(wǎng)絡開銷性能最好單實例、容忍極低概率失效單節(jié)點 Redis 鎖 唯一 value Lua 解鎖簡單可靠滿足絕大多數(shù)業(yè)務對一致性要求極高數(shù)據(jù)庫唯一索引 / 樂觀鎖版本號依賴數(shù)據(jù)庫事務不依賴緩存可用性跨機房、強一致基于共識算法的協(xié)調服務復雜度高但語義明確我自己的項目里訂單創(chuàng)建這類不能重復的操作最終用的是數(shù)據(jù)庫唯一索引兜底 Redis 鎖做快速失敗。Redis 鎖擋掉 99% 的重復請求剩下的漏網(wǎng)之魚由唯一索引攔截觸發(fā)異常后返回請勿重復提交。這樣即使 Redis 出問題業(yè)務也不會出錯只是壓力會打到數(shù)據(jù)庫。4.4 Lua 校驗解鎖為什么不能直接 DEL解鎖最容易被忽略的一點是不能直接DEL。因為如果 A 的業(yè)務超時了鎖自動過期B 拿到了鎖這時 A 執(zhí)行完業(yè)務來解鎖直接DEL就把 B 的鎖刪了。所以必須校驗 value 是不是自己的而校驗 刪除這兩步必須是原子的只能用 Lua-- KEYS[1]: 鎖的 key -- ARGV[1]: 當前請求的唯一標識 if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end在 Java 里通過RedisTemplate.execute(RedisScript, keys, args)執(zhí)行。很多人用if (get(key).equals(id)) del(key)這種寫法在并發(fā)下依然會出問題因為GET和DEL之間鎖可能剛好過期并被別人搶走。提示Redis 集群模式下執(zhí)行 Lua 腳本所有 key 必須落在同一個槽位。如果鎖的 key 是按業(yè)務 ID 拼的一般沒問題但如果腳本里同時操作多個 key需要用 hash tag比如{order:1001}:lock強制它們同槽。5. RDB 與 AOF分工、代價和主從復制鏈路5.1 RDB 與 AOF 不是二選一而是分工八股文的對比表通常是RDB 快、文件小、可能丟數(shù)據(jù)AOF 安全、文件大、恢復慢。結論生產(chǎn)環(huán)境建議同時開啟。這句話沒錯但沒解釋為什么同時開啟更好。RDB 是某個時間點的數(shù)據(jù)快照適合做備份和全量恢復也適合主從復制的首次同步。AOF 記錄的是寫命令能保證更高的數(shù)據(jù)安全性但它會隨著時間不斷增長需要重寫來壓縮。Redis 4.0 之后引入了混合持久化AOF 重寫時會把當前數(shù)據(jù)以 RDB 格式寫到 AOF 文件開頭后續(xù)增量命令以 AOF 格式追加。這樣恢復時先加載 RDB 部分再重放增量命令速度比純 AOF 快很多。關于appendfsync這個參數(shù)三種取值的安全性和性能差異很明顯取值行為最多丟多少數(shù)據(jù)性能影響always每條命令都 fsync幾乎不丟明顯下降everysec每秒 fsync 一次約 1 秒影響很小no交給操作系統(tǒng)決定可能幾十秒幾乎無影響絕大多數(shù)業(yè)務用everysec就夠了。只有對數(shù)據(jù)安全性要求極高的場景才考慮always而且要先用壓測確認性能能扛住。5.2 fork 與寫時復制內存為什么在 bgsave 時突然翻倍執(zhí)行BGSAVE時Redis 會 fork 一個子進程來寫文件主進程繼續(xù)處理請求。很多人以為 fork 之后內存會翻倍其實不會立刻翻倍因為 fork 用的是寫時復制Copy-On-Write父子進程共享同一份物理內存只有當某一方修改了某個內存頁才會復制那一頁。問題在于寫入量。如果 fork 之后主進程的寫入非常頻繁被修改的頁越來越多操作系統(tǒng)復制的內存就越來越多極端情況下內存占用會接近翻倍。這就是為什么在寫入高峰期做BGSAVE容易觸發(fā) OOM。我踩過一次一個 20GB 的實例設置了每 10 分鐘觸發(fā)的自動快照某天流量翻倍內存直接沖到了 38GB觸發(fā)了容器內存上限被殺。后來把自動快照的頻率調低改成業(yè)務低峰期執(zhí)行并且把實例內存從 32GB 提到了 64GB留出足夠的 COW 余量。經(jīng)驗是實際內存峰值大約等于當前數(shù)據(jù)量乘以 1.5 到 2規(guī)劃容量時別只看數(shù)據(jù)本身。注意vm.overcommit_memory這個內核參數(shù)需要設置為 1否則內核可能拒絕 fork 請求導致后臺保存失敗。5.3 主從復制的 runid、offset 與全量、增量同步主從復制的完整流程分三步。第一步從節(jié)點連接主節(jié)點發(fā)送PSYNC因為是首次同步主節(jié)點回復FULLRESYNC runid offset然后執(zhí)行BGSAVE生成 RDB 文件發(fā)給從節(jié)點從節(jié)點清空自身數(shù)據(jù)后加載。這個過程中主節(jié)點的新寫入會被記錄在復制緩沖區(qū)里RDB 發(fā)送完之后再把這部分命令補發(fā)給從節(jié)點。第二步全量同步完成后進入命令傳播階段主節(jié)點每執(zhí)行一個寫命令就發(fā)給從節(jié)點同時維護一個 Offset 計數(shù)器主從雙方通過比較 Offset 判斷是否一致。第三步如果網(wǎng)絡中斷后重連從節(jié)點發(fā)送PSYNC runid offset主節(jié)點檢查這個 runid 是不是自己的以及 offset 是否還在復制積壓緩沖區(qū)repl-backlog范圍內。都滿足就只發(fā)缺失的那部分命令也就是增量同步否則退化成全量同步。這里有個關鍵參數(shù)repl-backlog-size默認 1MB在高寫入量下很容易不夠。一旦斷開時間稍長offset 超出了緩沖區(qū)范圍就會觸發(fā)全量同步——主節(jié)點 fork、生成 RDB、傳輸、從節(jié)點加載整個過程對主節(jié)點壓力很大。估算方式是平均寫入速率 × 期望能容忍的斷連時長比如寫入 5MB/s 還想容忍 60 秒斷連那至少要 300MB。5.4 主從搭建的實操順序與幾個必改參數(shù)以一臺主、一臺從為例從節(jié)點的配置里加上replicaof 192.168.1.10 6379 masterauth 主節(jié)點密碼 replica-read-only yes repl-backlog-size 256mb repl-backlog-ttl 3600 repl-timeout 60啟動后檢查狀態(tài)redis-cli -h 192.168.1.11 info replication # 關注 role:slave, master_link_status:up, master_repl_offset, slave_repl_offset幾個容易忽略的點。第一masterauth一定不能漏否則連接會卡在master_link_status:down日志里會看到NOAUTH Authentication required。第二從節(jié)點默認read-only yes別為了圖方便改成 no否則可能出現(xiàn)雙向寫入導致數(shù)據(jù)混亂。第三主節(jié)點也要設置repl-backlog-size這個參數(shù)配置在主節(jié)點上不是從節(jié)點。第四防火墻和安全組要放開 6379 端口的互訪但這個端口絕對不能暴露到公網(wǎng)。如果要做自動故障轉移單靠主從不夠需要引入哨兵或者直接使用集群模式。哨兵負責監(jiān)控、選主和通知客戶端客戶端通過哨兵獲取當前主節(jié)點地址。6. 大 key、熱 key 與內存治理6.1 過期刪除與內存淘汰兩組策略不是一回事這兩個概念經(jīng)常被混在一起。過期刪除處理的是設置了 TTL 的 key 到期后怎么刪內存淘汰處理的是內存達到 maxmemory 后刪哪些 key。前者是定時任務后者是內存不足時的被動行為。過期刪除用的是惰性刪除 定期刪除的組合訪問 key 時檢查是否過期過期就刪同時每秒若干次隨機抽查一部分設置了 TTL 的 key刪掉其中過期的。這樣設計是為了避免遍歷所有 key 造成卡頓代價是有些過期 key 會短暫滯留。內存淘汰策略由maxmemory-policy決定策略淘汰范圍適用場景noeviction不淘汰寫入報錯當數(shù)據(jù)庫用不能丟數(shù)據(jù)allkeys-lru所有 key按最近最少使用純緩存場景推薦allkeys-lfu所有 key按訪問頻率熱點數(shù)據(jù)明顯、有長期低頻 keyvolatile-lru只淘汰設置了 TTL 的 key緩存和持久數(shù)據(jù)混用volatile-ttl優(yōu)先淘汰剩余時間短的對過期時間敏感的場景allkeys-random隨機淘汰訪問分布均勻時可用LRU 在 Redis 里是近似實現(xiàn)通過maxmemory-samples控制采樣數(shù)量默認 5。調大采樣數(shù)會讓淘汰更接近真實 LRU但會消耗更多 CPU。我們線上一般設成 10效果和開銷比較平衡。注意把maxmemory-policy設成noeviction而maxmemory又設得偏小時寫入會直接返回OOM command not allowed錯誤業(yè)務側會報異常。要么給足內存要么選淘汰策略。6.2 大 key 怎么找、怎么拆大 key 的危害是多方面的單次操作耗時長可能阻塞其他請求刪除時如果用的是DEL會同步釋放內存造成卡頓主從復制和持久化時也會放大影響。找大 key 最直接的方式是redis-cli --bigkeys redis-cli --memkeys redis-cli -h host -p 6379 memory usage key--bigkeys是按類型采樣統(tǒng)計的不會掃全庫對線上影響可控。MEMORY USAGE可以精確查看單個 key 的內存占用默認采樣 5 個元素估算。拆分思路要看數(shù)據(jù)結構。如果是 Hash可以按字段前綴拆成多個小 Hash如果是 List可以按時間或 ID 區(qū)間分段如果是 String先確認是不是存了序列化的大對象能拆成 Hash 就拆。刪除大 key 一定要用UNLINK而不是DELUNLINK是異步釋放不會阻塞主線程。另外如果業(yè)務里會批量掃描比如KEYS *或者HGETALL大 Hash一定要換成SCAN系列命令分批遍歷。KEYS在生產(chǎn)環(huán)境應該被完全禁用有的團隊甚至會在配置里改掉命令名來防止誤用。6.3 熱 key 與本地緩存熱 key 指的是訪問量極度集中的 key比如秒殺活動里的庫存 key、首頁配置 key。單個 key 的 QPS 太高會集中打到一個 Redis 節(jié)點上集群模式下成為瓶頸。發(fā)現(xiàn)熱 key 可以用redis-cli --hotkeys但前提是淘汰策略為 LFU否則統(tǒng)計不到。也可以自己做客戶端埋點統(tǒng)計每個 key 的訪問次數(shù)。應對方式有幾層。第一層是本地緩存用 Caffeine 這類工具在應用進程內緩存熱點數(shù)據(jù)設置很短的 TTL比如 1 到 3 秒大部分請求根本不會到 Redis。這一層的代價是數(shù)據(jù)一致性會有秒級延遲要評估業(yè)務能否接受。第二層是 key 分散把hot:key復制成hot:key:1到hot:key:10讀的時候隨機選一個寫的時候全部更新把壓力分散到多個節(jié)點。第三層是限流降級當 Redis 響應變慢時直接走本地兜底數(shù)據(jù)保證核心鏈路可用。我們做秒殺時用的是第一層 第三層庫存預熱到本地緩存Redis 只承擔扣減和最終校驗Redis 出現(xiàn)抖動時直接拒絕新請求而不是排隊等待。7. 安裝部署與監(jiān)控幾個容易踩的實操點7.1 安裝方式怎么選源碼、包管理還是容器編排在 Linux 上裝 Redis常見有三種方式。包管理器安裝apt install redis-server或yum install redis最省事但版本通常偏舊而且默認配置不一定適合生產(chǎn)。源碼編譯安裝可以指定版本和編譯參數(shù)適合需要特定版本的場景缺點是升級麻煩。容器方式適合已經(jīng)有編排平臺的環(huán)境配置和版本都能用鏡像固化下來。Windows 環(huán)境需要說明一下Redis 官方并不提供 Windows 版本官方文檔里明確建議在 Windows 上通過 WSL2 運行 Linux 版本。網(wǎng)上流傳的一些 Windows 移植版本通常停留在較老的版本功能和安全更新都跟不上只適合本地學習不要用在正式環(huán)境。如果用 Docker Compose 部署主從一個可參考的寫法是services: redis-master: image: redis:7.2 container_name: redis-master command: [redis-server, /etc/redis/redis.conf] volumes: - ./master/redis.conf:/etc/redis/redis.conf - ./master/data:/data ports: - 6379:6379 restart: always redis-replica: image: redis:7.2 container_name: redis-replica command: [redis-server, /etc/redis/redis.conf] volumes: - ./replica/redis.conf:/etc/redis/redis.conf - ./replica/data:/data depends_on: - redis-master restart: always從節(jié)點的配置文件里寫上replicaof redis-master 6379和masterauth。注意容器里用的是服務名而不是 IP因為容器重啟后 IP 會變。數(shù)據(jù)目錄一定要掛載出來否則容器重建后數(shù)據(jù)就沒了。7.2 一份生產(chǎn)可用的配置骨架配置項很多但核心的就那些。下面這份是我從幾個項目里提煉出來的骨架具體數(shù)值要按業(yè)務壓測調整bind 0.0.0.0 protected-mode yes port 6379 requirepass 強密碼 timeout 300 tcp-keepalive 300 # 持久化 save 900 1 save 300 10 appendonly yes appendfsync everysec aof-use-rdb-preamble yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 內存 maxmemory 8gb maxmemory-policy allkeys-lru maxmemory-samples 10 # 慢查詢 slowlog-log-slower-than 10000 slowlog-max-len 512 # 危險命令重命名 rename-command KEYS rename-command FLUSHALL 幾個必須強調的點bind不要寫成0.0.0.0之后又把端口暴露到公網(wǎng)這是最常見的被入侵原因requirepass一定要設而且密碼不能太弱rename-command把KEYS、FLUSHALL這類高危命令禁用掉能避免很多誤操作slowlog-log-slower-than單位是微秒10000 表示 10 毫秒超過這個耗時的命令會被記錄下來。7.3 可視化工具與監(jiān)控指標命令行夠用但排查問題時有個可視化工具會快很多。RedisInsight 是官方出品的界面清晰支持內存分析、慢查詢查看和命令行。Another Redis Desktop Manager 是社區(qū)里口碑不錯的客戶端跨平臺、啟動快、支持集群和哨兵日常用起來很順手。監(jiān)控方面最重要的幾個指標是命中率keyspace_hits / (keyspace_hits keyspace_misses)低于 80% 就要排查 key 設計或 TTL 設置內存使用率used_memory / maxmemory長期高于 80% 要警惕慢查詢數(shù)量slowlog_len持續(xù)增長說明有耗時命令連接數(shù)connected_clients突增可能是連接池泄漏或客戶端沒復用連接主從延遲master_repl_offset - slave_repl_offset被拒絕的命令rejected_connections、errorstats里的各類錯誤計數(shù)這些指標通過INFO命令就能拿到接進 Prometheus 之后用 Grafana 做看板。我個人習慣是在看板上加一條內存增長曲線如果曲線斜率在業(yè)務低峰期也不下降基本可以確定有 key 沒設 TTL 或者大 key 在堆積。最后分享一個我在排查線上問題時常用的小技巧當懷疑是某個 key 導致的問題先用redis-cli --bigkeys和--hotkeys快速定位再用MONITOR短時間抓一下命令流一定要短MONITOR本身開銷很大長時間開啟會拖慢實例最后用SLOWLOG GET 20看最近最慢的二十條命令。這三步走下來大部分 Redis 相關的線上問題都能定位到具體原因。如果后續(xù)要擴展我會優(yōu)先把 binlog 訂閱做緩存失效這條鏈路補上它比延遲雙刪更長治久安只是需要額外的中間件和運維成本。