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