實(shí)戰(zhàn)：內(nèi)存模型、數(shù)據(jù)結(jié)構(gòu)與緩存異常排查)
第一次在項(xiàng)目里被 Redis 救場是好幾年前一個(gè)商品詳情頁的接口。那時(shí)候數(shù)據(jù)庫的 QPS 已經(jīng)被壓到貼著地板走頁面每次刷新都要連表查十幾張表高峰期接口響應(yīng)時(shí)間直接干到三秒以上。后來把詳情頁那份聚合數(shù)據(jù)整成一份 JSON 塞進(jìn) Redis超時(shí)率當(dāng)天就掉下來了。從那以后我對這個(gè)中間件的態(tài)度就變了——它不是加個(gè)緩存這么簡單而是一套需要認(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)對再到線上排查的實(shí)操手法我會按我自己踩過的順序講一遍。看完你至少能做到兩件事知道什么數(shù)據(jù)該往 Redis 里放、什么數(shù)據(jù)不該放以及在它出問題的時(shí)候知道從哪幾個(gè)命令開始查。1. 先搞清楚 Redis 到底在項(xiàng)目里補(bǔ)的是哪塊短板很多人對 Redis 的第一印象是內(nèi)存數(shù)據(jù)庫讀得快這個(gè)描述沒錯(cuò)但太淺。真把它放進(jìn)架構(gòu)里你得先明白它替代的是哪一段鏈路否則用著用著就會出現(xiàn)緩存加了一堆接口還是慢或者數(shù)據(jù)對不上這類問題。1.1 從一次接口超時(shí)反推它解決的問題回到開頭那個(gè)詳情頁的例子。當(dāng)時(shí)那條鏈路的耗時(shí)分布大致是這樣的數(shù)據(jù)庫連接池等待、多表 JOIN、結(jié)果集序列化、網(wǎng)絡(luò)傳輸。真正壓死駱駝的是 JOIN 和連接池爭搶因?yàn)樵斍轫摰淖x請求量是寫請求的幾十倍每次讀都要重新拼裝一遍數(shù)據(jù)數(shù)據(jù)庫的 buffer pool 命中率再高也頂不住這種重復(fù)勞動(dòng)。Redis 在這里的價(jià)值不是快而是把一次復(fù)雜的計(jì)算或查詢結(jié)果變成一次 O(1) 的內(nèi)存讀取。這兩者的差別在于數(shù)據(jù)庫快是因?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ù)庫的查詢能力全丟了后來要做按手機(jī)號模糊搜索、按注冊時(shí)間排序全得在應(yīng)用層手寫最后又灰溜溜地加回?cái)?shù)據(jù)庫查詢。所以第一件事要先劃清邊界。1.2 Redis 與關(guān)系型數(shù)據(jù)庫的職責(zé)分工我的劃分原則很簡單數(shù)據(jù)庫負(fù)責(zé)真相Redis 負(fù)責(zé)效率。具體到落地下面這幾類數(shù)據(jù)適合放進(jìn)去讀多寫少、且允許短暫不一致的熱點(diǎn)數(shù)據(jù)比如商品詳情、配置項(xiàng)、字典表。有明確過期語義的數(shù)據(jù)比如登錄態(tài)、驗(yàn)證碼、短信頻控計(jì)數(shù)。需要原子性計(jì)數(shù)的場景比如庫存扣減的預(yù)扣、接口限流、文章閱讀數(shù)。需要跨進(jìn)程共享的臨時(shí)狀態(tài)比如分布式鎖、任務(wù)隊(duì)列、秒殺排隊(duì)。反過來下面這些我基本不往 Redis 里塞需要復(fù)雜條件查詢、聚合統(tǒng)計(jì)的業(yè)務(wù)主數(shù)據(jù)。單條體積超過幾十 KB 的大對象尤其是列表頁會批量取的。需要強(qiáng)事務(wù)保證的跨實(shí)體寫操作。生命周期極短且無復(fù)用價(jià)值的臨時(shí)數(shù)據(jù)。這里有個(gè)判斷口訣如果這份數(shù)據(jù)丟了業(yè)務(wù)能不能靠數(shù)據(jù)庫重建能重建的才適合放進(jìn)緩存層不能重建的說明它是真相的一部分應(yīng)該留在數(shù)據(jù)庫。還有一點(diǎn)容易被忽略Redis 的內(nèi)存這個(gè)屬性意味著成本和容量都是硬約束。一臺 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)了跨請求共享狀態(tài)的需求。如果只是幾千條數(shù)據(jù)的后臺管理系統(tǒng)查詢走索引完全夠用引入 Redis 只是多了一個(gè)需要運(yùn)維的組件。但只要出現(xiàn)下面任意一種情況它就值得上了同一份數(shù)據(jù)一秒內(nèi)被讀幾十次以上需要給接口做頻率限制需要給多個(gè)服務(wù)實(shí)例共享會話需要做排行榜、延時(shí)任務(wù)這類數(shù)據(jù)庫不擅長的結(jié)構(gòu)。這些都是硬需求跟項(xiàng)目規(guī)模無關(guān)。2. 單線程還能這么快底層到底做了什么Redis 是單線程的這句話流傳太廣以至于很多人第一次聽到會懷疑它扛不住并發(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è)線程輪詢處理成千上萬個(gè)連接。這帶來的好處非常直接不需要加鎖不存在競態(tài)任何一條命令執(zhí)行期間數(shù)據(jù)狀態(tài)都是確定的。像 INCR 這種操作天然就是原子的你不用操心并發(fā)問題。但網(wǎng)絡(luò)讀寫本身是有開銷的。Redis 6.0 之后引入了 IO 多線程注意是只把 socket 的讀寫和協(xié)議解析分給多個(gè)線程命令執(zhí)行仍然在主線程串行。這個(gè)改動(dòng)對高吞吐場景比如大 value 的批量讀寫提升明顯因?yàn)槠款i從 CPU 計(jì)算轉(zhuǎn)移到了網(wǎng)絡(luò)拷貝上。配置上對應(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è)。開太多反而會因?yàn)榫€程調(diào)度拖慢我在一臺 32 核機(jī)器上試過開到 16吞吐量相比 8 個(gè)還降了一點(diǎn)。2.2 內(nèi)存存儲與底層數(shù)據(jù)結(jié)構(gòu)的取舍純內(nèi)存這件事本身就是數(shù)量級的差距。一次內(nèi)存隨機(jī)訪問大概在 100 納秒量級而一次機(jī)械硬盤尋道是毫秒級SSD 也是幾十微秒級差距在四到五個(gè)數(shù)量級。但光快還不夠Redis 在數(shù)據(jù)結(jié)構(gòu)上做了很多省內(nèi)存的文章這部分決定了你的實(shí)例能裝多少數(shù)據(jù)。舉個(gè)具體例子一個(gè)普通的 String 并不是簡單地 malloc 一塊內(nèi)存而是用 SDS簡單動(dòng)態(tài)字符串來實(shí)現(xiàn)頭部記錄了長度和剩余空間好處是獲取長度是 O(1)、拼接時(shí)可以做預(yù)分配、并且二進(jìn)制安全可以存圖片、序列化對象。再比如小規(guī)模的 Hash底層不會一上來就用哈希表而是用 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)存儲一旦超過就轉(zhuǎn)成真正的哈希表。轉(zhuǎn)過去之后內(nèi)存占用可能翻好幾倍而且這個(gè)過程是不可逆的——即使你后來把字段刪到只剩 3 個(gè)它也不會變回緊湊結(jié)構(gòu)。我在一個(gè)存用戶標(biāo)簽的 Hash 上踩過這個(gè)坑前期測試時(shí)每個(gè)用戶 20 來個(gè)標(biāo)簽內(nèi)存很漂亮上線后運(yùn)營批量打標(biāo)某些用戶標(biāo)簽數(shù)沖到 200整個(gè)實(shí)例內(nèi)存直接漲了 40%。2.3 持久化RDB 與 AOF 的選擇邏輯內(nèi)存數(shù)據(jù)庫最怕的是斷電所以持久化機(jī)制必須搞清楚。Redis 給了兩種方式理解它們的關(guān)鍵是搞明白各自犧牲了什么。RDB是某一時(shí)刻的全量快照通過 fork 子進(jìn)程 寫時(shí)復(fù)制來完成。優(yōu)點(diǎn)是文件緊湊、恢復(fù)速度快適合做備份和災(zāi)備。缺點(diǎn)是兩次快照之間的數(shù)據(jù)會丟而且 fork 的瞬間如果數(shù)據(jù)量大會有明顯的內(nèi)存膨脹和短暫卡頓。AOF是追加寫命令日志按 fsync 策略分三檔策略行為數(shù)據(jù)安全性能影響always每條命令都刷盤最高最多丟一條最差QPS 掉一個(gè)數(shù)量級everysec每秒刷一次最多丟一秒可接受生產(chǎn)常用no交給操作系統(tǒng)可能丟較多最好不建議生產(chǎn)用AOF 的問題是文件會越來越大所以需要重寫rewrite本質(zhì)上也是 fork 子進(jìn)程根據(jù)當(dāng)前內(nèi)存狀態(tài)生成一份精簡的命令集。實(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)對應(yīng)五類真實(shí)業(yè)務(wù)場景Redis 常被叫做數(shù)據(jù)結(jié)構(gòu)服務(wù)器這個(gè)定位很準(zhǔn)確。它的價(jià)值不在于能存 key-value而在于它把常用的幾種數(shù)據(jù)結(jié)構(gòu)做成了服務(wù)端原語你在應(yīng)用層不用自己實(shí)現(xiàn)加鎖和并發(fā)控制。3.1 String 與 Hash緩存對象時(shí)的兩種打法String 是最基礎(chǔ)的能存字符串、數(shù)字、二進(jìn)制。最典型的用法是緩存整個(gè)對象序列化后的 JSONSET product:1001 {id:1001,name:某商品,price:99.00} EX 3600 GET product:1001EX 3600 表示一小時(shí)后過期。這種整存整取的方式適合讀多寫少、且每次都要完整對象的場景比如詳情頁。Hash 則適合需要部分讀寫、或者字段會獨(dú)立變化的場景HSET user:2001 name A同學(xué) level 3 lastLogin 2024-05-01 HGET user:2001 level HINCRBY user:2001 level 1用 Hash 的好處是可以只更新某個(gè)字段不用把整個(gè)對象讀出來改完再寫回去減少了網(wǎng)絡(luò)傳輸和序列化開銷。缺點(diǎn)是過期時(shí)間只能加在整個(gè) key 上沒法給單個(gè)字段設(shè) TTL。選型上我的經(jīng)驗(yàn)是對象字段少、整體讀寫就 String對象字段多、經(jīng)常單獨(dú)更新某個(gè)字段就 Hash。但要注意 2.2 里提到的結(jié)構(gòu)轉(zhuǎn)換問題字段數(shù)別讓它無限增長。有個(gè)容易忽略的細(xì)節(jié)String 存數(shù)字時(shí)可以直接用 INCR/DECR 做原子計(jì)數(shù)這是做限流、庫存預(yù)扣的基礎(chǔ)。像接口頻控這種場景我是這么寫的# 一分鐘內(nèi)同一用戶最多 60 次 INCR rate:limit:user:2001:202405011200 EXPIRE rate:limit:user:2001:202405011200 60兩次命令不是原子的嚴(yán)格場景需要用 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í)候會掛起等待超時(shí)返回 nil。用這個(gè)做簡單的任務(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)幾萬規(guī)模的集合還行上百萬就要考慮用別的方式了。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ì)列輕量得多精度控制在秒級完全夠用。3.4 結(jié)構(gòu)選型速查業(yè)務(wù)需求推薦結(jié)構(gòu)關(guān)鍵命令注意事項(xiàng)對象緩存StringSET/GET體積控制在 10KB 內(nèi)局部字段更新HashHSET/HGET字段數(shù)別超 128簡單隊(duì)列ListLPUSH/BRPOP無 ACK謹(jǐn)慎用于關(guān)鍵任務(wù)去重計(jì)數(shù)SetSADD/SCARD大集合注意內(nèi)存共同關(guān)系SetSINTER規(guī)模別上百萬排行榜ZSetZINCRBY/ZREVRANGEscore 用 double注意精度延時(shí)任務(wù)ZSetZADD/ZRANGEBYSCORE需要輪詢進(jìn)程配合頻控計(jì)數(shù)StringINCR/EXPIRE建議用 Lua 保證原子4. 從零裝一套能用的 Redis理論講完落到手上。這部分我按裝、配、驗(yàn)三步走配置部分會把幾個(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)會出事。下面這幾項(xiàng)我每次部署都會過一遍# 網(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 會一直吃內(nèi)存直到被系統(tǒng)殺掉那時(shí)候就不是淘汰幾個(gè) key 的問題了而是整個(gè)實(shí)例掛掉。maxmemory-policy的選擇取決于你的數(shù)據(jù)性質(zhì)noeviction內(nèi)存滿了直接報(bào)錯(cuò)適合數(shù)據(jù)不能丟的場景。allkeys-lru所有 key 里淘汰最近最少使用的純緩存場景首選。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è)約定來保證它們不會被誤淘汰。4.3 連通性驗(yàn)證與基礎(chǔ)命令實(shí)測裝完之后別急著寫代碼先手工驗(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è)都有對應(yīng)的打法緩存用起來之后真正讓人睡不著覺的不是性能而是數(shù)據(jù)一致性和異常流量。所謂穿透、擊穿、雪崩這三個(gè)詞說的是三種不同的失效模式應(yīng)對手段也完全不同必須分清楚。5.1 三種失效模式的成因?qū)Ρ犬惓ｎ愋陀|發(fā)條件現(xiàn)象影響范圍緩存穿透查詢根本不存在的數(shù)據(jù)每次都打到數(shù)據(jù)庫可能被惡意利用緩存擊穿熱點(diǎn) key 過期瞬間大量請求同時(shí)打庫單個(gè)熱點(diǎn)緩存雪崩大量 key 同時(shí)過期或?qū)嵗礄C(jī)數(shù)據(jù)庫瞬間承壓全局性穿透的本質(zhì)是緩存里沒有數(shù)據(jù)庫里也沒有查詢永遠(yuǎn)落空緩存形同虛設(shè)。擊穿是緩存里本來有剛好過期了一瞬間所有請求涌向數(shù)據(jù)庫。雪崩則是更大范圍的集體失效。這三者的共同點(diǎn)是把數(shù)據(jù)庫當(dāng)成了兜底所以核心思路都是在緩存層就把請求擋住或者分流。5.2 穿透與擊穿的落地實(shí)現(xiàn)對付穿透最直接的辦法是緩存空值。查數(shù)據(jù)庫沒查到也往 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 瘋狂請求會往 Redis 里塞大量空值 key所以通常要配合布隆過濾器在入口先做一層攔截。布隆過濾器判斷一定不存在是準(zhǔn)確的判斷存在有誤判率剛好適合放在緩存前面。擊穿的解法是加互斥鎖保證同一時(shí)刻只有一個(gè)請求去回源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è)否則持有者崩了會死鎖。5.3 雪崩的預(yù)防與兜底策略雪崩的預(yù)防核心是打散過期時(shí)間。給 TTL 加一個(gè)隨機(jī)偏移量是最簡單有效的做法ttl 3600 random.randint(0, 600) redis.set(key, value, exttl)這樣即使批量預(yù)熱過期時(shí)間也會分散在十分鐘的窗口里不會同時(shí)失效。除了打散還要做幾層兜底本地緩存比如 Caffeine作為二級緩存擋第一波流量數(shù)據(jù)庫連接池限流避免被打死關(guān)鍵接口做熔斷降級返回兜底數(shù)據(jù)而不是直接報(bào)錯(cuò)。我的實(shí)際經(jīng)驗(yàn)有一次批量導(dǎo)入商品后統(tǒng)一預(yù)熱緩存所有 key 的 TTL 都是 7200 秒結(jié)果兩小時(shí)后整批同時(shí)失效數(shù)據(jù)庫 CPU 直接打滿。后來改成預(yù)熱時(shí)按7200 random(0, 1200)設(shè)置再沒出現(xiàn)過集體失效。5.4 雙寫一致性該怎么做緩存和數(shù)據(jù)庫同時(shí)寫一定有短暫不一致關(guān)鍵是控制窗口和最終一致。業(yè)界主流是 Cache Aside 模式讀的時(shí)候先讀緩存沒有再讀庫并回填寫的時(shí)候先更新數(shù)據(jù)庫再刪除緩存。為什么是刪緩存而不是更新緩存因?yàn)椴l(fā)更新時(shí)兩個(gè)請求的更新順序可能和寫庫順序不一致導(dǎo)致緩存里存了舊值。刪除操作更安全下次讀的時(shí)候自然回填最新值。但先寫庫再刪緩存仍有極小概率出問題讀請求在寫庫之后、刪緩存之前讀到舊值并回填。常用的補(bǔ)救是延遲雙刪——寫完庫刪一次隔幾百毫秒再刪一次。更徹底的方案是訂閱數(shù)據(jù)庫的 binlog異步刪除緩存把一致性保障從業(yè)務(wù)代碼里剝離出來。6. 線上出問題時(shí)我一般從這幾個(gè)命令開始查Redis 的問題看起來五花八門實(shí)際上集中在幾類內(nèi)存漲了、變慢了、連接不上了、數(shù)據(jù)不對了。每一類都有對應(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è)命令會掃描全庫并列出每種類型最大的 key。注意它會遍歷所有鍵在數(shù)據(jù)量大的實(shí)例上會明顯增加負(fù)載建議在從節(jié)點(diǎn)或者低峰期執(zhí)行。找到大 key 之后單個(gè) key 的內(nèi)存占用可以用MEMORY USAGE user:2001如果確認(rèn)是某個(gè)大 Hash 或者大 List 占了幾百兆刪除時(shí)千萬別用 DEL會阻塞主線程。改用UNLINK它在后臺線程異步釋放內(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è)閾值的命令會被記錄。SLOWLOG GET 返回最近的慢命令包含執(zhí)行時(shí)間、命令內(nèi)容、客戶端地址。常見的慢命令有KEYS *全庫掃描生產(chǎn)禁用、FLUSHALL清庫、大集合的SMEMBERS、大 ZSet 的ZRANGE全量取。這些都在主線程執(zhí)行一次就能把整個(gè)實(shí)例卡住。另一個(gè)隱蔽的原因是持久化。開著 AOF everysec 的情況下如果磁盤 IO 跟不上fsync 會阻塞寫入?？梢酝ㄟ^INFO persistence看aof_delayed_fsync這個(gè)指標(biāo)如果它一直增長說明磁盤扛不住了要么換 SSD要么改配置。6.3 連接與命中率類問題連接數(shù)打滿是很常見的線上故障先用這個(gè)看CLIENT LIST INFO clientsconnected_clients接近maxclients時(shí)新連接會被拒絕。原因通常是應(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é)查詢能減少對主線程的影響。最后分享一個(gè)我在實(shí)際運(yùn)維里養(yǎng)成的小習(xí)慣給每個(gè)業(yè)務(wù)線的 key 加上統(tǒng)一的命名前綴比如order:、user:、cfg:配合SCAN命令按前綴遍歷千萬別用 KEYS。這樣做的好處是排查時(shí)能快速圈定范圍做容量評估時(shí)也能按業(yè)務(wù)線統(tǒng)計(jì)。我一般是這么掃的redis-cli -a 密碼 --scan --pattern order:* | head -100另外新實(shí)例上線前我都會跑一輪壓測用 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è)對照系——是整體變慢了還是某類命令變慢了一眼就能判斷。沒有基線的排查基本靠猜有了基線排查效率完全是另一個(gè)層次。 Redis生產(chǎn)實(shí)戰(zhàn)：內(nèi)存模型、數(shù)據(jù)結(jié)構(gòu)與緩存異常排查
第一次在項(xiàng)目里被 Redis 救場是好幾年前一個(gè)商品詳情頁的接口。那時(shí)候數(shù)據(jù)庫的 QPS 已經(jīng)被壓到貼著地板走頁面每次刷新都要連表查十幾張表高峰期接口響應(yīng)時(shí)間直接干到三秒以上。后來把詳情頁那份聚合數(shù)據(jù)整成一份 JSON 塞進(jìn) Redis超時(shí)率當(dāng)天就掉下來了。從那以后我對這個(gè)中間件的態(tài)度就變了——它不是加個(gè)緩存這么簡單而是一套需要認(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)對再到線上排查的實(shí)操手法我會按我自己踩過的順序講一遍。看完你至少能做到兩件事知道什么數(shù)據(jù)該往 Redis 里放、什么數(shù)據(jù)不該放以及在它出問題的時(shí)候知道從哪幾個(gè)命令開始查。1. 先搞清楚 Redis 到底在項(xiàng)目里補(bǔ)的是哪塊短板很多人對 Redis 的第一印象是內(nèi)存數(shù)據(jù)庫讀得快這個(gè)描述沒錯(cuò)但太淺。真把它放進(jìn)架構(gòu)里你得先明白它替代的是哪一段鏈路否則用著用著就會出現(xiàn)緩存加了一堆接口還是慢或者數(shù)據(jù)對不上這類問題。1.1 從一次接口超時(shí)反推它解決的問題回到開頭那個(gè)詳情頁的例子。當(dāng)時(shí)那條鏈路的耗時(shí)分布大致是這樣的數(shù)據(jù)庫連接池等待、多表 JOIN、結(jié)果集序列化、網(wǎng)絡(luò)傳輸。真正壓死駱駝的是 JOIN 和連接池爭搶因?yàn)樵斍轫摰淖x請求量是寫請求的幾十倍每次讀都要重新拼裝一遍數(shù)據(jù)數(shù)據(jù)庫的 buffer pool 命中率再高也頂不住這種重復(fù)勞動(dòng)。Redis 在這里的價(jià)值不是快而是把一次復(fù)雜的計(jì)算或查詢結(jié)果變成一次 O(1) 的內(nèi)存讀取。這兩者的差別在于數(shù)據(jù)庫快是因?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ù)庫的查詢能力全丟了后來要做按手機(jī)號模糊搜索、按注冊時(shí)間排序全得在應(yīng)用層手寫最后又灰溜溜地加回?cái)?shù)據(jù)庫查詢。所以第一件事要先劃清邊界。1.2 Redis 與關(guān)系型數(shù)據(jù)庫的職責(zé)分工我的劃分原則很簡單數(shù)據(jù)庫負(fù)責(zé)真相Redis 負(fù)責(zé)效率。具體到落地下面這幾類數(shù)據(jù)適合放進(jìn)去讀多寫少、且允許短暫不一致的熱點(diǎn)數(shù)據(jù)比如商品詳情、配置項(xiàng)、字典表。有明確過期語義的數(shù)據(jù)比如登錄態(tài)、驗(yàn)證碼、短信頻控計(jì)數(shù)。需要原子性計(jì)數(shù)的場景比如庫存扣減的預(yù)扣、接口限流、文章閱讀數(shù)。需要跨進(jìn)程共享的臨時(shí)狀態(tài)比如分布式鎖、任務(wù)隊(duì)列、秒殺排隊(duì)。反過來下面這些我基本不往 Redis 里塞需要復(fù)雜條件查詢、聚合統(tǒng)計(jì)的業(yè)務(wù)主數(shù)據(jù)。單條體積超過幾十 KB 的大對象尤其是列表頁會批量取的。需要強(qiáng)事務(wù)保證的跨實(shí)體寫操作。生命周期極短且無復(fù)用價(jià)值的臨時(shí)數(shù)據(jù)。這里有個(gè)判斷口訣如果這份數(shù)據(jù)丟了業(yè)務(wù)能不能靠數(shù)據(jù)庫重建能重建的才適合放進(jìn)緩存層不能重建的說明它是真相的一部分應(yīng)該留在數(shù)據(jù)庫。還有一點(diǎn)容易被忽略Redis 的內(nèi)存這個(gè)屬性意味著成本和容量都是硬約束。一臺 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)了跨請求共享狀態(tài)的需求。如果只是幾千條數(shù)據(jù)的后臺管理系統(tǒng)查詢走索引完全夠用引入 Redis 只是多了一個(gè)需要運(yùn)維的組件。但只要出現(xiàn)下面任意一種情況它就值得上了同一份數(shù)據(jù)一秒內(nèi)被讀幾十次以上需要給接口做頻率限制需要給多個(gè)服務(wù)實(shí)例共享會話需要做排行榜、延時(shí)任務(wù)這類數(shù)據(jù)庫不擅長的結(jié)構(gòu)。這些都是硬需求跟項(xiàng)目規(guī)模無關(guān)。2. 單線程還能這么快底層到底做了什么Redis 是單線程的這句話流傳太廣以至于很多人第一次聽到會懷疑它扛不住并發(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è)線程輪詢處理成千上萬個(gè)連接。這帶來的好處非常直接不需要加鎖不存在競態(tài)任何一條命令執(zhí)行期間數(shù)據(jù)狀態(tài)都是確定的。像 INCR 這種操作天然就是原子的你不用操心并發(fā)問題。但網(wǎng)絡(luò)讀寫本身是有開銷的。Redis 6.0 之后引入了 IO 多線程注意是只把 socket 的讀寫和協(xié)議解析分給多個(gè)線程命令執(zhí)行仍然在主線程串行。這個(gè)改動(dòng)對高吞吐場景比如大 value 的批量讀寫提升明顯因?yàn)槠款i從 CPU 計(jì)算轉(zhuǎn)移到了網(wǎng)絡(luò)拷貝上。配置上對應(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è)。開太多反而會因?yàn)榫€程調(diào)度拖慢我在一臺 32 核機(jī)器上試過開到 16吞吐量相比 8 個(gè)還降了一點(diǎn)。2.2 內(nèi)存存儲與底層數(shù)據(jù)結(jié)構(gòu)的取舍純內(nèi)存這件事本身就是數(shù)量級的差距。一次內(nèi)存隨機(jī)訪問大概在 100 納秒量級而一次機(jī)械硬盤尋道是毫秒級SSD 也是幾十微秒級差距在四到五個(gè)數(shù)量級。但光快還不夠Redis 在數(shù)據(jù)結(jié)構(gòu)上做了很多省內(nèi)存的文章這部分決定了你的實(shí)例能裝多少數(shù)據(jù)。舉個(gè)具體例子一個(gè)普通的 String 并不是簡單地 malloc 一塊內(nèi)存而是用 SDS簡單動(dòng)態(tài)字符串來實(shí)現(xiàn)頭部記錄了長度和剩余空間好處是獲取長度是 O(1)、拼接時(shí)可以做預(yù)分配、并且二進(jìn)制安全可以存圖片、序列化對象。再比如小規(guī)模的 Hash底層不會一上來就用哈希表而是用 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)存儲一旦超過就轉(zhuǎn)成真正的哈希表。轉(zhuǎn)過去之后內(nèi)存占用可能翻好幾倍而且這個(gè)過程是不可逆的——即使你后來把字段刪到只剩 3 個(gè)它也不會變回緊湊結(jié)構(gòu)。我在一個(gè)存用戶標(biāo)簽的 Hash 上踩過這個(gè)坑前期測試時(shí)每個(gè)用戶 20 來個(gè)標(biāo)簽內(nèi)存很漂亮上線后運(yùn)營批量打標(biāo)某些用戶標(biāo)簽數(shù)沖到 200整個(gè)實(shí)例內(nèi)存直接漲了 40%。2.3 持久化RDB 與 AOF 的選擇邏輯內(nèi)存數(shù)據(jù)庫最怕的是斷電所以持久化機(jī)制必須搞清楚。Redis 給了兩種方式理解它們的關(guān)鍵是搞明白各自犧牲了什么。RDB是某一時(shí)刻的全量快照通過 fork 子進(jìn)程 寫時(shí)復(fù)制來完成。優(yōu)點(diǎn)是文件緊湊、恢復(fù)速度快適合做備份和災(zāi)備。缺點(diǎn)是兩次快照之間的數(shù)據(jù)會丟而且 fork 的瞬間如果數(shù)據(jù)量大會有明顯的內(nèi)存膨脹和短暫卡頓。AOF是追加寫命令日志按 fsync 策略分三檔策略行為數(shù)據(jù)安全性能影響always每條命令都刷盤最高最多丟一條最差QPS 掉一個(gè)數(shù)量級everysec每秒刷一次最多丟一秒可接受生產(chǎn)常用no交給操作系統(tǒng)可能丟較多最好不建議生產(chǎn)用AOF 的問題是文件會越來越大所以需要重寫rewrite本質(zhì)上也是 fork 子進(jìn)程根據(jù)當(dāng)前內(nèi)存狀態(tài)生成一份精簡的命令集。實(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)對應(yīng)五類真實(shí)業(yè)務(wù)場景Redis 常被叫做數(shù)據(jù)結(jié)構(gòu)服務(wù)器這個(gè)定位很準(zhǔn)確。它的價(jià)值不在于能存 key-value而在于它把常用的幾種數(shù)據(jù)結(jié)構(gòu)做成了服務(wù)端原語你在應(yīng)用層不用自己實(shí)現(xiàn)加鎖和并發(fā)控制。3.1 String 與 Hash緩存對象時(shí)的兩種打法String 是最基礎(chǔ)的能存字符串、數(shù)字、二進(jìn)制。最典型的用法是緩存整個(gè)對象序列化后的 JSONSET product:1001 {id:1001,name:某商品,price:99.00} EX 3600 GET product:1001EX 3600 表示一小時(shí)后過期。這種整存整取的方式適合讀多寫少、且每次都要完整對象的場景比如詳情頁。Hash 則適合需要部分讀寫、或者字段會獨(dú)立變化的場景HSET user:2001 name A同學(xué) level 3 lastLogin 2024-05-01 HGET user:2001 level HINCRBY user:2001 level 1用 Hash 的好處是可以只更新某個(gè)字段不用把整個(gè)對象讀出來改完再寫回去減少了網(wǎng)絡(luò)傳輸和序列化開銷。缺點(diǎn)是過期時(shí)間只能加在整個(gè) key 上沒法給單個(gè)字段設(shè) TTL。選型上我的經(jīng)驗(yàn)是對象字段少、整體讀寫就 String對象字段多、經(jīng)常單獨(dú)更新某個(gè)字段就 Hash。但要注意 2.2 里提到的結(jié)構(gòu)轉(zhuǎn)換問題字段數(shù)別讓它無限增長。有個(gè)容易忽略的細(xì)節(jié)String 存數(shù)字時(shí)可以直接用 INCR/DECR 做原子計(jì)數(shù)這是做限流、庫存預(yù)扣的基礎(chǔ)。像接口頻控這種場景我是這么寫的# 一分鐘內(nèi)同一用戶最多 60 次 INCR rate:limit:user:2001:202405011200 EXPIRE rate:limit:user:2001:202405011200 60兩次命令不是原子的嚴(yán)格場景需要用 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í)候會掛起等待超時(shí)返回 nil。用這個(gè)做簡單的任務(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)幾萬規(guī)模的集合還行上百萬就要考慮用別的方式了。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ì)列輕量得多精度控制在秒級完全夠用。3.4 結(jié)構(gòu)選型速查業(yè)務(wù)需求推薦結(jié)構(gòu)關(guān)鍵命令注意事項(xiàng)對象緩存StringSET/GET體積控制在 10KB 內(nèi)局部字段更新HashHSET/HGET字段數(shù)別超 128簡單隊(duì)列ListLPUSH/BRPOP無 ACK謹(jǐn)慎用于關(guān)鍵任務(wù)去重計(jì)數(shù)SetSADD/SCARD大集合注意內(nèi)存共同關(guān)系SetSINTER規(guī)模別上百萬排行榜ZSetZINCRBY/ZREVRANGEscore 用 double注意精度延時(shí)任務(wù)ZSetZADD/ZRANGEBYSCORE需要輪詢進(jìn)程配合頻控計(jì)數(shù)StringINCR/EXPIRE建議用 Lua 保證原子4. 從零裝一套能用的 Redis理論講完落到手上。這部分我按裝、配、驗(yàn)三步走配置部分會把幾個(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)會出事。下面這幾項(xiàng)我每次部署都會過一遍# 網(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 會一直吃內(nèi)存直到被系統(tǒng)殺掉那時(shí)候就不是淘汰幾個(gè) key 的問題了而是整個(gè)實(shí)例掛掉。maxmemory-policy的選擇取決于你的數(shù)據(jù)性質(zhì)noeviction內(nèi)存滿了直接報(bào)錯(cuò)適合數(shù)據(jù)不能丟的場景。allkeys-lru所有 key 里淘汰最近最少使用的純緩存場景首選。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è)約定來保證它們不會被誤淘汰。4.3 連通性驗(yàn)證與基礎(chǔ)命令實(shí)測裝完之后別急著寫代碼先手工驗(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è)都有對應(yīng)的打法緩存用起來之后真正讓人睡不著覺的不是性能而是數(shù)據(jù)一致性和異常流量。所謂穿透、擊穿、雪崩這三個(gè)詞說的是三種不同的失效模式應(yīng)對手段也完全不同必須分清楚。5.1 三種失效模式的成因?qū)Ρ犬惓ｎ愋陀|發(fā)條件現(xiàn)象影響范圍緩存穿透查詢根本不存在的數(shù)據(jù)每次都打到數(shù)據(jù)庫可能被惡意利用緩存擊穿熱點(diǎn) key 過期瞬間大量請求同時(shí)打庫單個(gè)熱點(diǎn)緩存雪崩大量 key 同時(shí)過期或?qū)嵗礄C(jī)數(shù)據(jù)庫瞬間承壓全局性穿透的本質(zhì)是緩存里沒有數(shù)據(jù)庫里也沒有查詢永遠(yuǎn)落空緩存形同虛設(shè)。擊穿是緩存里本來有剛好過期了一瞬間所有請求涌向數(shù)據(jù)庫。雪崩則是更大范圍的集體失效。這三者的共同點(diǎn)是把數(shù)據(jù)庫當(dāng)成了兜底所以核心思路都是在緩存層就把請求擋住或者分流。5.2 穿透與擊穿的落地實(shí)現(xiàn)對付穿透最直接的辦法是緩存空值。查數(shù)據(jù)庫沒查到也往 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 瘋狂請求會往 Redis 里塞大量空值 key所以通常要配合布隆過濾器在入口先做一層攔截。布隆過濾器判斷一定不存在是準(zhǔn)確的判斷存在有誤判率剛好適合放在緩存前面。擊穿的解法是加互斥鎖保證同一時(shí)刻只有一個(gè)請求去回源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è)否則持有者崩了會死鎖。5.3 雪崩的預(yù)防與兜底策略雪崩的預(yù)防核心是打散過期時(shí)間。給 TTL 加一個(gè)隨機(jī)偏移量是最簡單有效的做法ttl 3600 random.randint(0, 600) redis.set(key, value, exttl)這樣即使批量預(yù)熱過期時(shí)間也會分散在十分鐘的窗口里不會同時(shí)失效。除了打散還要做幾層兜底本地緩存比如 Caffeine作為二級緩存擋第一波流量數(shù)據(jù)庫連接池限流避免被打死關(guān)鍵接口做熔斷降級返回兜底數(shù)據(jù)而不是直接報(bào)錯(cuò)。我的實(shí)際經(jīng)驗(yàn)有一次批量導(dǎo)入商品后統(tǒng)一預(yù)熱緩存所有 key 的 TTL 都是 7200 秒結(jié)果兩小時(shí)后整批同時(shí)失效數(shù)據(jù)庫 CPU 直接打滿。后來改成預(yù)熱時(shí)按7200 random(0, 1200)設(shè)置再沒出現(xiàn)過集體失效。5.4 雙寫一致性該怎么做緩存和數(shù)據(jù)庫同時(shí)寫一定有短暫不一致關(guān)鍵是控制窗口和最終一致。業(yè)界主流是 Cache Aside 模式讀的時(shí)候先讀緩存沒有再讀庫并回填寫的時(shí)候先更新數(shù)據(jù)庫再刪除緩存。為什么是刪緩存而不是更新緩存因?yàn)椴l(fā)更新時(shí)兩個(gè)請求的更新順序可能和寫庫順序不一致導(dǎo)致緩存里存了舊值。刪除操作更安全下次讀的時(shí)候自然回填最新值。但先寫庫再刪緩存仍有極小概率出問題讀請求在寫庫之后、刪緩存之前讀到舊值并回填。常用的補(bǔ)救是延遲雙刪——寫完庫刪一次隔幾百毫秒再刪一次。更徹底的方案是訂閱數(shù)據(jù)庫的 binlog異步刪除緩存把一致性保障從業(yè)務(wù)代碼里剝離出來。6. 線上出問題時(shí)我一般從這幾個(gè)命令開始查Redis 的問題看起來五花八門實(shí)際上集中在幾類內(nèi)存漲了、變慢了、連接不上了、數(shù)據(jù)不對了。每一類都有對應(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è)命令會掃描全庫并列出每種類型最大的 key。注意它會遍歷所有鍵在數(shù)據(jù)量大的實(shí)例上會明顯增加負(fù)載建議在從節(jié)點(diǎn)或者低峰期執(zhí)行。找到大 key 之后單個(gè) key 的內(nèi)存占用可以用MEMORY USAGE user:2001如果確認(rèn)是某個(gè)大 Hash 或者大 List 占了幾百兆刪除時(shí)千萬別用 DEL會阻塞主線程。改用UNLINK它在后臺線程異步釋放內(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è)閾值的命令會被記錄。SLOWLOG GET 返回最近的慢命令包含執(zhí)行時(shí)間、命令內(nèi)容、客戶端地址。常見的慢命令有KEYS *全庫掃描生產(chǎn)禁用、FLUSHALL清庫、大集合的SMEMBERS、大 ZSet 的ZRANGE全量取。這些都在主線程執(zhí)行一次就能把整個(gè)實(shí)例卡住。另一個(gè)隱蔽的原因是持久化。開著 AOF everysec 的情況下如果磁盤 IO 跟不上fsync 會阻塞寫入?？梢酝ㄟ^INFO persistence看aof_delayed_fsync這個(gè)指標(biāo)如果它一直增長說明磁盤扛不住了要么換 SSD要么改配置。6.3 連接與命中率類問題連接數(shù)打滿是很常見的線上故障先用這個(gè)看CLIENT LIST INFO clientsconnected_clients接近maxclients時(shí)新連接會被拒絕。原因通常是應(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é)查詢能減少對主線程的影響。最后分享一個(gè)我在實(shí)際運(yùn)維里養(yǎng)成的小習(xí)慣給每個(gè)業(yè)務(wù)線的 key 加上統(tǒng)一的命名前綴比如order:、user:、cfg:配合SCAN命令按前綴遍歷千萬別用 KEYS。這樣做的好處是排查時(shí)能快速圈定范圍做容量評估時(shí)也能按業(yè)務(wù)線統(tǒng)計(jì)。我一般是這么掃的redis-cli -a 密碼 --scan --pattern order:* | head -100另外新實(shí)例上線前我都會跑一輪壓測用 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è)對照系——是整體變慢了還是某類命令變慢了一眼就能判斷。沒有基線的排查基本靠猜有了基線排查效率完全是另一個(gè)層次。