第一次在項(xiàng)目里被 Redis 救場(chǎng)是好幾年前一個(gè)商品詳情頁(yè)的接口。那時(shí)候數(shù)據(jù)庫(kù)的 QPS 已經(jīng)被壓到貼著地板走頁(yè)面每次刷新都要連表查十幾張表高峰期接口響應(yīng)時(shí)間直接干到三秒以上。后來把詳情頁(yè)那份聚合數(shù)據(jù)整成一份 JSON 塞進(jìn) Redis超時(shí)率當(dāng)天就掉下來了。從那以后我對(duì)這個(gè)中間件的態(tài)度就變了——它不是加個(gè)緩存這么簡(jiǎn)單而是一套需要認(rèn)真理解內(nèi)存模型、數(shù)據(jù)結(jié)構(gòu)、持久化策略和淘汰機(jī)制的基礎(chǔ)設(shè)施。這篇內(nèi)容面向的是準(zhǔn)備把 Redis 用進(jìn)生產(chǎn)環(huán)境、或者已經(jīng)用了但心里沒底的同學(xué)從它到底解決什么問題、單線程為什么還能扛住高并發(fā)到五種基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)的落地選型、安裝配置、緩存三大異常的應(yīng)對(duì)再到線上排查的實(shí)操手法我會(huì)按我自己踩過的順序講一遍?？赐昴阒辽倌茏龅絻杉轮朗裁磾?shù)據(jù)該往 Redis 里放、什么數(shù)據(jù)不該放以及在它出問題的時(shí)候知道從哪幾個(gè)命令開始查。1. 先搞清楚 Redis 到底在項(xiàng)目里補(bǔ)的是哪塊短板很多人對(duì) Redis 的第一印象是內(nèi)存數(shù)據(jù)庫(kù)讀得快這個(gè)描述沒錯(cuò)但太淺。真把它放進(jìn)架構(gòu)里你得先明白它替代的是哪一段鏈路否則用著用著就會(huì)出現(xiàn)緩存加了一堆接口還是慢或者數(shù)據(jù)對(duì)不上這類問題。1.1 從一次接口超時(shí)反推它解決的問題回到開頭那個(gè)詳情頁(yè)的例子。當(dāng)時(shí)那條鏈路的耗時(shí)分布大致是這樣的數(shù)據(jù)庫(kù)連接池等待、多表 JOIN、結(jié)果集序列化、網(wǎng)絡(luò)傳輸。真正壓死駱駝的是 JOIN 和連接池爭(zhēng)搶因?yàn)樵斍轫?yè)的讀請(qǐng)求量是寫請(qǐng)求的幾十倍每次讀都要重新拼裝一遍數(shù)據(jù)數(shù)據(jù)庫(kù)的 buffer pool 命中率再高也頂不住這種重復(fù)勞動(dòng)。Redis 在這里的價(jià)值不是快而是把一次復(fù)雜的計(jì)算或查詢結(jié)果變成一次 O(1) 的內(nèi)存讀取。這兩者的差別在于數(shù)據(jù)庫(kù)快是因?yàn)樗饕蛿?shù)據(jù)局部性Redis 快是因?yàn)樗鼔焊蛔鲇?jì)算直接返回你之前存好的字節(jié)。理解這一點(diǎn)很關(guān)鍵因?yàn)樗鼪Q定了你該緩存什么——緩存的是重復(fù)計(jì)算的結(jié)果而不是所有查詢。我在實(shí)際項(xiàng)目里見過反例有人把用戶表整表緩存成 Hash每次查單個(gè)用戶還要 HGET 一次看著是走了 Redis實(shí)際上把關(guān)系型數(shù)據(jù)庫(kù)的查詢能力全丟了后來要做按手機(jī)號(hào)模糊搜索、按注冊(cè)時(shí)間排序全得在應(yīng)用層手寫最后又灰溜溜地加回?cái)?shù)據(jù)庫(kù)查詢。所以第一件事要先劃清邊界。1.2 Redis 與關(guān)系型數(shù)據(jù)庫(kù)的職責(zé)分工我的劃分原則很簡(jiǎn)單數(shù)據(jù)庫(kù)負(fù)責(zé)真相Redis 負(fù)責(zé)效率。具體到落地下面這幾類數(shù)據(jù)適合放進(jìn)去讀多寫少、且允許短暫不一致的熱點(diǎn)數(shù)據(jù)比如商品詳情、配置項(xiàng)、字典表。有明確過期語(yǔ)義的數(shù)據(jù)比如登錄態(tài)、驗(yàn)證碼、短信頻控計(jì)數(shù)。需要原子性計(jì)數(shù)的場(chǎng)景比如庫(kù)存扣減的預(yù)扣、接口限流、文章閱讀數(shù)。需要跨進(jìn)程共享的臨時(shí)狀態(tài)比如分布式鎖、任務(wù)隊(duì)列、秒殺排隊(duì)。反過來下面這些我基本不往 Redis 里塞需要復(fù)雜條件查詢、聚合統(tǒng)計(jì)的業(yè)務(wù)主數(shù)據(jù)。單條體積超過幾十 KB 的大對(duì)象尤其是列表頁(yè)會(huì)批量取的。需要強(qiáng)事務(wù)保證的跨實(shí)體寫操作。生命周期極短且無復(fù)用價(jià)值的臨時(shí)數(shù)據(jù)。這里有個(gè)判斷口訣如果這份數(shù)據(jù)丟了業(yè)務(wù)能不能靠數(shù)據(jù)庫(kù)重建能重建的才適合放進(jìn)緩存層不能重建的說明它是真相的一部分應(yīng)該留在數(shù)據(jù)庫(kù)。還有一點(diǎn)容易被忽略Redis 的內(nèi)存這個(gè)屬性意味著成本和容量都是硬約束。一臺(tái) 16G 內(nèi)存的機(jī)器實(shí)際能給 Redis 用的可能只有 10G 出頭剩下要留給操作系統(tǒng)、fork 時(shí)的寫時(shí)復(fù)制、以及內(nèi)存碎片。所以在設(shè)計(jì)階段就該估算數(shù)據(jù)量而不是等 OOM 了再反過來刪 key。1.3 什么規(guī)模的項(xiàng)目才真正需要它經(jīng)常有人問小項(xiàng)目要不要上 Redis。我的看法是看兩個(gè)指標(biāo)單表數(shù)據(jù)量是否已經(jīng)讓查詢變慢以及是否出現(xiàn)了跨請(qǐng)求共享狀態(tài)的需求。如果只是幾千條數(shù)據(jù)的后臺(tái)管理系統(tǒng)查詢走索引完全夠用引入 Redis 只是多了一個(gè)需要運(yùn)維的組件。但只要出現(xiàn)下面任意一種情況它就值得上了同一份數(shù)據(jù)一秒內(nèi)被讀幾十次以上需要給接口做頻率限制需要給多個(gè)服務(wù)實(shí)例共享會(huì)話需要做排行榜、延時(shí)任務(wù)這類數(shù)據(jù)庫(kù)不擅長(zhǎng)的結(jié)構(gòu)。這些都是硬需求跟項(xiàng)目規(guī)模無關(guān)。2. 單線程還能這么快底層到底做了什么Redis 是單線程的這句話流傳太廣以至于很多人第一次聽到會(huì)懷疑它扛不住并發(fā)。實(shí)際情況是Redis 的命令執(zhí)行確實(shí)是單線程的但它的快不是因?yàn)榫€程少而是因?yàn)闆]有線程切換開銷 純內(nèi)存操作 精心設(shè)計(jì)的數(shù)據(jù)結(jié)構(gòu) IO 多路復(fù)用這幾件事疊加在一起。2.1 單線程模型的真實(shí)含義與版本演進(jìn)早期版本里Redis 從接收連接、讀取命令、執(zhí)行命令到寫回結(jié)果全部在一個(gè)主線程里完成靠的是 epollLinux、kqueuemacOS這類多路復(fù)用機(jī)制一個(gè)線程輪詢處理成千上萬(wàn)個(gè)連接。這帶來的好處非常直接不需要加鎖不存在競(jìng)態(tài)任何一條命令執(zhí)行期間數(shù)據(jù)狀態(tài)都是確定的。像 INCR 這種操作天然就是原子的你不用操心并發(fā)問題。但網(wǎng)絡(luò)讀寫本身是有開銷的。Redis 6.0 之后引入了 IO 多線程注意是只把 socket 的讀寫和協(xié)議解析分給多個(gè)線程命令執(zhí)行仍然在主線程串行。這個(gè)改動(dòng)對(duì)高吞吐場(chǎng)景比如大 value 的批量讀寫提升明顯因?yàn)槠款i從 CPU 計(jì)算轉(zhuǎn)移到了網(wǎng)絡(luò)拷貝上。配置上對(duì)應(yīng)的是這兩項(xiàng)# redis.conf io-threads 4 io-threads-do-reads yes提示io-threads 的設(shè)置經(jīng)驗(yàn)值是 CPU 核數(shù)的 3/4 左右且不建議超過 8 個(gè)。開太多反而會(huì)因?yàn)榫€程調(diào)度拖慢我在一臺(tái) 32 核機(jī)器上試過開到 16吞吐量相比 8 個(gè)還降了一點(diǎn)。2.2 內(nèi)存存儲(chǔ)與底層數(shù)據(jù)結(jié)構(gòu)的取舍純內(nèi)存這件事本身就是數(shù)量級(jí)的差距。一次內(nèi)存隨機(jī)訪問大概在 100 納秒量級(jí)而一次機(jī)械硬盤尋道是毫秒級(jí)SSD 也是幾十微秒級(jí)差距在四到五個(gè)數(shù)量級(jí)。但光快還不夠Redis 在數(shù)據(jù)結(jié)構(gòu)上做了很多省內(nèi)存的文章這部分決定了你的實(shí)例能裝多少數(shù)據(jù)。舉個(gè)具體例子一個(gè)普通的 String 并不是簡(jiǎn)單地 malloc 一塊內(nèi)存而是用 SDS簡(jiǎn)單動(dòng)態(tài)字符串來實(shí)現(xiàn)頭部記錄了長(zhǎng)度和剩余空間好處是獲取長(zhǎng)度是 O(1)、拼接時(shí)可以做預(yù)分配、并且二進(jìn)制安全可以存圖片、序列化對(duì)象。再比如小規(guī)模的 Hash底層不會(huì)一上來就用哈希表而是用 listpack老版本叫 ziplist這種緊湊的連續(xù)內(nèi)存結(jié)構(gòu)元素少的時(shí)候省下大量指針開銷。這些細(xì)節(jié)平時(shí)不用關(guān)心但有兩個(gè)配置項(xiàng)跟它直接相關(guān)值得記住hash-max-listpack-entries 128 hash-max-listpack-value 64 zset-max-listpack-entries 128意思是當(dāng) Hash 的字段數(shù)不超過 128、且每個(gè)字段值不超過 64 字節(jié)時(shí)用緊湊結(jié)構(gòu)存儲(chǔ)一旦超過就轉(zhuǎn)成真正的哈希表。轉(zhuǎn)過去之后內(nèi)存占用可能翻好幾倍而且這個(gè)過程是不可逆的——即使你后來把字段刪到只剩 3 個(gè)它也不會(huì)變回緊湊結(jié)構(gòu)。我在一個(gè)存用戶標(biāo)簽的 Hash 上踩過這個(gè)坑前期測(cè)試時(shí)每個(gè)用戶 20 來個(gè)標(biāo)簽內(nèi)存很漂亮上線后運(yùn)營(yíng)批量打標(biāo)某些用戶標(biāo)簽數(shù)沖到 200整個(gè)實(shí)例內(nèi)存直接漲了 40%。2.3 持久化RDB 與 AOF 的選擇邏輯內(nèi)存數(shù)據(jù)庫(kù)最怕的是斷電所以持久化機(jī)制必須搞清楚。Redis 給了兩種方式理解它們的關(guān)鍵是搞明白各自犧牲了什么。RDB是某一時(shí)刻的全量快照通過 fork 子進(jìn)程 寫時(shí)復(fù)制來完成。優(yōu)點(diǎn)是文件緊湊、恢復(fù)速度快適合做備份和災(zāi)備。缺點(diǎn)是兩次快照之間的數(shù)據(jù)會(huì)丟而且 fork 的瞬間如果數(shù)據(jù)量大會(huì)有明顯的內(nèi)存膨脹和短暫卡頓。AOF是追加寫命令日志按 fsync 策略分三檔策略行為數(shù)據(jù)安全性能影響always每條命令都刷盤最高最多丟一條最差QPS 掉一個(gè)數(shù)量級(jí)everysec每秒刷一次最多丟一秒可接受生產(chǎn)常用no交給操作系統(tǒng)可能丟較多最好不建議生產(chǎn)用AOF 的問題是文件會(huì)越來越大所以需要重寫rewrite本質(zhì)上也是 fork 子進(jìn)程根據(jù)當(dāng)前內(nèi)存狀態(tài)生成一份精簡(jiǎn)的命令集。實(shí)際生產(chǎn)里我基本都用混合持久化Redis 4.0 之后支持配置是這樣appendonly yes appendfsync everysec aof-use-rdb-preamble yes開了混合模式之后AOF 重寫時(shí)前半段用 RDB 格式存全量后半段追加增量命令。恢復(fù)時(shí)先加載 RDB 部分再重放命令兼顧了速度和完整性。這個(gè)配置我在這幾年幾個(gè)項(xiàng)目里都用恢復(fù)時(shí)間和數(shù)據(jù)安全性都比較平衡。注意如果實(shí)例內(nèi)存超過 10Gfork 時(shí)的寫時(shí)復(fù)制可能帶來額外的內(nèi)存峰值。建議預(yù)留至少 50% 的空閑內(nèi)存或者把vm.overcommit_memory設(shè)為 1避免 fork 失敗。3. 五種基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)對(duì)應(yīng)五類真實(shí)業(yè)務(wù)場(chǎng)景Redis 常被叫做數(shù)據(jù)結(jié)構(gòu)服務(wù)器這個(gè)定位很準(zhǔn)確。它的價(jià)值不在于能存 key-value而在于它把常用的幾種數(shù)據(jù)結(jié)構(gòu)做成了服務(wù)端原語(yǔ)你在應(yīng)用層不用自己實(shí)現(xiàn)加鎖和并發(fā)控制。3.1 String 與 Hash緩存對(duì)象時(shí)的兩種打法String 是最基礎(chǔ)的能存字符串、數(shù)字、二進(jìn)制。最典型的用法是緩存整個(gè)對(duì)象序列化后的 JSONSET product:1001 {id:1001,name:某商品,price:99.00} EX 3600 GET product:1001EX 3600 表示一小時(shí)后過期。這種整存整取的方式適合讀多寫少、且每次都要完整對(duì)象的場(chǎng)景比如詳情頁(yè)。Hash 則適合需要部分讀寫、或者字段會(huì)獨(dú)立變化的場(chǎng)景HSET user:2001 name A同學(xué) level 3 lastLogin 2024-05-01 HGET user:2001 level HINCRBY user:2001 level 1用 Hash 的好處是可以只更新某個(gè)字段不用把整個(gè)對(duì)象讀出來改完再寫回去減少了網(wǎng)絡(luò)傳輸和序列化開銷。缺點(diǎn)是過期時(shí)間只能加在整個(gè) key 上沒法給單個(gè)字段設(shè) TTL。選型上我的經(jīng)驗(yàn)是對(duì)象字段少、整體讀寫就 String對(duì)象字段多、經(jīng)常單獨(dú)更新某個(gè)字段就 Hash。但要注意 2.2 里提到的結(jié)構(gòu)轉(zhuǎn)換問題字段數(shù)別讓它無限增長(zhǎng)。有個(gè)容易忽略的細(xì)節(jié)String 存數(shù)字時(shí)可以直接用 INCR/DECR 做原子計(jì)數(shù)這是做限流、庫(kù)存預(yù)扣的基礎(chǔ)。像接口頻控這種場(chǎng)景我是這么寫的# 一分鐘內(nèi)同一用戶最多 60 次 INCR rate:limit:user:2001:202405011200 EXPIRE rate:limit:user:2001:202405011200 60兩次命令不是原子的嚴(yán)格場(chǎng)景需要用 Lua 腳本或者SET key 1 EX 60 NX配合 INCR 的組合來處理。3.2 List 與 Set隊(duì)列、去重與關(guān)系判斷List 是雙向鏈表底層實(shí)際是 quicklist由多個(gè)緊湊節(jié)點(diǎn)串起來支持兩端插入彈出天然適合做隊(duì)列LPUSH queue:task job-001 BRPOP queue:task 5BRPOP 是阻塞版本隊(duì)列空的時(shí)候會(huì)掛起等待超時(shí)返回 nil。用這個(gè)做簡(jiǎn)單的任務(wù)隊(duì)列是可行的但要注意它沒有 ACK 機(jī)制——消費(fèi)者取走消息后如果進(jìn)程崩了這條消息就丟了。要可靠投遞得上 Stream 類型或者專業(yè)的消息隊(duì)列。Set 是無序集合最大的價(jià)值是去重和集合運(yùn)算SADD article:1001:liked user:2001 SADD article:1001:liked user:2002 SCARD article:1001:liked SINTER user:2001:follow user:2002:followSINTER 求交集這個(gè)能力在做共同關(guān)注共同好友時(shí)特別省事一行命令解決不用把兩個(gè)列表拉到應(yīng)用層做雙層循環(huán)。但要注意大集合求交集的復(fù)雜度是 O(N*M)幾萬(wàn)規(guī)模的集合還行上百萬(wàn)就要考慮用別的方式了。3.3 ZSet排行榜與延時(shí)任務(wù)的核心有序集合是我個(gè)人認(rèn)為 Redis 最有價(jià)值的結(jié)構(gòu)。它每個(gè)元素帶一個(gè) score按 score 排序底層用跳表實(shí)現(xiàn)插入和范圍查詢都是 O(logN)。排行榜是最經(jīng)典的應(yīng)用ZINCRBY rank:20240501 1 user:2001 ZREVRANGE rank:20240501 0 9 WITHSCORES第一行給用戶加分第二行取分?jǐn)?shù)最高的前十名含分?jǐn)?shù)。ZREVRANGE 是倒序正序用 ZRANGE。另一個(gè)用法是延時(shí)任務(wù)。把任務(wù)的執(zhí)行時(shí)間戳作為 score然后用 ZRANGEBYSCORE 按時(shí)間范圍取到期任務(wù)ZADD delay:queue 1714560000 order-close:3001 ZRANGEBYSCORE delay:queue 0 1714560000 LIMIT 0 100配合定時(shí)輪詢就實(shí)現(xiàn)了一個(gè)輕量的延時(shí)隊(duì)列。我在幾個(gè)項(xiàng)目里用它做過訂單超時(shí)關(guān)閉比引入完整消息隊(duì)列輕量得多精度控制在秒級(jí)完全夠用。3.4 結(jié)構(gòu)選型速查業(yè)務(wù)需求推薦結(jié)構(gòu)關(guān)鍵命令注意事項(xiàng)對(duì)象緩存StringSET/GET體積控制在 10KB 內(nèi)局部字段更新HashHSET/HGET字段數(shù)別超 128簡(jiǎn)單隊(duì)列ListLPUSH/BRPOP無 ACK謹(jǐn)慎用于關(guān)鍵任務(wù)去重計(jì)數(shù)SetSADD/SCARD大集合注意內(nèi)存共同關(guān)系SetSINTER規(guī)模別上百萬(wàn)排行榜ZSetZINCRBY/ZREVRANGEscore 用 double注意精度延時(shí)任務(wù)ZSetZADD/ZRANGEBYSCORE需要輪詢進(jìn)程配合頻控計(jì)數(shù)StringINCR/EXPIRE建議用 Lua 保證原子4. 從零裝一套能用的 Redis理論講完落到手上。這部分我按裝、配、驗(yàn)三步走配置部分會(huì)把幾個(gè)真正影響生產(chǎn)穩(wěn)定性的項(xiàng)挑出來講。4.1 安裝方式的選擇與取舍三種常見方式包管理器安裝、源碼編譯、容器運(yùn)行。包管理器最省事apt install redis-server或者yum install redis但版本往往偏舊有些新特性用不上。源碼編譯能拿到最新穩(wěn)定版代價(jià)是要自己處理依賴wget https://download.redis.io/releases/redis-7.2.4.tar.gz tar -zxvf redis-7.2.4.tar.gz cd redis-7.2.4 make make install PREFIX/usr/local/redis容器方式適合本地開發(fā)和快速驗(yàn)證docker run -d -p 6379:6379 redis:7.2。但生產(chǎn)環(huán)境用容器要額外注意數(shù)據(jù)卷掛載和內(nèi)存限制容器內(nèi)的 maxmemory 和宿主機(jī)的 cgroup 限制不一致時(shí)容易出現(xiàn) OOM Kill 而不是正常的淘汰。提示編譯前確認(rèn) gcc 版本7.x 之后要求 gcc 5.3 以上。另外make失敗最常見的原因是 jemalloc 編譯不過可以加MALLOClibc參數(shù)繞過。4.2 生產(chǎn)環(huán)境必須改的配置項(xiàng)默認(rèn)配置是給開發(fā)用的直接上生產(chǎn)會(huì)出事。下面這幾項(xiàng)我每次部署都會(huì)過一遍# 網(wǎng)絡(luò)與安全 bind 0.0.0.0 protected-mode yes port 6379 requirepass 你的強(qiáng)密碼 # 運(yùn)行方式 daemonize yes maxclients 10000 # 內(nèi)存 maxmemory 8gb maxmemory-policy allkeys-lru # 持久化 appendonly yes appendfsync everysecmaxmemory一定要設(shè)不設(shè)的話 Redis 會(huì)一直吃內(nèi)存直到被系統(tǒng)殺掉那時(shí)候就不是淘汰幾個(gè) key 的問題了而是整個(gè)實(shí)例掛掉。maxmemory-policy的選擇取決于你的數(shù)據(jù)性質(zhì)noeviction內(nèi)存滿了直接報(bào)錯(cuò)適合數(shù)據(jù)不能丟的場(chǎng)景。allkeys-lru所有 key 里淘汰最近最少使用的純緩存場(chǎng)景首選。volatile-lru只淘汰設(shè)了過期時(shí)間的 key適合緩存和持久數(shù)據(jù)混存的實(shí)例。allkeys-lfu按訪問頻率淘汰熱點(diǎn)數(shù)據(jù)保護(hù)更好4.0 之后支持。我個(gè)人在純緩存實(shí)例上一律用allkeys-lru在混合實(shí)例上用volatile-lru并且嚴(yán)格要求持久數(shù)據(jù)不設(shè) TTL靠這個(gè)約定來保證它們不會(huì)被誤淘汰。4.3 連通性驗(yàn)證與基礎(chǔ)命令實(shí)測(cè)裝完之后別急著寫代碼先手工驗(yàn)一遍redis-cli -h 127.0.0.1 -p 6379 -a 你的密碼 127.0.0.1:6379 PING PONG 127.0.0.1:6379 INFO serverPING 返回 PONG 說明連通。INFO 里重點(diǎn)看幾個(gè)字段redis_version版本、uptime_in_days運(yùn)行天數(shù)、connected_clients當(dāng)前連接數(shù)。再跑一組讀寫驗(yàn)證127.0.0.1:6379 SET test:key hello EX 60 OK 127.0.0.1:6379 TTL test:key (integer) 59 127.0.0.1:6379 GET test:key helloTTL 返回 59 而不是 60是因?yàn)槊顖?zhí)行有極小的耗時(shí)屬于正?，F(xiàn)象。如果 TTL 返回 -1 說明沒設(shè)過期返回 -2 說明 key 不存在——這兩個(gè)返回值經(jīng)常被混淆寫監(jiān)控腳本時(shí)要注意區(qū)分。5. 緩存三大異常每個(gè)都有對(duì)應(yīng)的打法緩存用起來之后真正讓人睡不著覺的不是性能而是數(shù)據(jù)一致性和異常流量。所謂穿透、擊穿、雪崩這三個(gè)詞說的是三種不同的失效模式應(yīng)對(duì)手段也完全不同必須分清楚。5.1 三種失效模式的成因?qū)Ρ犬惓ｎ愋陀|發(fā)條件現(xiàn)象影響范圍緩存穿透查詢根本不存在的數(shù)據(jù)每次都打到數(shù)據(jù)庫(kù)可能被惡意利用緩存擊穿熱點(diǎn) key 過期瞬間大量請(qǐng)求同時(shí)打庫(kù)單個(gè)熱點(diǎn)緩存雪崩大量 key 同時(shí)過期或?qū)嵗礄C(jī)數(shù)據(jù)庫(kù)瞬間承壓全局性穿透的本質(zhì)是緩存里沒有數(shù)據(jù)庫(kù)里也沒有查詢永遠(yuǎn)落空緩存形同虛設(shè)。擊穿是緩存里本來有剛好過期了一瞬間所有請(qǐng)求涌向數(shù)據(jù)庫(kù)。雪崩則是更大范圍的集體失效。這三者的共同點(diǎn)是把數(shù)據(jù)庫(kù)當(dāng)成了兜底所以核心思路都是在緩存層就把請(qǐng)求擋住或者分流。5.2 穿透與擊穿的落地實(shí)現(xiàn)對(duì)付穿透最直接的辦法是緩存空值。查數(shù)據(jù)庫(kù)沒查到也往 Redis 里塞一個(gè)特殊標(biāo)記TTL 設(shè)短一點(diǎn)比如 60 秒def get_user(user_id): key fuser:{user_id} cached redis.get(key) if cached is not None: if cached __NULL__: return None return json.loads(cached) user db.query_user(user_id) if user is None: redis.set(key, __NULL__, ex60) return None redis.set(key, json.dumps(user), ex3600) return user這個(gè)做法的隱患是如果攻擊者用隨機(jī) ID 瘋狂請(qǐng)求會(huì)往 Redis 里塞大量空值 key所以通常要配合布隆過濾器在入口先做一層攔截。布隆過濾器判斷一定不存在是準(zhǔn)確的判斷存在有誤判率剛好適合放在緩存前面。擊穿的解法是加互斥鎖保證同一時(shí)刻只有一個(gè)請(qǐng)求去回源def get_hot_data(key): data redis.get(key) if data: return data lock_key flock:{key} if redis.set(lock_key, 1, nxTrue, ex10): try: data db.query(key) redis.set(key, data, ex300) return data finally: redis.delete(lock_key) else: time.sleep(0.05) return get_hot_data(key)注意nxTrue這個(gè)參數(shù)等價(jià)于 SETNX只有 key 不存在時(shí)才設(shè)置成功這是拿鎖的關(guān)鍵。鎖的過期時(shí)間要設(shè)否則持有者崩了會(huì)死鎖。5.3 雪崩的預(yù)防與兜底策略雪崩的預(yù)防核心是打散過期時(shí)間。給 TTL 加一個(gè)隨機(jī)偏移量是最簡(jiǎn)單有效的做法ttl 3600 random.randint(0, 600) redis.set(key, value, exttl)這樣即使批量預(yù)熱過期時(shí)間也會(huì)分散在十分鐘的窗口里不會(huì)同時(shí)失效。除了打散還要做幾層兜底本地緩存比如 Caffeine作為二級(jí)緩存擋第一波流量數(shù)據(jù)庫(kù)連接池限流避免被打死關(guān)鍵接口做熔斷降級(jí)返回兜底數(shù)據(jù)而不是直接報(bào)錯(cuò)。我的實(shí)際經(jīng)驗(yàn)有一次批量導(dǎo)入商品后統(tǒng)一預(yù)熱緩存所有 key 的 TTL 都是 7200 秒結(jié)果兩小時(shí)后整批同時(shí)失效數(shù)據(jù)庫(kù) CPU 直接打滿。后來改成預(yù)熱時(shí)按7200 random(0, 1200)設(shè)置再?zèng)]出現(xiàn)過集體失效。5.4 雙寫一致性該怎么做緩存和數(shù)據(jù)庫(kù)同時(shí)寫一定有短暫不一致關(guān)鍵是控制窗口和最終一致。業(yè)界主流是 Cache Aside 模式讀的時(shí)候先讀緩存沒有再讀庫(kù)并回填寫的時(shí)候先更新數(shù)據(jù)庫(kù)再刪除緩存。為什么是刪緩存而不是更新緩存因?yàn)椴l(fā)更新時(shí)兩個(gè)請(qǐng)求的更新順序可能和寫庫(kù)順序不一致導(dǎo)致緩存里存了舊值。刪除操作更安全下次讀的時(shí)候自然回填最新值。但先寫庫(kù)再刪緩存仍有極小概率出問題讀請(qǐng)求在寫庫(kù)之后、刪緩存之前讀到舊值并回填。常用的補(bǔ)救是延遲雙刪——寫完庫(kù)刪一次隔幾百毫秒再刪一次。更徹底的方案是訂閱數(shù)據(jù)庫(kù)的 binlog異步刪除緩存把一致性保障從業(yè)務(wù)代碼里剝離出來。6. 線上出問題時(shí)我一般從這幾個(gè)命令開始查Redis 的問題看起來五花八門實(shí)際上集中在幾類內(nèi)存漲了、變慢了、連接不上了、數(shù)據(jù)不對(duì)了。每一類都有對(duì)應(yīng)的排查入口。6.1 內(nèi)存類問題的定位路徑第一步看整體redis-cli -a 密碼 INFO memory重點(diǎn)看三個(gè)值used_memory_human實(shí)際使用、used_memory_rss_human操作系統(tǒng)看到的內(nèi)存、mem_fragmentation_ratio碎片率。碎片率在 1.0 到 1.5 之間算正常超過 1.5 說明碎片較多可以考慮開啟activedefrag yes做在線碎片整理或者在低峰期重啟。第二步找大 keyredis-cli -a 密碼 --bigkeys這個(gè)命令會(huì)掃描全庫(kù)并列出每種類型最大的 key。注意它會(huì)遍歷所有鍵在數(shù)據(jù)量大的實(shí)例上會(huì)明顯增加負(fù)載建議在從節(jié)點(diǎn)或者低峰期執(zhí)行。找到大 key 之后單個(gè) key 的內(nèi)存占用可以用MEMORY USAGE user:2001如果確認(rèn)是某個(gè)大 Hash 或者大 List 占了幾百兆刪除時(shí)千萬(wàn)別用 DEL會(huì)阻塞主線程。改用UNLINK它在后臺(tái)線程異步釋放內(nèi)存UNLINK big:hash:key6.2 變慢的常見原因與排查手法Redis 變慢無非幾個(gè)方向慢命令、大 key 操作、網(wǎng)絡(luò)問題、持久化阻塞。先用慢查詢?nèi)罩径ㄎ籆ONFIG SET slowlog-log-slower-than 10000 SLOWLOG GET 1010000 微秒就是 10 毫秒超過這個(gè)閾值的命令會(huì)被記錄。SLOWLOG GET 返回最近的慢命令包含執(zhí)行時(shí)間、命令內(nèi)容、客戶端地址。常見的慢命令有KEYS *全庫(kù)掃描生產(chǎn)禁用、FLUSHALL清庫(kù)、大集合的SMEMBERS、大 ZSet 的ZRANGE全量取。這些都在主線程執(zhí)行一次就能把整個(gè)實(shí)例卡住。另一個(gè)隱蔽的原因是持久化。開著 AOF everysec 的情況下如果磁盤 IO 跟不上fsync 會(huì)阻塞寫入?？梢酝ㄟ^INFO persistence看aof_delayed_fsync這個(gè)指標(biāo)如果它一直增長(zhǎng)說明磁盤扛不住了要么換 SSD要么改配置。6.3 連接與命中率類問題連接數(shù)打滿是很常見的線上故障先用這個(gè)看CLIENT LIST INFO clientsconnected_clients接近maxclients時(shí)新連接會(huì)被拒絕。原因通常是應(yīng)用側(cè)連接池配置過大或者連接沒正確釋放。檢查連接池的maxTotal和maxIdle一般建議單實(shí)例連接池控制在 50 以內(nèi)多個(gè)應(yīng)用實(shí)例加起來別超過 maxclients 的 80%。命中率同樣重要INFO stats看keyspace_hits和keyspace_misses兩者相除就是命中率。低于 80% 就要反思緩存策略了可能是 TTL 太短、緩存的數(shù)據(jù)根本沒人訪問、或者 key 設(shè)計(jì)有問題導(dǎo)致查不到。6.4 排查速查表現(xiàn)象首選命令常見原因處理方式內(nèi)存持續(xù)上漲INFO memory大 key、無 TTL、碎片找大 key、補(bǔ) TTL、開碎片整理響應(yīng)變慢SLOWLOG GET慢命令、大 key 操作替換命令、拆分 key連接被拒INFO clients連接池過大、未釋放調(diào)小池子、查泄漏命中率低INFO statsTTL 過短、key 設(shè)計(jì)差調(diào)整策略、重新設(shè)計(jì)持久化卡頓INFO persistence磁盤 IO 不足換盤、調(diào) fsync 策略數(shù)據(jù)不一致業(yè)務(wù)側(cè)日志雙寫順序錯(cuò)、刪除失敗延遲雙刪、訂閱 binlog一個(gè)容易忽略的點(diǎn)INFO命令在高版本里可以帶 section 參數(shù)比如INFO memory只返回內(nèi)存相關(guān)字段比全量 INFO 快很多。寫監(jiān)控腳本時(shí)用分節(jié)查詢能減少對(duì)主線程的影響。最后分享一個(gè)我在實(shí)際運(yùn)維里養(yǎng)成的小習(xí)慣給每個(gè)業(yè)務(wù)線的 key 加上統(tǒng)一的命名前綴比如order:、user:、cfg:配合SCAN命令按前綴遍歷千萬(wàn)別用 KEYS。這樣做的好處是排查時(shí)能快速圈定范圍做容量評(píng)估時(shí)也能按業(yè)務(wù)線統(tǒng)計(jì)。我一般是這么掃的redis-cli -a 密碼 --scan --pattern order:* | head -100另外新實(shí)例上線前我都會(huì)跑一輪壓測(cè)用 redis-benchmark 把基線摸清楚redis-benchmark -h 127.0.0.1 -p 6379 -a 密碼 -n 100000 -c 50 -t set,get -q這個(gè)基線數(shù)據(jù)的價(jià)值在于線上出現(xiàn)性能問題時(shí)你有個(gè)對(duì)照系——是整體變慢了還是某類命令變慢了一眼就能判斷。沒有基線的排查基本靠猜有了基線排查效率完全是另一個(gè)層次。