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