1. Redis五大數(shù)據(jù)類型從入門到精通的核心基石如果你剛開始接觸Redis或者已經(jīng)用它做過一些簡單的緩存但總覺得對它的理解還浮在表面那今天這篇內(nèi)容就是為你準(zhǔn)備的。Redis之所以強大絕不僅僅是因為它快更在于它那五種設(shè)計精巧、功能各異的數(shù)據(jù)類型。很多人把Redis當(dāng)做一個簡單的“鍵值對”緩存來用這其實只發(fā)揮了它20%的功力。真正理解這五種類型就像拿到了打開Redis寶庫的五把鑰匙你會發(fā)現(xiàn)它能做的事情遠(yuǎn)超你的想象從實現(xiàn)一個復(fù)雜的社交網(wǎng)絡(luò)點贊系統(tǒng)到構(gòu)建一個高并發(fā)的秒殺隊列再到實時統(tǒng)計在線用戶都離不開對這些數(shù)據(jù)類型的靈活運用。我見過不少項目初期為了圖省事把所有數(shù)據(jù)都往String類型里塞用JSON一包了事。短期內(nèi)看似沒問題但隨著業(yè)務(wù)增長性能瓶頸和復(fù)雜度會指數(shù)級上升。比如要做一個文章排行榜用String存儲每篇文章的分?jǐn)?shù)每次更新和排序都需要全量操作效率極低。而如果一開始就選用Sorted Set這就是它原生支持、性能極高的場景。所以今天我們不只講命令怎么用更會深入探討每種類型的設(shè)計思想、適用場景以及那些我踩過坑后才明白的“最佳實踐”。無論你是正在準(zhǔn)備面試還是希望優(yōu)化現(xiàn)有系統(tǒng)相信這篇詳盡的梳理都能給你帶來實實在在的收獲。2. 核心類型深度解析與設(shè)計哲學(xué)2.1 String不止是字符串更是多功能工具箱String是Redis最基本的數(shù)據(jù)類型但千萬別被它的名字騙了。在Redis里一個String類型的值不僅可以是一個文本字符串也可以是數(shù)字整數(shù)或浮點數(shù)甚至是二進(jìn)制數(shù)據(jù)如圖片序列化后的字節(jié)流。其最大容量為512MB。核心設(shè)計思想String類型是Redis所有數(shù)據(jù)結(jié)構(gòu)的原子基礎(chǔ)。它的高效源于其底層實現(xiàn)的簡單性。在Redis 3.2版本之后字符串根據(jù)長度和內(nèi)容會采用不同的編碼方式如embstr,raw,int以最大限度地節(jié)省內(nèi)存。例如當(dāng)一個字符串值可以用64位有符號整數(shù)表示時它會直接被存儲為int編碼省去了復(fù)雜結(jié)構(gòu)的開銷。常用命令精講SET key value [EX seconds] [PX milliseconds] [NX|XX]這是最基礎(chǔ)的命令。EX和PX參數(shù)用于設(shè)置過期時間秒/毫秒這是實現(xiàn)緩存失效的基石。NX僅在鍵不存在時設(shè)置和XX僅在鍵存在時設(shè)置則是實現(xiàn)分布式鎖的關(guān)鍵。例如實現(xiàn)一個簡單的鎖SET lock:order123 unique_token NX PX 10000。GET key獲取值。如果鍵不存在返回nil。MSET/MGET key1 value1 [key2 value2 ...]批量設(shè)置/獲取多個鍵值對。這是一個非常重要的性能優(yōu)化點。在需要同時操作多個鍵時使用MGET比循環(huán)調(diào)用GET能減少大量的網(wǎng)絡(luò)往返時間RTT。INCR/DECR key和INCRBY/DECRBY key increment將鍵存儲的整數(shù)值原子性地增加或減少。這是實現(xiàn)計數(shù)器如文章閱讀量、用戶點贊數(shù)的完美選擇。其原子性保證了在高并發(fā)下計數(shù)的絕對準(zhǔn)確。SETRANGE key offset value和GETRANGE key start end對字符串的指定范圍進(jìn)行設(shè)置和獲取?？捎糜趯崿F(xiàn)一個簡單的位圖BitMap功能雖然Redis有專門的Bitmap類型基于String但了解這個命令有助于理解其靈活性。STRLEN key獲取字符串長度。注意SET命令的NX參數(shù)是實現(xiàn)分布式鎖的“紅鎖”Redlock算法之外最簡單、最常用的鎖實現(xiàn)方式通常稱為SETNX方式。但它并非完美需要考慮鎖的續(xù)期和釋放的原子性使用Lua腳本等問題。2.2 Hash化整為零的對象緩存利器Hash是一個鍵值對集合特別適合存儲對象。例如一個用戶信息userId: 1001可以有字段nameageemail等。核心設(shè)計思想Hash可以將一個對象的多個字段存儲在一個Redis鍵中既能像操作一個獨立對象那樣進(jìn)行存取HGETALL也能單獨操作某個字段HSET實現(xiàn)了存儲效率和操作靈活性的平衡。在數(shù)據(jù)量較小時它采用類似ziplist的緊湊編碼非常節(jié)省內(nèi)存當(dāng)字段數(shù)量或值超過閾值時會自動轉(zhuǎn)換為hashtable編碼以保證操作效率。常用命令精講HSET key field value [field value ...]設(shè)置哈希表中一個或多個字段的值。HGET key field獲取指定字段的值。HGETALL key獲取哈希表中所有字段和值。慎用此命令如果哈希表字段非常多比如幾千個這條命令會一次性返回大量數(shù)據(jù)可能阻塞Redis服務(wù)端并占用大量網(wǎng)絡(luò)帶寬。通常建議用HMGET指定需要的字段或使用HSCAN進(jìn)行漸進(jìn)式遍歷。HDEL key field1 [field2 ...]刪除一個或多個字段。HINCRBY key field increment為哈希表中的整數(shù)字段值增加指定增量。完美用于對象內(nèi)部的計數(shù)器如商品庫存HINCRBY product:1001 stock -1。HKEYS/HVALS key獲取所有字段名或所有值。HLEN key獲取字段數(shù)量。實操心得在緩存一個復(fù)雜的數(shù)據(jù)庫行時使用Hash比將整個對象序列化成JSON字符串存為String更有優(yōu)勢。首先你可以局部更新某個字段而無需讀寫整個對象。其次如果對象中某些字段很大但不常變化而某些字段很小但頻繁變化Hash可以讓你只操作變化的部分效率更高。但切記不要濫用HGETALL。2.3 List靈活的雙端隊列與消息流List是一個簡單的字符串列表按照插入順序排序。你可以在頭部左邊或尾部右邊添加元素。核心設(shè)計思想List的底層實現(xiàn)是quicklist3.2版本后它是ziplist和雙向鏈表的結(jié)合體在內(nèi)存效率和操作性能上取得了很好的平衡。它本質(zhì)上是一個雙端隊列Deque這使其成為實現(xiàn)多種模式的天然選擇。常用命令精講LPUSH/RPUSH key element [element ...]將一個或多個值插入到列表的頭部左邊/尾部右邊。LPOP/RPOP key移除并返回列表的第一個左邊/最后一個右邊元素。這是實現(xiàn)隊列和棧的關(guān)鍵。BLPOP/BRPOP key [key ...] timeoutLPOP/RPOP的阻塞版本。如果列表沒有元素命令會阻塞連接直到等待超時或有元素可彈出為止。這是實現(xiàn)簡單消息隊列如任務(wù)隊列的核心消費者端通過BLPOP等待任務(wù)實現(xiàn)了生產(chǎn)者和消費者的解耦。LRANGE key start stop獲取列表中指定范圍內(nèi)的元素。LRANGE key 0 -1可以獲取列表所有元素。LINDEX key index通過索引獲取元素。LLEN key獲取列表長度。應(yīng)用場景示例消息隊列生產(chǎn)者用LPUSH將任務(wù)加入task_queue多個消費者用BRPOP爭搶任務(wù)。確保每個任務(wù)只被一個消費者處理。最新文章列表在博客或新聞?wù)景l(fā)布新文章時用LPUSH插入到articles:latest列表用LRANGE articles:latest 0 9獲取最新的10篇文章。超出一定長度后可以用LTRIM修剪。記錄用戶操作流用戶最近的操作如瀏覽記錄可以用LPUSH記錄到一個列表并用LTRIM保持固定長度如最近50條。踩坑提醒List沒有原生的“已讀”或“確認(rèn)”機制。如果用BLPOP做消息隊列消息一旦被彈出如果消費者在處理過程中崩潰這條消息就永久丟失了。對于要求可靠消息傳遞的場景需要使用更專業(yè)的Stream類型Redis 5.0引入或者外部的消息中間件如RabbitMQ, Kafka。2.4 Set無序唯一集合與關(guān)系運算Set是字符串的無序集合其特點是元素唯一、不可重復(fù)并且支持豐富的集合運算交集、并集、差集。核心設(shè)計思想Set的底層實現(xiàn)可以是intset當(dāng)元素全是整數(shù)且數(shù)量較少時或hashtable。它的核心價值在于O(1)時間復(fù)雜度的成員查找和強大的集合運算能力。常用命令精講SADD key member [member ...]向集合添加一個或多個成員。SREM key member [member ...]移除集合中一個或多個成員。SISMEMBER key member判斷成員是否在集合中。這是最常用的命令之一效率極高。SMEMBERS key返回集合中的所有成員。和HGETALL一樣對大數(shù)據(jù)量集合要慎用推薦使用SSCAN。SCARD key獲取集合的成員數(shù)。SINTER key1 [key2 ...]/SUNION .../SDIFF ...計算多個集合的交集、并集、差集。SINTERSTORE destination key1 [key2 ...]計算交集并將結(jié)果存儲到新的destination集合中。SUNIONSTORE和SDIFFSTORE同理。這些*STORE命令非常有用因為它們將計算和存儲原子性地結(jié)合在一起。應(yīng)用場景示例標(biāo)簽系統(tǒng)給文章打標(biāo)簽每篇文章的標(biāo)簽存為一個集合tags:article:1001?？梢暂p松實現(xiàn)“查找具有某幾個標(biāo)簽的所有文章”求交集。共同好友/興趣將用戶的好友ID存為集合friends:userA。SINTER friends:userA friends:userB立刻得出共同好友。抽獎/隨機推薦SRANDMEMBER key [count]命令可以隨機返回一個或多個成員用于抽獎。SPOP key [count]則是隨機移除并返回確保不會重復(fù)中獎。數(shù)據(jù)去重對一批數(shù)據(jù)進(jìn)行SADD自動完成去重。2.5 Sorted Set有序唯一集合與排行榜引擎Sorted Set是Set的升級版它在保證成員唯一性的基礎(chǔ)上為每個成員關(guān)聯(lián)一個分?jǐn)?shù)score成員依據(jù)分?jǐn)?shù)進(jìn)行從小到大的排序。分?jǐn)?shù)可以重復(fù)但成員不能重復(fù)。核心設(shè)計思想Sorted Set是Redis數(shù)據(jù)類型中的“瑞士軍刀”功能極為強大。其底層使用ziplist元素少時和skiplist跳躍表結(jié)合hashtable的實現(xiàn)。跳躍表保證了按分?jǐn)?shù)范圍查詢的高效ZRANGEBYSCOREO(log N)哈希表保證了按成員查詢分?jǐn)?shù)或判斷存在性的高效O(1)。這種雙索引結(jié)構(gòu)使其能勝任多種復(fù)雜場景。常用命令精講ZADD key [NX|XX] [CH] [INCR] score member [score member ...]添加成員及其分?jǐn)?shù)到有序集合。NX/XX與SET命令類似。INCR表示對分?jǐn)?shù)進(jìn)行增量操作這是實現(xiàn)排行榜實時更新的關(guān)鍵。ZRANGE key start stop [WITHSCORES]按分?jǐn)?shù)升序返回指定排名區(qū)間內(nèi)的成員。ZREVRANGE為降序即從高到低。WITHSCORES選項會同時返回分?jǐn)?shù)。ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]返回分?jǐn)?shù)在[min, max]區(qū)間內(nèi)的成員。這是范圍查詢的利器。min和max可以用-inf和inf表示負(fù)無窮和正無窮。ZRANK key member/ZREVRANK key member返回成員在集合中的正序/逆序排名從0開始。ZSCORE key member返回成員的分?jǐn)?shù)。ZINCRBY key increment member為指定成員的分?jǐn)?shù)增加增量。這是排行榜應(yīng)用中最核心的命令例如用戶點贊ZINCRBY article:likes 1 articleId。ZREM key member [member ...]移除一個或多個成員。ZCOUNT key min max統(tǒng)計分?jǐn)?shù)在指定區(qū)間內(nèi)的成員數(shù)量。應(yīng)用場景示例排行榜這是最經(jīng)典的場景。游戲玩家積分榜、視頻熱度榜、銷售商品Top N等。通過ZINCRBY更新分?jǐn)?shù)用ZREVRANGE獲取前N名。帶權(quán)重的隊列將任務(wù)的執(zhí)行時間戳作為分?jǐn)?shù)成員是任務(wù)內(nèi)容。消費者用ZRANGEBYSCORE key -inf current_timestamp WITHSCORES LIMIT 0 1來獲取到期的任務(wù)實現(xiàn)延遲隊列。范圍查詢例如存儲學(xué)生的成績分?jǐn)?shù)為成績成員為學(xué)號可以快速找出所有成績在80-90分之間的學(xué)生ZRANGEBYSCORE scores 80 90。時間軸將時間戳作為分?jǐn)?shù)消息或事件作為成員可以構(gòu)建一個天然按時間排序的流。實操心得Sorted Set的分?jǐn)?shù)是雙精度浮點數(shù)可能存在精度問題。對于需要精確排序的場景如金融積分可以考慮將實際值乘以一個倍數(shù)如10000轉(zhuǎn)換為整數(shù)存儲。另外ZRANGE等命令的start和stop參數(shù)指的是排名索引而不是分?jǐn)?shù)值這一點新手容易混淆。3. 命令使用中的高級技巧與避坑指南3.1 管道Pipeline與事務(wù)Transaction的正確使用當(dāng)你需要連續(xù)執(zhí)行多個命令時網(wǎng)絡(luò)往返時間RTT會成為性能瓶頸。Redis管道可以將多個命令打包一次性發(fā)送極大地提升性能。管道使用示例偽代碼# 不使用管道 for user_id in user_ids: redis.get(f‘user:{user_id}‘) # 每次調(diào)用都有一次RTT # 使用管道 pipe redis.pipeline() for user_id in user_ids: pipe.get(f‘user:{user_id}‘) results pipe.execute() # 僅一次RTT事務(wù)MULTI/EXECRedis的事務(wù)并非關(guān)系型數(shù)據(jù)庫那種嚴(yán)格的ACID事務(wù)。它更像一個命令打包的批量執(zhí)行并保證在執(zhí)行過程中不會被其他命令打斷隔離性。在MULTI和EXEC之間的命令會被排隊EXEC時原子性執(zhí)行。但它沒有回滾機制。如果事務(wù)中的某條命令語法錯誤所有命令都不會執(zhí)行如果是運行時錯誤如對字符串執(zhí)行INCR只有出錯的命令失敗其他命令仍會執(zhí)行。WATCH命令用于實現(xiàn)樂觀鎖。WATCH一個或多個鍵如果在EXEC執(zhí)行前這些鍵被其他客戶端修改則當(dāng)前客戶端的事務(wù)將失敗。這是實現(xiàn)復(fù)雜原子操作如“檢查并設(shè)置”的關(guān)鍵。重要提示管道和事務(wù)可以結(jié)合使用pipeline(transactionTrue)但要注意在事務(wù)內(nèi)部無法看到管道中其他命令的執(zhí)行結(jié)果因為所有命令是在EXEC時一起執(zhí)行的。3.2 Lua腳本實現(xiàn)復(fù)雜原子操作的終極武器當(dāng)管道和事務(wù)都無法滿足復(fù)雜的原子邏輯時Lua腳本是最終的解決方案。Redis會單線程執(zhí)行整個Lua腳本期間不會執(zhí)行任何其他命令因此腳本內(nèi)的所有操作都是原子的。典型應(yīng)用實現(xiàn)一個安全的庫存扣減和高并發(fā)下的排行榜名次更新。-- 扣減庫存防止超賣 local key KEYS[1] -- 商品庫存鍵如 ‘inventory:item_001‘ local change tonumber(ARGV[1]) -- 要扣減的數(shù)量如 -1 local current redis.call(‘GET‘, key) if (not current) or (tonumber(current) change 0) then return 0 -- 庫存不存在或不足扣減失敗 else redis.call(‘INCRBY‘, key, change) return 1 -- 扣減成功 end在客戶端調(diào)用EVAL “上述腳本” 1 inventory:item_001 -1注意事項腳本不宜過長或過重執(zhí)行腳本會阻塞Redis單線程長時間運行的腳本會導(dǎo)致其他所有客戶端超時。務(wù)必保持腳本輕量。使用SCRIPT LOAD和EVALSHA對于常用腳本可以先加載到服務(wù)器緩存然后通過SHA1摘要來執(zhí)行避免每次傳輸腳本源碼。腳本中訪問的鍵名和參數(shù)應(yīng)通過KEYS和ARGV數(shù)組傳遞而不是硬編碼在腳本里這有利于集群模式下的正確路由。3.3 鍵空間通知與過期策略的深入理解Redis允許客戶端訂閱頻道以接收影響數(shù)據(jù)集的某些事件。最有用的是鍵過期事件__keyevent0__:expired和鍵空間事件如del,set等。應(yīng)用場景實現(xiàn)一個延遲任務(wù)系統(tǒng)。將任務(wù)信息存入一個String鍵并為其設(shè)置過期時間如5分鐘后。訂閱過期事件當(dāng)鍵過期時事件處理器會收到通知從而觸發(fā)任務(wù)的執(zhí)行。這比用Sorted Set輪詢檢查更節(jié)省資源。但是這里有巨坑可靠性問題鍵空間通知是“盡力而為”的。如果Redis服務(wù)器在鍵過期時正好崩潰或者發(fā)布事件時客戶端斷開連接這個事件可能會丟失。性能開銷開啟鍵空間通知通過配置notify-keyspace-events Ex會對Redis性能有輕微影響。過期事件的延遲Redis的過期鍵刪除是惰性刪除訪問時檢查加定期刪除。這意味著即使鍵已到過期時間也可能不會立即產(chǎn)生過期事件會有一定的延遲取決于hz配置。因此對于要求高可靠性的延遲任務(wù)建議仍使用Sorted Set或?qū)I(yè)的延遲隊列中間件。3.4 內(nèi)存優(yōu)化與Big Key排查Redis是內(nèi)存數(shù)據(jù)庫內(nèi)存就是最寶貴的資源。不當(dāng)?shù)氖褂脮a(chǎn)生“Big Key”大鍵導(dǎo)致內(nèi)存不均、操作阻塞、集群數(shù)據(jù)傾斜等問題。Big Key的定義String類型值 10KB非String類型Hash,List,Set,Sorted Set元素數(shù)量 5000 或 總價值大小 10MB排查Big Key的方法使用redis-cli --bigkeys命令這是一個掃描工具可以快速找出每種數(shù)據(jù)類型中最大的鍵。但它在生產(chǎn)環(huán)境掃描時可能會對性能產(chǎn)生影響。使用MEMORY USAGE key命令精確計算某個鍵及其值所占用的內(nèi)存字節(jié)數(shù)。使用SCAN命令編寫腳本漸進(jìn)式分析最安全、對生產(chǎn)影響最小的方法。優(yōu)化策略拆分Big Key將一個包含百萬字段的Hash拆分成多個小的Hash例如通過哈希取模user:info:{userId % 100}。使用適合的數(shù)據(jù)類型比如存儲大量獨立且需要過期時間的鍵值對用String存儲對象屬性用Hash需要集合運算用Set。啟用壓縮對于String類型的值如果主要是文本可以考慮在客戶端進(jìn)行壓縮如gzip后再存儲但會增加CPU開銷。設(shè)置合理的過期時間給緩存數(shù)據(jù)設(shè)置TTL是防止數(shù)據(jù)無限增長最基本、最有效的手段。4. 數(shù)據(jù)類型選型決策與實戰(zhàn)場景對照理解了每個類型的特性后如何在實戰(zhàn)中做出正確選擇下面這個表格總結(jié)了核心場景與選型建議并附上了關(guān)鍵考量點。場景需求首選數(shù)據(jù)類型備選/替代方案關(guān)鍵考量點與注意事項簡單緩存如會話、驗證碼String-利用EX/PX設(shè)置過期時間。值較大時注意網(wǎng)絡(luò)傳輸開銷。對象緩存如用戶信息、商品詳情HashString (存儲序列化JSON)Hash優(yōu)勢可局部更新字段內(nèi)存效率可能更高小對象。String優(yōu)勢序列化后整體存取簡單兼容性廣。若對象字段頻繁全量讀寫兩者差異不大。計數(shù)器閱讀量、點贊數(shù)String(INCR)Hash (HINCRBY)String更簡單直接。如果計數(shù)器是對象的一部分用Hash的HINCRBY更合適。分布式鎖String(SET with NX PX)-需配合唯一值、Lua腳本實現(xiàn)原子解鎖或考慮更復(fù)雜的Redlock算法。消息隊列/任務(wù)隊列List(BLPOP/BRPOP)Stream(Redis 5.0)List簡單快速但消息不可重復(fù)消費、無確認(rèn)機制。Stream功能完整消費者組、消息確認(rèn)、回溯適用于需要可靠消息的場景。最新N條記錄時間線、動態(tài)List(LPUSH LTRIM)Sorted Set(分?jǐn)?shù)為時間戳)List實現(xiàn)簡單固定長度效率高。Sorted Set可按時間范圍查詢更靈活但內(nèi)存開銷稍大。標(biāo)簽系統(tǒng)、共同好友Set-利用SADD,SISMEMBER,SINTER等集合運算效率極高。大數(shù)據(jù)量時避免SMEMBERS。抽獎、隨機推薦Set(SRANDMEMBER/SPOP)-SRANDMEMBER不刪除元素可重復(fù)抽獎SPOP刪除元素確保唯一性。排行榜/延時隊列Sorted Set-排行榜分?jǐn)?shù)為排序依據(jù)ZINCRBY更新ZREVRANGE獲取Top N。延時隊列分?jǐn)?shù)為執(zhí)行時間戳消費者用ZRANGEBYSCORE輪詢到期任務(wù)。大數(shù)據(jù)去重如爬蟲URL去重SetBitmap(極端省內(nèi)存)如果元素是連續(xù)的整數(shù)或可以映射為整數(shù)Bitmap基于String可以極大地節(jié)省內(nèi)存億級數(shù)據(jù)僅需約12MB。否則用Set。位操作用戶簽到、特征標(biāo)志String(BitMap)-使用SETBIT,GETBIT,BITCOUNT,BITOP等命令。非常節(jié)省空間適合布爾型、狀態(tài)型數(shù)據(jù)的大規(guī)模存儲與統(tǒng)計。發(fā)布/訂閱簡單消息通知Pub/SubStream, List (輪詢)Redis原生Pub/Sub無消息持久化客戶端斷開則消息丟失。Stream或基于List的輪詢模式更可靠。選型心法總結(jié)先問場景再選類型不要手里拿著錘子String看什么都像釘子。明確你的核心操作是什么是取最新是排序是判斷存在還是集合運算?？紤]數(shù)據(jù)規(guī)模小數(shù)據(jù)量下各類型差異不大但數(shù)據(jù)量一旦上來選錯類型的代價巨大。提前預(yù)估數(shù)據(jù)增長。原子性需求需要多個操作原子執(zhí)行時優(yōu)先考慮原生命令如INCR、管道事務(wù)或Lua腳本。內(nèi)存與性能的權(quán)衡ziplist、intset等緊湊編碼在數(shù)據(jù)量小時非常省內(nèi)存但超過閾值后性能會變化。了解這些內(nèi)部編碼機制有助于深度優(yōu)化。未來擴展性當(dāng)前簡單的String緩存未來是否需要支持局部更新如果是或許一開始就該用Hash。5. 性能監(jiān)控、問題排查與線上運維要點5.1 關(guān)鍵監(jiān)控指標(biāo)與健康檢查要讓Redis穩(wěn)定運行必須關(guān)注以下幾個核心指標(biāo)內(nèi)存使用率(used_memory,used_memory_rss)這是生命線。通過INFO memory命令查看。確保used_memory不超過maxmemory配置如果設(shè)置了的話。used_memory_rss是操作系統(tǒng)分配給Redis的物理內(nèi)存通常比used_memory大如果大得過多比如超過1.5倍可能表示內(nèi)存碎片嚴(yán)重。連接數(shù)(connected_clients)通過INFO clients查看。連接數(shù)異常增長可能意味著客戶端連接未正確關(guān)閉或有連接池泄漏。命令耗時使用SLOWLOG GET查看慢查詢?nèi)罩?。Redis默認(rèn)記錄超過10毫秒的命令這個閾值可以通過slowlog-log-slower-than配置。頻繁出現(xiàn)的慢查詢通常是Big Key操作或復(fù)雜O(N)命令如KEYS *,HGETALLon big hash,SMEMBERSon big set導(dǎo)致的。命中率(keyspace_hits,keyspace_misses)對于緩存場景至關(guān)重要。通過INFO stats查看。命中率 hits / (hits misses)。過低的命中率如低于90%意味著緩存效果不佳需要檢查緩存鍵設(shè)計或淘汰策略。網(wǎng)絡(luò)流量(total_net_input_bytes,total_net_output_bytes)監(jiān)控進(jìn)出流量異常突增可能意味著有大量數(shù)據(jù)寫入或讀取或者是受到了攻擊。5.2 典型問題排查流程問題一客戶端報錯(error) OOM command not allowed when used memory ‘maxmemory‘原因內(nèi)存使用達(dá)到上限且配置的淘汰策略maxmemory-policy無法釋放足夠內(nèi)存或根本沒有設(shè)置淘汰策略默認(rèn)noeviction。排查檢查INFO memory確認(rèn)used_memory和maxmemory。檢查maxmemory-policy配置。生產(chǎn)環(huán)境推薦使用allkeys-lru或volatile-lru。使用redis-cli --bigkeys或MEMORY USAGE命令查找是否有Big Key。檢查是否有大量數(shù)據(jù)未設(shè)置過期時間。問題二客戶端請求超時Redis CPU占用率飆升原因很可能有慢查詢或阻塞命令正在執(zhí)行。排查立刻執(zhí)行SLOWLOG GET 10查看最近的慢查詢。執(zhí)行INFO commandstats查看各種命令的調(diào)用次數(shù)和總耗時找到可疑命令。檢查是否有使用KEYS *模式匹配的命令在生產(chǎn)環(huán)境運行。永遠(yuǎn)不要在生產(chǎn)環(huán)境使用KEYS命令應(yīng)該用SCAN替代。檢查是否在執(zhí)行大型集合的SINTER/SUNION等計算密集型命令。問題三主從復(fù)制中斷master_link_status:down原因網(wǎng)絡(luò)問題、主庫內(nèi)存不足導(dǎo)致持久化失敗、或從庫處理能力跟不上主庫的寫入速度。排查檢查主從網(wǎng)絡(luò)連通性。查看主庫日志檢查bgsaveRDB持久化是否失敗。如果主庫內(nèi)存太大fork子進(jìn)程進(jìn)行持久化時可能會因內(nèi)存不足而失敗。檢查從庫日志查看復(fù)制緩沖區(qū)是否溢出?？紤]使用更快的磁盤、增加從庫緩沖區(qū)大小client-output-buffer-limit或優(yōu)化主庫寫入流量。5.3 配置優(yōu)化建議設(shè)置maxmemory和淘汰策略一定要設(shè)置。根據(jù)業(yè)務(wù)容忍度選擇策略如allkeys-lru所有鍵參與LRU淘汰或volatile-lru只淘汰有過期時間的鍵。禁用危險命令在生產(chǎn)環(huán)境通過rename-command配置將KEYS、FLUSHALL、FLUSHDB等命令重命名為一個隨機字符串或直接禁用防止誤操作。rename-command KEYS “” rename-command FLUSHALL “” rename-command FLUSHDB “” rename-command CONFIG “”調(diào)整持久化策略根據(jù)數(shù)據(jù)重要性選擇RDB、AOF或混合模式。AOF的appendfsync選項everysec在性能和數(shù)據(jù)安全間取得了較好平衡是默認(rèn)推薦值。合理設(shè)置tcp-keepalive和timeouttcp-keepalive保持TCP連接活性timeout設(shè)置客戶端空閑超時斷開防止連接數(shù)堆積。使用連接池在客戶端使用連接池避免頻繁創(chuàng)建和銷毀連接的開銷。掌握Redis的五大數(shù)據(jù)類型及其命令只是邁出了成為Redis高手的第一步。真正的功力體現(xiàn)在如何根據(jù)千變?nèi)f化的業(yè)務(wù)場景將這些基礎(chǔ)組件像樂高積木一樣靈活組合并配以恰當(dāng)?shù)谋O(jiān)控、調(diào)優(yōu)和問題排查手段。從用一個SET NX PX實現(xiàn)分布式鎖到用Sorted Set構(gòu)建一個實時競技排行榜再到用List和Pub/Sub搭建一個輕量消息系統(tǒng)每一次實踐都會加深你對“數(shù)據(jù)結(jié)構(gòu)即工具”的理解。記住沒有最好的數(shù)據(jù)類型只有最適合當(dāng)前場景的選擇。多思考、多測試、多總結(jié)你就能讓Redis在你的系統(tǒng)中發(fā)揮出最大的威力。