據(jù)類型實戰(zhàn)詳解：原理、場景選型與排障)
1. 為什么先把數(shù)據(jù)類型想清楚比背命令更重要做后端開發(fā)的幾乎沒有人能繞開 Redis。緩存、分布式鎖、排行榜、消息隊列、計數(shù)統(tǒng)計樣樣都有它的身影。但我在面試和帶團隊時發(fā)現(xiàn)一個很有意思的現(xiàn)象很多人提到 Redis能熟練說出 String、Hash、List、Set、ZSet 這五種數(shù)據(jù)類型可一旦落到具體業(yè)務場景選型和命令就亂了套——有人用 String 存了一個巨大的 JSON有人用 List 做高可靠消息隊列還有人把排行榜硬生生做成了在數(shù)據(jù)庫里 ORDER BY。這些問題的根源不是命令不熟而是對數(shù)據(jù)類型的底層定位和適用邊界缺乏直覺。這篇內(nèi)容我準備把這五種數(shù)據(jù)類型徹底拆開講透。不光是SADD 是加集合、ZADD 是加有序集合這種流于表面的操作符背誦而是每個類型解決什么問題、底層結(jié)構(gòu)如何影響性能、什么場景選它會自找麻煩、什么樣的 key 設計才算合理。你如果是剛接觸 Redis 的新手這篇文章可以作為完整的入門路線你如果已經(jīng)用 Redis 寫過業(yè)務代碼我相信里面關(guān)于大 key、編碼轉(zhuǎn)換、原子性誤區(qū)和排障經(jīng)驗的段落也能幫你補上一些平時沒太注意的盲區(qū)。我自己的習慣是拿到一個業(yè)務需求先不動手寫命令先畫數(shù)據(jù)模型再對著五種類型做映射。這一步做完整個方案基本就成型了。接下來我們把每個類型挨個過一遍從原理講到實戰(zhàn)再講講這些年我踩過的坑。2. String最基礎但最容易被用錯的類型2.1 String 的底層結(jié)構(gòu)和三種編碼形態(tài)String 是 Redis 最基礎的數(shù)據(jù)類型一個 key 對應一個 valuevalue 最大能到 512MB。很多人以為 String 就是存字符串實際它的底層遠不止字符串這么簡單。Redis 為了在不同場景下做出性能最優(yōu)的選擇給 String 設計了三種編碼方式編碼觸發(fā)條件底層結(jié)構(gòu)intvalue 是整數(shù)且能用 long 表示直接存整數(shù)值不自帶 redisObject 的 sds 頭部embstrvalue 長度小于等于 44 字節(jié)一次性分配連續(xù)的 redisObject 和 sds 內(nèi)存rawvalue 長度大于 44 字節(jié)分兩次分配redisObject 和 sds 獨立內(nèi)存這個 44 字節(jié)的臨界值很多資料提過但沒講透。它其實是 Redis 內(nèi)存分配策略和緩存行對齊共同作用的結(jié)果jemallocRedis 默認內(nèi)存分配器在 64 字節(jié)以下會走 size class 分配redisObject 結(jié)構(gòu)本身占 16 字節(jié)SDS 頭部在 Redis 3.2 之后占 3 字節(jié)再加上結(jié)束符算下來能留給數(shù)據(jù)的空間就是 44 字節(jié)。超過這個值embstr 的連續(xù)內(nèi)存一次分配優(yōu)勢就保不住了轉(zhuǎn)為 raw 后讀寫需要兩次內(nèi)存分配性能會略降。我在實際項目中很少直接干預編碼切換但我會用 OBJECT ENCODING 命令檢查線上 key 的編碼狀態(tài)。以前排查過一個詭異問題某個存儲手機號的 String key平時寫入都正常偶爾一次寫入性能暴跌后來發(fā)現(xiàn)是因為某個手機號后面多了一個空格長度從 11 位變成 12 位編碼從 embstr 跳到 raw觸發(fā)了一次額外的內(nèi)存分配。這種問題很難從業(yè)務代碼層面察覺但只要你理解編碼機制排查方向就會清晰很多。2.2 單值緩存以外String 的經(jīng)典命令組合String 最常見的用法當然是緩存單值比如用戶昵稱、商品庫存、接口返回的 JSON 片段。但 String 的價值不止于 SET/GET 這一對我給你列幾個我日常最高頻的命令組合每一個都有明確的場景指向。SETNX 是分布式鎖的最小實現(xiàn)。它的全稱是 SET if Not eXists只有在 key 不存在時才設置成功。配合 EXPIRE 設置過期時間就成了一版最簡分布式鎖 SETNX lock:order:1001 1 (integer) 1 EXPIRE lock:order:1001 30 (integer) 1當然真實生產(chǎn)環(huán)境里建議直接用 SET 命令帶 NX 和 EX 兩個參數(shù)一次性完成 SET lock:order:1001 1 NX EX 30 OK為什么推薦用 SET 帶 NX EX 而不是先 SETNX 再 EXPIRE因為兩條命令組合不具備原子性中間如果 Redis 崩潰或網(wǎng)絡抖動鎖就沒有過期時間了直接變成死鎖。用一條 SET 命令就能把加鎖和設置過期合并成一個原子操作這個細節(jié)我在代碼評審里幾乎每次都會提。MSET/MGET 是批量讀寫的利器。一次網(wǎng)絡往返完成多個 key 的讀寫在高并發(fā)場景下能顯著降低 RTT 的影響 MSET user:1001:name zhangsan user:1001:age 28 OK MGET user:1001:name user:1001:age 1) zhangsan 2) 28這里要注意MSET/MGET 雖然是批量操作但它并不是原子的——中間某個 key 寫失敗不會回滾其他 key。如果你需要要么全成功要么全失敗的事務語義得用 MULTI/EXEC 包裹但那樣又會帶來性能開銷所以常規(guī)緩存場景用 MSET/MGET 就夠了別指望它承載事務。2.3 為什么容器類型嵌套的 String 不一定安全Redis 的 Hash、List、Set、ZSet 里存的值本質(zhì)上也都是 String。于是有一種常見的錯誤認知既然容器里的元素是 String那我是不是可以用同樣的 String 命令去處理它們我可以直接說結(jié)論不行。容器內(nèi)部的 String 不具備獨立 key 的性質(zhì)它沒有自己的 TTL、沒有自己的過期時間、不能被單獨設置 EXPIRE也不能被單獨設置訪問權(quán)限。為什么這樣說因為 Redis 的過期機制是以 key 為單位的。你給一個 Hash 設置了 EXPIRE整個 Hash 到點會被刪除但 Hash 里某個 field 想要單獨維持更長時間的存留普通版本 Redis 根本做不到。Redis 7.4 開始支持部分 Hash field 的過期特性但在 7.4 之前所有給某個 field 單獨設 TTL的方案都是自己用另外的 key 去模擬。這個特性我在設計緩存方案時吃過虧。當時給一個用戶維度的 Hash 設置了 1 小時過期其中某個 field 存的是特殊標記需要保留 24 小時。我天真地以為可以單獨給那個 field 續(xù)期后來發(fā)現(xiàn)根本沒這個命令最后只能拆出一個獨立的 String key 來存這個標記。這個教訓讓我養(yǎng)成一個習慣凡是生命周期不一致的數(shù)據(jù)千萬別塞進同一個容器 key要么拆 key要么接受整體過期的約束。2.4 String 適合做的幾類小任務除了緩存和鎖String 還有幾個被低估的用法。第一類是計數(shù)器。INCR 和 DECR 是原子操作天然適合做訪問量、點贊數(shù)、庫存扣減。很多新人會用先 GET 再 SET來實現(xiàn)計數(shù)這在并發(fā)下會丟數(shù)正確姿勢永遠是直接 INCR/DECR讓 Redis 保證原子性。第二類是 Session 共享。分布式系統(tǒng)里用戶登錄狀態(tài)通常放在 Redis用 SETEX 設置會話 ID 和過期時間用戶每次請求都去 GET 一下。這個場景的關(guān)鍵是過期時間的粒度要匹配業(yè)務純接口鑒權(quán)可以設短一點比如 30 分鐘購物車這種需要長時間保留的狀態(tài)可以設長一些比如 7 天。第三類是分布式 ID 生成。INCR 一個全局 key就能拿到一個趨勢遞增的 ID。但要注意這個 ID 不能拿去當數(shù)據(jù)庫主鍵因為 Redis 重啟后 INCR 會從持久化后的值繼續(xù)如果持久化策略是 RDB 快照重啟后可能丟掉最近幾次自增記錄會造成主鍵沖突。所以分布式 ID 建議用專門的雪花算法或者在數(shù)據(jù)庫層用號段模式Redis 的 INCR 只適合對順序不敏感的場景。3. Hash對象緩存和等值查詢的性價比之王3.1 為什么對象型數(shù)據(jù)我首選 HashString 類型存對象時有兩種常見但又各有局限的做法一是把整個對象 JSON 序列化后塞進一個 key查詢時整體反序列化哪怕只想取其中一個字段也要全量解析二是按對象屬性拆成多個 key多出大量 key 的維護成本。Hash 的思路則完全不同——它天生就是一個小對象容器一個 key 下面可以掛多個 field-value 對結(jié)構(gòu)上和對象幾乎一一對應 HSET user:1001 name zhangsan age 28 city hangzhou (integer) 3 HGET user:1001 name zhangsan HGETALL user:1001 1) name 2) zhangsan 3) age 4) 28 5) city 6) hangzhou當業(yè)務方接口只返回用戶昵稱時HGET 一次到位當丟給前端做詳情展示時HGETALL 一把梭哈非常靈活。和 String 方案相比Hash 最大的三個優(yōu)勢是單字段讀寫、批量字段讀寫、字段級邏輯控制。這些優(yōu)勢在緩存化改造中特別明顯——把老的 MySQL 行記錄映射成一個 Hash 時字段名和列名幾乎可以一一對齊改造成本極低。我用 Hash 做對象緩存的習慣是key 保持高扇出、可枚舉field 用穩(wěn)定的業(yè)務標識。典型 key 設計是 user:1001、order:20231001 這種后面跟業(yè)務 ID。如果業(yè)務 ID 本身可能被重建或變化那就盡量避免把所有邏輯都掛在同一個 key 上因為 Hash 的過期是整體過期的一個 field 想單獨續(xù)期會變得很別扭。這一點在緩存與數(shù)據(jù)庫一致性方案里經(jīng)常被忽略——很多人以為 Hash 可以做字段級過期實際上官方在普通 Hash 上并不提供這個能力除非你用的是 7.4 以上版本且啟用了 hash field expiration 特性。3.2 HGETALL 的不當使用與漸進式遍歷HGETALL 是個好命令但也很容易成為性能陷阱。當一個 Hash 里有幾千個 field 時HGETALL 會一條命令把所有 KV 全部拉回來這個 O(N) 操作在大 key 場景下比預想中更危險。我之前接手過一個跑了兩年的老項目一個商品信息 Hash 因為運營不斷往里面加自定義屬性慢慢膨脹到幾萬個 field高峰期一個 HGETALL 就能把帶寬和 GC 拉爆。排查時我先執(zhí)行 HLEN 發(fā)現(xiàn) field 數(shù)量已經(jīng)上萬然后立刻讓線上讀按需取字段只讀接口用多個 HGET 精準命中管理后臺才放行 HGETALL才把慢查詢壓下去。如果確實要全量讀或做遍歷推薦漸進式命令 HSCAN它和 SCAN 的思路一致可以分多次迭代取回全部 field-value每次返回一個游標下次接著遍歷。HSCAN 返回的游標并不是簡單的偏移量而是哈希桶的索引位置所以哪怕遍歷過程中有數(shù)據(jù)變化也能保證不錯的起始點位 HSCAN user:1001 0 MATCH name* 1) 0 2) 1) name 2) zhangsan這種做法適合做數(shù)據(jù)統(tǒng)計、批量遷移或后臺任務掃描但不適合高頻線上讀鏈路。線上讀服務永遠是精確命中離散取字段而不是拿著大鐵鍬去挖金礦。3.3 Hash 的內(nèi)存結(jié)構(gòu)與編碼轉(zhuǎn)換細節(jié)Hash 在元素較少時使用 ziplist緊湊列表編碼當元素數(shù)量超過 hash-max-ziplist-entries 或單個 field 的 value 長度超過 hash-max-ziplist-value 時會轉(zhuǎn)換為 hashtable 編碼。這個轉(zhuǎn)換是透明的但會影響內(nèi)存占用和操作復雜度。我做過一次內(nèi)存實測100 萬個 field 的小值 Hash在 ziplist 編碼下內(nèi)存占用比 hashtable 編碼大概省 30% 到 40%讀取耗時差別也在毫秒級內(nèi)真正的差異主要發(fā)生在寫入時的 rehash 和內(nèi)存碎片上。實際操作中我會在配置里關(guān)注 hash-max-ziplist-entries 和 hash-max-ziplist-value 兩個參數(shù)。如果業(yè)務明確知道某個 Hash 的 field 數(shù)量上限很低可以把閾值調(diào)高一點盡量保持 ziplist 編碼以節(jié)省內(nèi)存但也要小心ziplist 編碼下的更新操作是 O(N)如果頻繁修改中間位置的數(shù)據(jù)性能反而會下降。我的經(jīng)驗是一個 Hash 的 field 數(shù)控制在幾百到幾千、單個 value 控制在幾百字節(jié)內(nèi)是比較舒服的范圍超過這個量級就要考慮是不是數(shù)據(jù)結(jié)構(gòu)選錯了。3.4 用 Hash 做短鏈映射、字典表與多指標計數(shù)Hash 的應用場景里我最常用的是三類。第一是短鏈映射。短鏈服務通常需要一個短碼到完整 URL的映射直接用 Hash 存一個短鏈庫就是一個大 Hash訪問時 HGET 一下生成時 HSET 一下天然支持批量導入。第二是字典表。電商后臺會有一堆枚舉值狀態(tài)碼、城市碼、類目碼這種配置型數(shù)據(jù)按業(yè)務模塊拆成多個 Hash例如 config:city 存所有城市編碼和名稱config:category 存類目樹。后臺修改配置時 HSET 某個字段不影響到其他字段也不用為每個配置單獨建一個 String keykey 數(shù)量大幅下降。第三是多指標計數(shù)。比如記錄某篇文章的點贊、收藏、評論數(shù)用 Hash 的 field 分別保存 post:1001:stat 的 like、fav、comment每次更新用 HINCRBY 原子累加讀取時 HMGET 一次拿多個指標不用為每個指標單獨建 key。這一招在實時數(shù)據(jù)大屏、運營看板里非常常見邏輯簡單但非常穩(wěn)。Hash 還有一個被低估的優(yōu)勢是批量寫入和批量讀取的對稱性。業(yè)務方要批量初始化一批對象時可以先用 HM?SE T一次寫入多個 field再在查詢時用 HMGET 一次性取多個 field。這種對稱設計在接口層很容易和前端表單字段對齊我寫緩存服務時特別偏愛這種對齊感——數(shù)據(jù)模型和接口模型一致代碼可讀性極高排查問題時一眼就能看清數(shù)據(jù)流向。4. List時間線、隊列與操作記錄的一把好手4.1 List 在 Redis 里的真實定位很多人一提到 List 就下意識說消息隊列這個印象不奇怪LPUSH 加 BRPOP 的組合確實可以做出一個簡單的隊列。但 List 在 Redis 五大類型里其實更偏線性結(jié)構(gòu)的存在它既是棧又是隊列既可以左進右出也可以左進左出完全取決于你怎么用。而它真正的實力在于順序性、長度控制和時間窗口記錄。List 的內(nèi)部存儲是一個雙向鏈表結(jié)構(gòu)所以頭尾插入刪除都是 O(1)但中間位置的隨機訪問則是 O(N)。Redis 的 List 在早期實現(xiàn)里直接用 linkedlist后來為了節(jié)省內(nèi)存又引入了 quicklist一種以 ziplist 為節(jié)點的雙向鏈表。我自己的理解是List 適合所有按時間順序追加、按批次消費的場景不適合高頻隨機查找。如果你要按索引下標取值比如取第 1000 個元素List 會慢到你想罵人這時候應該考慮用其他結(jié)構(gòu)而不是硬扛。4.2 LPUSH 加 LPOP / RPOP從隊列到棧的完整組合List 的命令很多核心就幾組。先看最常用的隊列語義 LPUSH task:queue job1 job2 job3 (integer) 3 RPOP task:queue job1 RPOP task:queue job2LPUSH 從左側(cè)寫入RPOP 從右側(cè)彈出先進先出這就是一個標準 FIFO 隊列。反過來LPUSH 加 LPOP 就是 LIFO 棧。如果想讓消費端在隊列為空時阻塞等待可以用 BRPOP這樣消費端不會高頻空轉(zhuǎn)輪詢能大幅降低無謂的 Redis 訪問壓力 BRPOP task:queue 5 1) task:queue 2) job3這個 5 表示阻塞 5 秒超時返回空。我在做任務調(diào)度時經(jīng)常用 BRPOP 配合超時時間消費線程掛在那里隊列一來就立刻被喚醒隊列空閑時也不會反復產(chǎn)生請求。有一個值得注意的點BRPOP 返回的是key 和 value兩部分因為你可能同時阻塞監(jiān)聽多個 key所以返回值里第一項是哪個 key 有數(shù)據(jù)第二項才是具體數(shù)據(jù)代碼里別取錯。4.3 用 List 做時間線和操作記錄LTRIM 的妙用List 的另一個高頻場景是最新動態(tài)和操作記錄。比如用戶的最近瀏覽記錄、系統(tǒng)的最近告警、文章的最新評論都有同一個共性只關(guān)心最新的 N 條歷史數(shù)據(jù)要么歸檔要么丟棄。實現(xiàn)思路很經(jīng)典 LPUSH user:1001:recent_posts post:9001 post:9002 post:9003 (integer) 3 LTRIM user:1001:recent_posts 0 2 OK LRANGE user:1001:recent_posts 0 -1 1) post:9003 2) post:9002 3) post:9001LPUSH 之后立刻 LTRIM 只保留前 N 條就構(gòu)成了一個容量固定的滑動窗口。你在微博、抖音時間線里看到的那種只保留最近一屏的列表底層很多就是這種思路。LTRIM 是 Range 保持的精髓它把超出窗口的內(nèi)容一次性剪掉不寫代碼、不跑定時任務一條命令就把 List 的容量控制住了。這里有個坑我必須多提一次LRANGE 返回的順序是從左到右。你 LPUSH 進去的數(shù)據(jù)在左側(cè)所以 LRANGE 0 -1 返回的第一條是最新寫入的。很多新人在這一點上栽過跟頭——他們以為 List 和數(shù)據(jù)庫查詢結(jié)果一樣順序按插入時間正序結(jié)果一測發(fā)現(xiàn)最新的在最前面日志里和預想不符排查半天。我建議寫代碼前先在命令行里手動 push 三條數(shù)據(jù)感受一下順序再進代碼寫邏輯別靠想象寫。4.4 List 作為消息隊列的痛點與替代方案雖然 LPUSH 加 BRPOP 能做隊列但如果你想用 List 在生產(chǎn)環(huán)境做重邏輯的消息隊列我勸你先想清楚幾個限制。消息丟失風險。BRPOP 彈出并返回數(shù)據(jù)后如果消費端在處理消息時崩潰這條消息就再也取不回來了。相比之下專業(yè)的消息隊列比如 RabbitMQ、Kafka 都有消費確認機制Redis Stream 則提供了消費者組和 PEL待處理條目列表來保證消息可追蹤。消息積壓時內(nèi)存膨脹。List 是一個純內(nèi)存結(jié)構(gòu)消息堆積多了Redis 內(nèi)存直接開始報警。消息隊列有磁盤緩沖能力但 Redis List 沒有。如果消息量預估很大要么考慮 Stream要么考慮外部的消息隊列中間件。重復消費問題。List 消費端拿走了消息消息就沒了所以也不存在重復消費和冪等設計的余地。如果你需要的是每個消息被多個消費者各自處理一次List 根本實現(xiàn)不了這是 Stream 的消費者組才有的能力。我對 List 做隊列的態(tài)度很簡單適合輕量級任務、低頻打點、單消費者場景不適合多消費者、高可靠、大量積壓的場景。后者的合理選擇是 Redis Stream如果連 Stream 都滿足不了可靠性要求那就直接用專業(yè)消息隊列別硬湊。5. Set標簽、去重與隨機抽樣的標準答案5.1 Set 的底層與去重邏輯Set 是一個無序、不重復的集合。它的底層實現(xiàn)有兩種編碼元素全是整數(shù)且數(shù)量少時用 intset整數(shù)集合元素是字符串或數(shù)量較大時用 hashtable。無論哪種編碼Set 都能保證添加重復元素時靜默忽略、不重復存儲。這一條命令實測就能證明 SADD tag:1001 java redis java (integer) 2 SMEMBERS tag:1001 1) java 2) redisSADD 返回 2說明第二個 java 被忽略了。這個去重能力是天然的不需要你在業(yè)務代碼里維護一個曾見過的清單。我在做去重邏輯時最省事的方案就是直接用一個 Set 的 key 存儲所有已處理的 ID每次新數(shù)據(jù)進來用 SISMEMBER 或 SADD 來判斷。SISMEMBER 返回 1 說明存在返回 0 說明不存在如果你想把判斷加加入合成一步那就看 SADD 的返回值——返回 1 說明添加成功原本不存在返回 0 說明原本就存在加了個寂寞。5.2 SADD/SREM/SISMEMBER集合操作與用戶標簽實戰(zhàn)Set 最常見的場景是給用戶打標簽。內(nèi)容平臺要給用戶打上科技愛好者數(shù)碼達人籃球迷等標簽用 Set 來做就是 SADD user:1001:tags 科技 數(shù)碼 籃球 (integer) 3 SREM user:1001:tags 科技 (integer) 1 SISMEMBER user:1001:tags 數(shù)碼 (integer) 1標簽的增刪查改都變成了集合操作非常自然。更妙的是當需要知道同時打了 A 標簽和 B 標簽的用戶時可以直接用 SINTER 求交集不用在業(yè)務代碼里做雙重循環(huán)。舉一個實際場景運營想篩選既關(guān)注數(shù)碼話題又活躍的用戶維護兩個 Set一個存關(guān)注數(shù)碼話題的用戶 ID一個存活躍用戶 ID然后 SINTER 取交集一次拿到人群包。這種基于 Set 的交并集運算在推薦系統(tǒng)的人群圈選里是標配。5.3 隨機類場景SPOP 和 SRANDMEMBER 的區(qū)別抽獎是 Set 的經(jīng)典玩法但 SPOP 和 SRANDMEMBER 兩個命令的分工經(jīng)常被搞混。SPOP 會從集合中隨機移除一個元素并返回它SRANDMEMBER 則只是隨機返回一個或多個元素不會移除。對應到業(yè)務上抽獎發(fā)獎獎品發(fā)放后不能重復發(fā)用 SPOP隨機展示推薦位、隨機抽一個用戶做調(diào)查但不改變用戶池用 SRANDMEMBER SADD lottery:20240101 u1 u2 u3 u4 (integer) 4 SPOP lottery:20240101 u2 SRANDMEMBER lottery:20240101 2 1) u3 2) u4我見過一個活動組的同學在抽獎接口里用 SRANDMEMBER 抽獎結(jié)果一個用戶被抽中兩次因為元素還在集合里。后來改成 SPOP中獎用戶立刻出池問題就沒了。另一個細節(jié)是 SPOP 支持 count 參數(shù)SPOP lottery:20240101 3 可以一次抽出 3 個不同的元素保證互不重復這在批量抽獎里非常實用不需要在代碼里循環(huán)多次調(diào) SPOP。5.4 Set 做存在性判斷從黑名單到布隆過濾器的取舍Set 還可以承擔一部分布隆過濾器的職責判斷一個元素是否存在時用 SISMEMBER時間復雜度 O(1)。比如黑名單、白名單、已讀列表、已發(fā)放權(quán)益列表都可以用 Set 來存。和布隆過濾器相比Set 的優(yōu)點是精確、無誤差缺點是內(nèi)存占用較高——每個元素都要真實存儲在內(nèi)存中。我在實戰(zhàn)中的做法是如果集合規(guī)模小幾萬到幾十萬直接用 Set 做存在性判斷省心省力如果規(guī)模到了千萬級甚至億級Set 內(nèi)存頂不住才考慮布隆過濾器。這里有一個折中的技巧可以把 Set 的 key 按業(yè)務維度切片比如 user:100x:blacklist把一個巨大的集合拆散到多個 key 上分擔單 key 的壓力同時讓 SISMEMBER 的命中路徑更短。切片的粒度要結(jié)合實際查詢模式別切出幾十萬個 key 把管理搞癱瘓。6. Sorted Set排行榜、延遲隊列與范圍查詢的關(guān)鍵武器6.1 Score 的含義與排序規(guī)則Sorted SetZSet是 Redis 五種類型里最特別的一個它給每個元素關(guān)聯(lián)了一個 double 類型的 score元素按 score 從小到大排序。如果你有復雜排序需求且同時要求插入性能ZSet 幾乎是唯一選擇。它的排序是穩(wěn)定的score 相同時按元素的字典序member 的字符串順序排列。 ZADD ranking:game 100 playerA 200 playerB 150 playerC (integer) 3 ZRANGE ranking:game 0 -1 WITHSCORES 1) playerA 2) 100 3) playerC 4) 150 5) playerB 6) 200注意 ZRANGE 默認是從小到大取也就是升序。如果你要排行榜從高到低可以用 ZREVRANGE從大到小或者 ZRANGE 加 REV 參數(shù)。很多面試題里會問ZSet 底層是什么答案是跳躍表加哈希表跳表負責排序和范圍查詢哈希表負責 O(1) 查找元素對應的 score。理解這一點你就明白了為什么 ZSet 能做按 score 取排名按排名取元素按 score 區(qū)間取元素三種維度的查詢而且效率都很高。6.2 ZADD/ZSCORE/ZRANK排行榜的完整實現(xiàn)路徑寫一個排行榜功能是 ZSet 的入門實操步驟并不復雜。第一步數(shù)據(jù)寫入。用 ZADD 把玩家 ID 和分數(shù)寫入 ZADD ranking:202401 1000 playerA (integer) 1 ZADD ranking:202401 1200 playerB (integer) 1 ZADD ranking:202401 800 playerC (integer) 1第二步查詢 TopN。用 ZREVRANGE 拿到榜單前三 ZREVRANGE ranking:202401 0 2 WITHSCORES 1) playerB 2) 1200 3) playerA 4) 1000 5) playerC 6) 800第三步給某個玩家加分。用 ZINCRBY 在現(xiàn)有 score 上累加 ZINCRBY ranking:202401 100 playerC 900第四步查某個玩家的排名。ZRANK 返回的是從 0 開始的升序排名ZREVRANK 返回降序排名 ZREVRANK ranking:202401 playerB (integer) 0有了這四步一個帶排名、加分、名次查詢的完整排行榜就通了。我在做排行榜時還會注意一個細節(jié)如果數(shù)據(jù)量很大ZRANGE 全量取出會導致網(wǎng)絡傳輸壓力很大所以接口層必須要分頁。很多新手直接 ZREVRANGE 0 -1 把整個排行榜拖回內(nèi)存再在內(nèi)存里分頁這是非常典型的性能反模式。正確做法是在 Redis 端就用 ZREVRANGE 的 start 和 stop 參數(shù)做分頁只拿當前頁需要的數(shù)據(jù)。6.3 ZSet 做延遲隊列的兩種思路與同分陷阱延遲隊列是 ZSet 的隱藏神技。思路很簡單把任務的執(zhí)行時間戳作為 score消費者用 ZRANGEBYSCORE 去拿到點該執(zhí)行的任務。我常用的實現(xiàn)方式有兩種。方式一輪詢掃描 ZADD delay:queue 1735689600 task:1001 ZRANGEBYSCORE delay:queue 0 1735689600 WITHSCORES LIMIT 0 10用一個后臺線程定時執(zhí)行 ZRANGEBYSCORE把 score 小于當前時間的任務取出來處理完再 ZREM 刪除。這個方案簡單、可控適合任務量不大的場景。方式二阻塞型使用 BZPOPMIN 可以阻塞等待score 最小且已被加入到集合中的元素彈出。但要注意BZPOPMIN 彈出的是整個 ZSet 中 score 最小的元素不是小于某個閾值的所有元素。所以如果你想實現(xiàn)嚴格的延遲隊列更穩(wěn)妥的還是輪詢方式。我再補充一個坑ZSet 的 score 是 double 類型用毫秒時間戳做 score 時精度完全夠但如果你用秒級時間戳同一秒內(nèi)大量任務會落到同一個 scoreZRANGEBYSCORE 的范圍取法就要額外考慮同秒任務的順序否則同一秒的任務你可能只取到一部分。做法是把時間戳精確到毫秒或者在任務里附帶一個自增序號來打破同分競爭。6.4 范圍查詢與冷熱數(shù)據(jù)的分級處理ZSet 里還有一個非常強大的能力就是按 score 范圍做切片查詢ZRANGEBYSCORE min max。做冷熱數(shù)據(jù)分級時可以把數(shù)據(jù)的最近活躍時間作為 score然后按時間窗口切出近期活躍和沉睡用戶。 ZADD active:users 1735689600 u1 ZADD active:users 1735603200 u2 ZRANGEBYSCORE active:users 1735603200 1735689600 1) u2 2) u1這個操作直接回答了哪些用戶在過去 24 小時內(nèi)有活躍行為。相比用時間戳字段去數(shù)據(jù)庫走索引ZSet 的優(yōu)勢是全內(nèi)存、O(log N) 的范圍查找、天然按時間排序。在一些用戶分層、營銷人群圈選的系統(tǒng)里這種用法非常常見。同樣要提醒ZSet 是內(nèi)存結(jié)構(gòu)存幾十萬上百萬元素還好千萬別把全量用戶都塞進一個 ZSet內(nèi)存和寫入壓力扛不住。要按業(yè)務域拆 key例如 active:202401、active:202402每個月一個新 key。6.5 ZSet 與 List、Set 的選擇取舍最后把決策問題講清楚。如果你還不知道某個場景該用 List、Set 還是 ZSet可以按這個思路判斷需要先進先出、按容量剪裁優(yōu)先 List需要唯一性、快速求交并集、隨機抽取優(yōu)先 Set需要按分數(shù)排序、按范圍取 TopN、帶權(quán)重取元素優(yōu)先 ZSet一個很好的類比是List 像排隊打飯的隊伍Set 像一個去重后的集合ZSet 更像一個帶分數(shù)標簽的有序排行榜。它們之間的轉(zhuǎn)換也經(jīng)常出現(xiàn)比如你先用 List 收集了一批待處理任務在去重環(huán)節(jié)轉(zhuǎn)成 Set最終需要按優(yōu)先級執(zhí)行時再轉(zhuǎn)成 ZSet。Redis 類型不是死的關(guān)鍵是每種類型擅長解決什么問題。7. 內(nèi)部編碼、內(nèi)存優(yōu)化與命令選型的經(jīng)驗總結(jié)7.1 五種類型的內(nèi)部編碼對照很多面試題里會問 Redis 的 encoding但實際調(diào)優(yōu)中它也是最有用的信息因為直接決定了內(nèi)存和性能。不同數(shù)據(jù)類型在不同條件下走不同編碼數(shù)據(jù)類型小數(shù)據(jù)量編碼大數(shù)據(jù)量編碼觸發(fā)轉(zhuǎn)換的關(guān)鍵配置Stringint / embstrraw字符串長度超過 44 字節(jié)走 rawHashziplisthashtablehash-max-ziplist-entries / hash-max-ziplist-valueListquicklist內(nèi)含 ziplistquicklistlist-max-ziplist-size / list-compress-depthSetintsethashtableset-max-intset-entriesZSetziplistskiplist dictzset-max-ziplist-entries / zset-max-ziplist-value我并不是建議你去背這些配置而是建議你在內(nèi)存水位異常時用 OBJECT ENCODING key 或 DEBUG OBJECT key 去看一個 key 當前的編碼 OBJECT ENCODING user:1001 ziplist DEBUG OBJECT user:1001 Value at:0x7f9f1c44b920 refcount:1 encoding:ziplist serializedlength:83 lru:4823112 lru_seconds_idle:120如果發(fā)現(xiàn)原本預期走緊湊編碼的 key 變成了 hashtable 或 raw往往是因為某個 value 太大或字段太多觸發(fā)了轉(zhuǎn)換。這時候你該做的不是盲目調(diào)大閾值而是審視數(shù)據(jù)模型是否合理。比如一個 Hash 的 field 漲到上萬個那不該調(diào)高 ziplist 閾值而是應該把大 Hash 拆成多個小 Hash按業(yè)務分桶。7.2 內(nèi)存優(yōu)化從 key 命名到緊湊編碼的三個層次Redis 內(nèi)存優(yōu)化的話題很容易被忽視因為很多人只有當內(nèi)存報警時才想起看但那時已經(jīng)晚了。我給出的優(yōu)化思路有三個層次。第一層控制 key 的數(shù)量與長度。一個 key 的名稱哪怕只多 20 個字節(jié)1000 萬個 key 就多出 200MB 內(nèi)存這還不算哈希表本身的膨脹。所以 key 命名要短而可讀比如 user:1001 而不是 full_user_name:1001:profile_cache:001。我看到過長 key 把內(nèi)存占到 30% 以上的真實案例教訓是命名的長度直接影響內(nèi)存成本。第二層優(yōu)選緊湊編碼。在前面編碼對照表里ziplist、intset、embstr 都是緊湊編碼在數(shù)據(jù)量小時內(nèi)存效率遠高于 hashtable 和 raw。合理設置閾值盡量讓小數(shù)據(jù)保持緊湊形態(tài)。需要提醒的是緊湊編碼下的讀性能未必差只是寫路徑更脆因為寫入可能觸發(fā)編碼轉(zhuǎn)換。所以更建議根據(jù)業(yè)務規(guī)模預估來設置閾值而不是拍腦袋把參數(shù)調(diào)大。第三層利用 key 聚合減少元數(shù)據(jù)開銷。Redis 每個 key 都要維護元數(shù)據(jù)類型、編碼、LRU、引用計數(shù)等key 數(shù)量越多元數(shù)據(jù)開銷越大。把業(yè)務上相關(guān)聯(lián)的子數(shù)據(jù)聚合到一個 Hash/ZSet/Set 里能顯著減少 key 的數(shù)量。比如點贊、收藏、評論三個計數(shù)用一個 Hash 存三個 field比用三個 key 存三個值更省內(nèi)存。但聚合也要有度單 key 過大又會導致讀寫放大所以聚合和拆分要根據(jù)實際訪問模式來平衡。7.3 O(N) 命令的紅線KEYS、HGETALL、SMEMBERS、LRANGERedis 在單線程模型下一個慢命令會阻塞所有其他命令。常用的 O(N) 命令里有幾個經(jīng)典紅線是必須記住的KEYS生產(chǎn)環(huán)境等于自殺千萬別用用 SCAN 代替HGETALL大 Hash 下會阻塞用 HSCAN 或按需 HGETSMEMBERS大 Set 下的全量輸出同理用 SSCANLRANGE大 List 下全量輸出同理按需 LRANGE start stopZRANGE大 ZSet 下全量輸出同理分頁取這里多說一句Redis 會為慢命令記錄 slowlog配置 slowlog-log-slower-than 可以設置閾值。實際排障時我經(jīng)常用 SLOWLOG GET 定位那些拖垮實例的罪魁禍首。建議上線前就把慢日志打開閾值設在 10 毫秒左右生產(chǎn)環(huán)境一旦出現(xiàn)慢查詢就知道誰在搗鬼 SLOWLOG GET 10 1) 1) (integer) 102 2) (integer) 1735689600 3) (integer) 2300 4) SLOWLOG7.4 類型選擇決策表遇到業(yè)務需求先查這張表我把常見業(yè)務需求直接映射到對應的數(shù)據(jù)類型方便你直接抄作業(yè)。這份經(jīng)驗匯總不保證覆蓋所有場景但能覆蓋八成常見需求業(yè)務需求推薦數(shù)據(jù)類型關(guān)鍵命令緩存單值、分布式鎖StringSET / GET / SETNX / SETEX緩存對象、按字段讀寫HashHSET / HGET / HGETALL會話、驗證碼短期存儲StringSETEX / GETDEL最新動態(tài)、時間線ListLPUSH / LTRIM / LRANGE輕量消息隊列ListLPUSH / BRPOP可靠消息隊列Stream或外部 MQXADD / XREADGROUP用戶標簽、去重SetSADD / SISMEMBER / SINTER隨機抽獎SetSPOP / SRANDMEMBER排行榜、TopNZSetZADD / ZINCRBY / ZREVRANGE延遲隊列ZSetZADD / ZRANGEBYSCORE / ZREM全局唯一計數(shù)StringINCR / DECR大規(guī)模存在性判斷RedisBloom布隆過濾器BF.ADD / BF.EXISTS這張表是我做技術(shù)選型時的第一反應表。它不解決這個業(yè)務到底要不要用 Redis的問題只解決確定了用 Redis 之后該用哪個類型的問題。接下來再想清楚 key 生命周期、過期策略、與數(shù)據(jù)庫的一致性整個方案就已經(jīng)成型了一半。7.5 從五大類型到 Stream、Bitmaps、HyperLogLog 的延伸寫完五大類型必須提一句 Redis 不止這五種。官方容易被忽視的還有 Bitmaps、HyperLogLog、Stream、地理空間類型 Geo。它們各有絕活Bitmaps 做在線狀態(tài)統(tǒng)計極省內(nèi)存HyperLogLog 用 12KB 就能做千萬級基數(shù)統(tǒng)計Geo 直接支持附近的人或店鋪查詢Stream 則彌補了 List 做可靠消息隊列的短板。我平時的習慣是先用五大類型解決 80% 的需求再根據(jù)場景引入這些專項類型。它們不是越多越好而是搞清楚每種類型在天平上的位置——內(nèi)存、準確度、實時性、可靠性四個維度分別取舍。8. 實際部署中的幾個翻車現(xiàn)場與搶救記錄8.1 大 Value 引發(fā)的阻塞與拆分真實翻車案例一某個老項目里用一個 String key 存儲了十幾 MB 的 JSON 數(shù)據(jù)啟動時一次性讀取平時基本不更新。結(jié)果某天業(yè)務方大量請求這個 keyRedis 響應突然飆到幾百毫秒。我用 STRLEN 檢查發(fā)現(xiàn) value 已經(jīng)很大又用 SLOWLOG 確認 GET 操作本身就是慢查詢。之所以慢不完全是網(wǎng)絡傳輸問題而是這個 key 的數(shù)據(jù)在 Redis 內(nèi)部要經(jīng)歷序列化、內(nèi)存拷貝、網(wǎng)絡輸出三個階段每個階段都被放大。后來我把這個 String 拆成多個小 key 按字段存儲或者改用 Hash 按字段讀取問題迎刃而解。這里的關(guān)鍵教訓是Redis 不適合存大對象超過幾百 KB 就要拆。真遇到不能拆的比如整存整取的外系統(tǒng)接口數(shù)據(jù)那就做好緩存失效策略和網(wǎng)絡超時并接受延遲上升的事實。8.2 過期策略與內(nèi)存淘汰的組合拳很多人在一個 Redis 實例里同時設置 TTL又開啟了 allkeys-lru 淘汰結(jié)果發(fā)現(xiàn)數(shù)據(jù)早早就被淘汰了總是丟失。這里有兩個機制的名字只差一字但行為截然不同過期機制expire是主動把過期數(shù)據(jù)刪除內(nèi)存淘汰eviction是在內(nèi)存達到 maxmemory 時按策略挑選 key 刪除。如果實例內(nèi)存很小又開了 allkeys-lru那么即使 key 還沒到 TTL也可能被 LRU 策略提前淘汰。解決辦法依據(jù)業(yè)務特點來定緩存型數(shù)據(jù)可以接受淘汰用 volatile-lru 或者 allkeys-lru 都行但像分布式鎖、限流計數(shù)這種狀態(tài)型數(shù)據(jù)絕不能依賴淘汰策略一定要設置合理的 TTL 并考慮持久化。另一個相關(guān)的坑是過期鍵在從庫上不會主動刪除。Redis 主從架構(gòu)里過期鍵的處理是主庫負責刪除然后向從庫發(fā)送 DEL。如果從庫被提升為主庫在舊主庫發(fā)送刪除命令之前從庫上的這些數(shù)據(jù)可能仍然可讀——這是主從切換后偶爾出現(xiàn)臟數(shù)據(jù)的一個原因。要減少這個窗口需要關(guān)注 repl-disable-tcp-nodelay 和同步延遲或者使用 Redis 7 的 WAITAOF 等機制提升數(shù)據(jù)一致性。8.3 用 MEMORY 和 OBJECT 命令做常規(guī)體檢真正的排障高手不會等故障發(fā)生才動手而是定期給 Redis 做體檢。我最常用的三個命令第一個是 MEMORY USAGE key查一個 key 實際占用內(nèi)存 MEMORY USAGE user:1001 (integer) 136第二個是 INFO memory查整體內(nèi)存分布、碎片率 mem_fragmentation_ratio 等 INFO memory # Memory used_memory:826032 used_memory_human:806.67K used_memory_rss:2396160 mem_fragmentation_ratio:2.90碎片率長期大于 1.5 或小于 1都要關(guān)注。大于 1.5 說明內(nèi)存碎片嚴重可以考慮啟用 activedefrag 或通過主從切換來整理小于 1 說明發(fā)生了 swapRedis 開始用磁盤性能會斷崖式下跌。第三個是 OBJECT ENCODING key查編碼是否符合預期。這三個命令組合起來一個 key 大約 10 秒內(nèi)就能完成內(nèi)存占用、碎片情況、編碼狀態(tài)的全面體檢。8.4 連接數(shù)打滿與命令超時的排查鏈路還有一次業(yè)務反饋所有接口都變慢我排查后發(fā)現(xiàn) Redis 連接數(shù)暴漲。連接數(shù)打滿的常見原因有幾個服務端連接池配置過大、客戶端沒有正確歸還連接、慢查詢導致單個連接占用時間過長、空閑連接沒有及時回收。這些原因的排查順序我從實際經(jīng)驗里總結(jié)成一條鏈路先看 deferred 和 rejected 連接數(shù)再用 CLIENT LIST 看連接來源分布再用 SLOWLOG 慢日志看是否有慢命令最后看客戶端連接池的 maxTotal 和 maxIdle 配置。這里特別提一個容易被忽略的點很多客戶端連接池的最大連接數(shù)默認值是大幾千但 Redis 服務端默認 maxclients 只有 10000。當服務實例多、每個實例又用盡連接池時很容易打滿。解決辦法是統(tǒng)一規(guī)劃連接池大小建議每個服務實例的連接數(shù)控制在幾百以內(nèi)并在客戶端配置合理的 minIdle 和 maxIdle避免連接被無意義地占用。另一個維度是給所有 Redis 命令設置合理的超時時間——連接超時設 200ms讀超時設 500ms一旦超時立即熔斷降級而不是無限等待把故障的影響控制在調(diào)用方。9. 寫給新手的幾條實戰(zhàn)心法9.1 先畫數(shù)據(jù)模型再寫命令我見過很多新人一上來就敲命令敲著敲著發(fā)現(xiàn)類型選錯了又要重構(gòu)。正確順序是先畫出業(yè)務數(shù)據(jù)模型——哪些是單值、哪些是對象、哪些是列表、哪些是集合、哪些需要排序然后對著五大類型做映射。這個過程不花 10 分鐘但能省下一天的重構(gòu)時間。畫數(shù)據(jù)模型時我的習慣是隨手寫一個數(shù)據(jù)字典格式很簡單key: user:1001 類型: Hash field: name / age / city / reg_time 用途: 用戶詳情緩存按字段讀取 TTL: 1 小時每個 key 都按這個格式在項目文檔里登記維護成本非常低但團隊協(xié)作時能避免很多這個 key 到底存的啥的口頭溝通。9.2 一套命令走天下還是按需組合Redis 的命令看起來多但常用的命令其實就是二十來個。我對新手的建議是別試圖背全命令但要把核心組合用熟。單值緩存組合SET GET DEL SETNX SETEX EXPIRE對象緩存組合HSET HGET HGETALL HDEL HINCRBY列表組合LPUSH RPOP LRANGE LTRIM LLEN集合組合SADD SREM SISMEMBER SINTER SPOP有序集合組合ZADD ZINCRBY ZRANGE ZREVRANGE ZRANGEBYSCORE每個組合都有自己的慣用法比如LPUSH LTRIM 做最新列表ZADD ZREVRANGE 做排行榜SADD 返回值做去重判斷。把慣用法記熟再配合 SCAN、OBJECT、MEMORY 等運維命令基本就能應對 95% 的開發(fā)場景。9.3 養(yǎng)成三個好習慣TTL、命名規(guī)范、監(jiān)控最后聊聊習慣技術(shù)選型再對習慣不好也會翻車。我總結(jié)成三條缺一不可。第一能設 TTL 一定要設 TTL。緩存型數(shù)據(jù)如果忘了設過期時間一旦數(shù)據(jù)源變化Redis 里的舊數(shù)據(jù)就會一直存在成為僵尸緩存。我見過一個項目所有 key 都沒設置過期時間后來數(shù)據(jù)不一致了排查了一星期最后發(fā)現(xiàn)是緩存沒失效。所有能設 TTL 的 key都應該設 TTL哪怕只是 10 分鐘。第二key 命名要有統(tǒng)一規(guī)范。一個可讀的命名體系能讓你在排障時不用憑空猜。我常用的規(guī)范是業(yè)務域:實體:ID:屬性例如 user:1001:profile:name。這種命名方式的好處是可以通過前綴用 SCAN 掃描出某個業(yè)務域的所有 key監(jiān)控平臺也能按前綴聚合統(tǒng)計。但注意千萬不要用 KEYS 命令去掃生產(chǎn)環(huán)境要用 SCAN。第三監(jiān)控必須前置。至少要有三個指標命中率hit_rate、內(nèi)存使用率、慢查詢數(shù)。命中率低了說明緩存設計有問題內(nèi)存漲了要提前擴容慢查詢多了要立刻排查。對接 Prometheus 加 Grafana 的 redis_exporter 是社區(qū)標配上線前就接好別等出了事故再裝。這三個習慣是零成本高回報的典型。很多人把注意力放在選型和命令上卻忽視了這些基礎工程能力最終在真實故障里付出代價?？梢哉fRedis 用得好不好一大半取決于這三點有沒有做到。我自己的體會是把這五種類型全部用熟只是第一層真正的高手會把它們當作樂高積木一樣自然地組合用 String 存令牌、用 Hash 存對象、用 List 做時間線、用 Set 做去重、用 ZSet 做排序然后在更復雜的場景里疊加 Stream、HyperLogLog 這些進階結(jié)構(gòu)。掌握每個結(jié)構(gòu)最擅長解決的那個問題比死記一百條命令有用得多。最后再分享一個小技巧遇到不確定該用哪種類型的方案先在命令行里用真實數(shù)據(jù)規(guī)模的小樣本跑一遍觀察內(nèi)存和耗時表現(xiàn)再做決定。這種先試驗后落地的習慣能幫你避免很多以為能用、一上線就出問題的大型返工。 Redis五大數(shù)據(jù)類型實戰(zhàn)詳解：原理、場景選型與排障
1. 為什么先把數(shù)據(jù)類型想清楚比背命令更重要做后端開發(fā)的幾乎沒有人能繞開 Redis。緩存、分布式鎖、排行榜、消息隊列、計數(shù)統(tǒng)計樣樣都有它的身影。但我在面試和帶團隊時發(fā)現(xiàn)一個很有意思的現(xiàn)象很多人提到 Redis能熟練說出 String、Hash、List、Set、ZSet 這五種數(shù)據(jù)類型可一旦落到具體業(yè)務場景選型和命令就亂了套——有人用 String 存了一個巨大的 JSON有人用 List 做高可靠消息隊列還有人把排行榜硬生生做成了在數(shù)據(jù)庫里 ORDER BY。這些問題的根源不是命令不熟而是對數(shù)據(jù)類型的底層定位和適用邊界缺乏直覺。這篇內(nèi)容我準備把這五種數(shù)據(jù)類型徹底拆開講透。不光是SADD 是加集合、ZADD 是加有序集合這種流于表面的操作符背誦而是每個類型解決什么問題、底層結(jié)構(gòu)如何影響性能、什么場景選它會自找麻煩、什么樣的 key 設計才算合理。你如果是剛接觸 Redis 的新手這篇文章可以作為完整的入門路線你如果已經(jīng)用 Redis 寫過業(yè)務代碼我相信里面關(guān)于大 key、編碼轉(zhuǎn)換、原子性誤區(qū)和排障經(jīng)驗的段落也能幫你補上一些平時沒太注意的盲區(qū)。我自己的習慣是拿到一個業(yè)務需求先不動手寫命令先畫數(shù)據(jù)模型再對著五種類型做映射。這一步做完整個方案基本就成型了。接下來我們把每個類型挨個過一遍從原理講到實戰(zhàn)再講講這些年我踩過的坑。2. String最基礎但最容易被用錯的類型2.1 String 的底層結(jié)構(gòu)和三種編碼形態(tài)String 是 Redis 最基礎的數(shù)據(jù)類型一個 key 對應一個 valuevalue 最大能到 512MB。很多人以為 String 就是存字符串實際它的底層遠不止字符串這么簡單。Redis 為了在不同場景下做出性能最優(yōu)的選擇給 String 設計了三種編碼方式編碼觸發(fā)條件底層結(jié)構(gòu)intvalue 是整數(shù)且能用 long 表示直接存整數(shù)值不自帶 redisObject 的 sds 頭部embstrvalue 長度小于等于 44 字節(jié)一次性分配連續(xù)的 redisObject 和 sds 內(nèi)存rawvalue 長度大于 44 字節(jié)分兩次分配redisObject 和 sds 獨立內(nèi)存這個 44 字節(jié)的臨界值很多資料提過但沒講透。它其實是 Redis 內(nèi)存分配策略和緩存行對齊共同作用的結(jié)果jemallocRedis 默認內(nèi)存分配器在 64 字節(jié)以下會走 size class 分配redisObject 結(jié)構(gòu)本身占 16 字節(jié)SDS 頭部在 Redis 3.2 之后占 3 字節(jié)再加上結(jié)束符算下來能留給數(shù)據(jù)的空間就是 44 字節(jié)。超過這個值embstr 的連續(xù)內(nèi)存一次分配優(yōu)勢就保不住了轉(zhuǎn)為 raw 后讀寫需要兩次內(nèi)存分配性能會略降。我在實際項目中很少直接干預編碼切換但我會用 OBJECT ENCODING 命令檢查線上 key 的編碼狀態(tài)。以前排查過一個詭異問題某個存儲手機號的 String key平時寫入都正常偶爾一次寫入性能暴跌后來發(fā)現(xiàn)是因為某個手機號后面多了一個空格長度從 11 位變成 12 位編碼從 embstr 跳到 raw觸發(fā)了一次額外的內(nèi)存分配。這種問題很難從業(yè)務代碼層面察覺但只要你理解編碼機制排查方向就會清晰很多。2.2 單值緩存以外String 的經(jīng)典命令組合String 最常見的用法當然是緩存單值比如用戶昵稱、商品庫存、接口返回的 JSON 片段。但 String 的價值不止于 SET/GET 這一對我給你列幾個我日常最高頻的命令組合每一個都有明確的場景指向。SETNX 是分布式鎖的最小實現(xiàn)。它的全稱是 SET if Not eXists只有在 key 不存在時才設置成功。配合 EXPIRE 設置過期時間就成了一版最簡分布式鎖 SETNX lock:order:1001 1 (integer) 1 EXPIRE lock:order:1001 30 (integer) 1當然真實生產(chǎn)環(huán)境里建議直接用 SET 命令帶 NX 和 EX 兩個參數(shù)一次性完成 SET lock:order:1001 1 NX EX 30 OK為什么推薦用 SET 帶 NX EX 而不是先 SETNX 再 EXPIRE因為兩條命令組合不具備原子性中間如果 Redis 崩潰或網(wǎng)絡抖動鎖就沒有過期時間了直接變成死鎖。用一條 SET 命令就能把加鎖和設置過期合并成一個原子操作這個細節(jié)我在代碼評審里幾乎每次都會提。MSET/MGET 是批量讀寫的利器。一次網(wǎng)絡往返完成多個 key 的讀寫在高并發(fā)場景下能顯著降低 RTT 的影響 MSET user:1001:name zhangsan user:1001:age 28 OK MGET user:1001:name user:1001:age 1) zhangsan 2) 28這里要注意MSET/MGET 雖然是批量操作但它并不是原子的——中間某個 key 寫失敗不會回滾其他 key。如果你需要要么全成功要么全失敗的事務語義得用 MULTI/EXEC 包裹但那樣又會帶來性能開銷所以常規(guī)緩存場景用 MSET/MGET 就夠了別指望它承載事務。2.3 為什么容器類型嵌套的 String 不一定安全Redis 的 Hash、List、Set、ZSet 里存的值本質(zhì)上也都是 String。于是有一種常見的錯誤認知既然容器里的元素是 String那我是不是可以用同樣的 String 命令去處理它們我可以直接說結(jié)論不行。容器內(nèi)部的 String 不具備獨立 key 的性質(zhì)它沒有自己的 TTL、沒有自己的過期時間、不能被單獨設置 EXPIRE也不能被單獨設置訪問權(quán)限。為什么這樣說因為 Redis 的過期機制是以 key 為單位的。你給一個 Hash 設置了 EXPIRE整個 Hash 到點會被刪除但 Hash 里某個 field 想要單獨維持更長時間的存留普通版本 Redis 根本做不到。Redis 7.4 開始支持部分 Hash field 的過期特性但在 7.4 之前所有給某個 field 單獨設 TTL的方案都是自己用另外的 key 去模擬。這個特性我在設計緩存方案時吃過虧。當時給一個用戶維度的 Hash 設置了 1 小時過期其中某個 field 存的是特殊標記需要保留 24 小時。我天真地以為可以單獨給那個 field 續(xù)期后來發(fā)現(xiàn)根本沒這個命令最后只能拆出一個獨立的 String key 來存這個標記。這個教訓讓我養(yǎng)成一個習慣凡是生命周期不一致的數(shù)據(jù)千萬別塞進同一個容器 key要么拆 key要么接受整體過期的約束。2.4 String 適合做的幾類小任務除了緩存和鎖String 還有幾個被低估的用法。第一類是計數(shù)器。INCR 和 DECR 是原子操作天然適合做訪問量、點贊數(shù)、庫存扣減。很多新人會用先 GET 再 SET來實現(xiàn)計數(shù)這在并發(fā)下會丟數(shù)正確姿勢永遠是直接 INCR/DECR讓 Redis 保證原子性。第二類是 Session 共享。分布式系統(tǒng)里用戶登錄狀態(tài)通常放在 Redis用 SETEX 設置會話 ID 和過期時間用戶每次請求都去 GET 一下。這個場景的關(guān)鍵是過期時間的粒度要匹配業(yè)務純接口鑒權(quán)可以設短一點比如 30 分鐘購物車這種需要長時間保留的狀態(tài)可以設長一些比如 7 天。第三類是分布式 ID 生成。INCR 一個全局 key就能拿到一個趨勢遞增的 ID。但要注意這個 ID 不能拿去當數(shù)據(jù)庫主鍵因為 Redis 重啟后 INCR 會從持久化后的值繼續(xù)如果持久化策略是 RDB 快照重啟后可能丟掉最近幾次自增記錄會造成主鍵沖突。所以分布式 ID 建議用專門的雪花算法或者在數(shù)據(jù)庫層用號段模式Redis 的 INCR 只適合對順序不敏感的場景。3. Hash對象緩存和等值查詢的性價比之王3.1 為什么對象型數(shù)據(jù)我首選 HashString 類型存對象時有兩種常見但又各有局限的做法一是把整個對象 JSON 序列化后塞進一個 key查詢時整體反序列化哪怕只想取其中一個字段也要全量解析二是按對象屬性拆成多個 key多出大量 key 的維護成本。Hash 的思路則完全不同——它天生就是一個小對象容器一個 key 下面可以掛多個 field-value 對結(jié)構(gòu)上和對象幾乎一一對應 HSET user:1001 name zhangsan age 28 city hangzhou (integer) 3 HGET user:1001 name zhangsan HGETALL user:1001 1) name 2) zhangsan 3) age 4) 28 5) city 6) hangzhou當業(yè)務方接口只返回用戶昵稱時HGET 一次到位當丟給前端做詳情展示時HGETALL 一把梭哈非常靈活。和 String 方案相比Hash 最大的三個優(yōu)勢是單字段讀寫、批量字段讀寫、字段級邏輯控制。這些優(yōu)勢在緩存化改造中特別明顯——把老的 MySQL 行記錄映射成一個 Hash 時字段名和列名幾乎可以一一對齊改造成本極低。我用 Hash 做對象緩存的習慣是key 保持高扇出、可枚舉field 用穩(wěn)定的業(yè)務標識。典型 key 設計是 user:1001、order:20231001 這種后面跟業(yè)務 ID。如果業(yè)務 ID 本身可能被重建或變化那就盡量避免把所有邏輯都掛在同一個 key 上因為 Hash 的過期是整體過期的一個 field 想單獨續(xù)期會變得很別扭。這一點在緩存與數(shù)據(jù)庫一致性方案里經(jīng)常被忽略——很多人以為 Hash 可以做字段級過期實際上官方在普通 Hash 上并不提供這個能力除非你用的是 7.4 以上版本且啟用了 hash field expiration 特性。3.2 HGETALL 的不當使用與漸進式遍歷HGETALL 是個好命令但也很容易成為性能陷阱。當一個 Hash 里有幾千個 field 時HGETALL 會一條命令把所有 KV 全部拉回來這個 O(N) 操作在大 key 場景下比預想中更危險。我之前接手過一個跑了兩年的老項目一個商品信息 Hash 因為運營不斷往里面加自定義屬性慢慢膨脹到幾萬個 field高峰期一個 HGETALL 就能把帶寬和 GC 拉爆。排查時我先執(zhí)行 HLEN 發(fā)現(xiàn) field 數(shù)量已經(jīng)上萬然后立刻讓線上讀按需取字段只讀接口用多個 HGET 精準命中管理后臺才放行 HGETALL才把慢查詢壓下去。如果確實要全量讀或做遍歷推薦漸進式命令 HSCAN它和 SCAN 的思路一致可以分多次迭代取回全部 field-value每次返回一個游標下次接著遍歷。HSCAN 返回的游標并不是簡單的偏移量而是哈希桶的索引位置所以哪怕遍歷過程中有數(shù)據(jù)變化也能保證不錯的起始點位 HSCAN user:1001 0 MATCH name* 1) 0 2) 1) name 2) zhangsan這種做法適合做數(shù)據(jù)統(tǒng)計、批量遷移或后臺任務掃描但不適合高頻線上讀鏈路。線上讀服務永遠是精確命中離散取字段而不是拿著大鐵鍬去挖金礦。3.3 Hash 的內(nèi)存結(jié)構(gòu)與編碼轉(zhuǎn)換細節(jié)Hash 在元素較少時使用 ziplist緊湊列表編碼當元素數(shù)量超過 hash-max-ziplist-entries 或單個 field 的 value 長度超過 hash-max-ziplist-value 時會轉(zhuǎn)換為 hashtable 編碼。這個轉(zhuǎn)換是透明的但會影響內(nèi)存占用和操作復雜度。我做過一次內(nèi)存實測100 萬個 field 的小值 Hash在 ziplist 編碼下內(nèi)存占用比 hashtable 編碼大概省 30% 到 40%讀取耗時差別也在毫秒級內(nèi)真正的差異主要發(fā)生在寫入時的 rehash 和內(nèi)存碎片上。實際操作中我會在配置里關(guān)注 hash-max-ziplist-entries 和 hash-max-ziplist-value 兩個參數(shù)。如果業(yè)務明確知道某個 Hash 的 field 數(shù)量上限很低可以把閾值調(diào)高一點盡量保持 ziplist 編碼以節(jié)省內(nèi)存但也要小心ziplist 編碼下的更新操作是 O(N)如果頻繁修改中間位置的數(shù)據(jù)性能反而會下降。我的經(jīng)驗是一個 Hash 的 field 數(shù)控制在幾百到幾千、單個 value 控制在幾百字節(jié)內(nèi)是比較舒服的范圍超過這個量級就要考慮是不是數(shù)據(jù)結(jié)構(gòu)選錯了。3.4 用 Hash 做短鏈映射、字典表與多指標計數(shù)Hash 的應用場景里我最常用的是三類。第一是短鏈映射。短鏈服務通常需要一個短碼到完整 URL的映射直接用 Hash 存一個短鏈庫就是一個大 Hash訪問時 HGET 一下生成時 HSET 一下天然支持批量導入。第二是字典表。電商后臺會有一堆枚舉值狀態(tài)碼、城市碼、類目碼這種配置型數(shù)據(jù)按業(yè)務模塊拆成多個 Hash例如 config:city 存所有城市編碼和名稱config:category 存類目樹。后臺修改配置時 HSET 某個字段不影響到其他字段也不用為每個配置單獨建一個 String keykey 數(shù)量大幅下降。第三是多指標計數(shù)。比如記錄某篇文章的點贊、收藏、評論數(shù)用 Hash 的 field 分別保存 post:1001:stat 的 like、fav、comment每次更新用 HINCRBY 原子累加讀取時 HMGET 一次拿多個指標不用為每個指標單獨建 key。這一招在實時數(shù)據(jù)大屏、運營看板里非常常見邏輯簡單但非常穩(wěn)。Hash 還有一個被低估的優(yōu)勢是批量寫入和批量讀取的對稱性。業(yè)務方要批量初始化一批對象時可以先用 HM?SE T一次寫入多個 field再在查詢時用 HMGET 一次性取多個 field。這種對稱設計在接口層很容易和前端表單字段對齊我寫緩存服務時特別偏愛這種對齊感——數(shù)據(jù)模型和接口模型一致代碼可讀性極高排查問題時一眼就能看清數(shù)據(jù)流向。4. List時間線、隊列與操作記錄的一把好手4.1 List 在 Redis 里的真實定位很多人一提到 List 就下意識說消息隊列這個印象不奇怪LPUSH 加 BRPOP 的組合確實可以做出一個簡單的隊列。但 List 在 Redis 五大類型里其實更偏線性結(jié)構(gòu)的存在它既是棧又是隊列既可以左進右出也可以左進左出完全取決于你怎么用。而它真正的實力在于順序性、長度控制和時間窗口記錄。List 的內(nèi)部存儲是一個雙向鏈表結(jié)構(gòu)所以頭尾插入刪除都是 O(1)但中間位置的隨機訪問則是 O(N)。Redis 的 List 在早期實現(xiàn)里直接用 linkedlist后來為了節(jié)省內(nèi)存又引入了 quicklist一種以 ziplist 為節(jié)點的雙向鏈表。我自己的理解是List 適合所有按時間順序追加、按批次消費的場景不適合高頻隨機查找。如果你要按索引下標取值比如取第 1000 個元素List 會慢到你想罵人這時候應該考慮用其他結(jié)構(gòu)而不是硬扛。4.2 LPUSH 加 LPOP / RPOP從隊列到棧的完整組合List 的命令很多核心就幾組。先看最常用的隊列語義 LPUSH task:queue job1 job2 job3 (integer) 3 RPOP task:queue job1 RPOP task:queue job2LPUSH 從左側(cè)寫入RPOP 從右側(cè)彈出先進先出這就是一個標準 FIFO 隊列。反過來LPUSH 加 LPOP 就是 LIFO 棧。如果想讓消費端在隊列為空時阻塞等待可以用 BRPOP這樣消費端不會高頻空轉(zhuǎn)輪詢能大幅降低無謂的 Redis 訪問壓力 BRPOP task:queue 5 1) task:queue 2) job3這個 5 表示阻塞 5 秒超時返回空。我在做任務調(diào)度時經(jīng)常用 BRPOP 配合超時時間消費線程掛在那里隊列一來就立刻被喚醒隊列空閑時也不會反復產(chǎn)生請求。有一個值得注意的點BRPOP 返回的是key 和 value兩部分因為你可能同時阻塞監(jiān)聽多個 key所以返回值里第一項是哪個 key 有數(shù)據(jù)第二項才是具體數(shù)據(jù)代碼里別取錯。4.3 用 List 做時間線和操作記錄LTRIM 的妙用List 的另一個高頻場景是最新動態(tài)和操作記錄。比如用戶的最近瀏覽記錄、系統(tǒng)的最近告警、文章的最新評論都有同一個共性只關(guān)心最新的 N 條歷史數(shù)據(jù)要么歸檔要么丟棄。實現(xiàn)思路很經(jīng)典 LPUSH user:1001:recent_posts post:9001 post:9002 post:9003 (integer) 3 LTRIM user:1001:recent_posts 0 2 OK LRANGE user:1001:recent_posts 0 -1 1) post:9003 2) post:9002 3) post:9001LPUSH 之后立刻 LTRIM 只保留前 N 條就構(gòu)成了一個容量固定的滑動窗口。你在微博、抖音時間線里看到的那種只保留最近一屏的列表底層很多就是這種思路。LTRIM 是 Range 保持的精髓它把超出窗口的內(nèi)容一次性剪掉不寫代碼、不跑定時任務一條命令就把 List 的容量控制住了。這里有個坑我必須多提一次LRANGE 返回的順序是從左到右。你 LPUSH 進去的數(shù)據(jù)在左側(cè)所以 LRANGE 0 -1 返回的第一條是最新寫入的。很多新人在這一點上栽過跟頭——他們以為 List 和數(shù)據(jù)庫查詢結(jié)果一樣順序按插入時間正序結(jié)果一測發(fā)現(xiàn)最新的在最前面日志里和預想不符排查半天。我建議寫代碼前先在命令行里手動 push 三條數(shù)據(jù)感受一下順序再進代碼寫邏輯別靠想象寫。4.4 List 作為消息隊列的痛點與替代方案雖然 LPUSH 加 BRPOP 能做隊列但如果你想用 List 在生產(chǎn)環(huán)境做重邏輯的消息隊列我勸你先想清楚幾個限制。消息丟失風險。BRPOP 彈出并返回數(shù)據(jù)后如果消費端在處理消息時崩潰這條消息就再也取不回來了。相比之下專業(yè)的消息隊列比如 RabbitMQ、Kafka 都有消費確認機制Redis Stream 則提供了消費者組和 PEL待處理條目列表來保證消息可追蹤。消息積壓時內(nèi)存膨脹。List 是一個純內(nèi)存結(jié)構(gòu)消息堆積多了Redis 內(nèi)存直接開始報警。消息隊列有磁盤緩沖能力但 Redis List 沒有。如果消息量預估很大要么考慮 Stream要么考慮外部的消息隊列中間件。重復消費問題。List 消費端拿走了消息消息就沒了所以也不存在重復消費和冪等設計的余地。如果你需要的是每個消息被多個消費者各自處理一次List 根本實現(xiàn)不了這是 Stream 的消費者組才有的能力。我對 List 做隊列的態(tài)度很簡單適合輕量級任務、低頻打點、單消費者場景不適合多消費者、高可靠、大量積壓的場景。后者的合理選擇是 Redis Stream如果連 Stream 都滿足不了可靠性要求那就直接用專業(yè)消息隊列別硬湊。5. Set標簽、去重與隨機抽樣的標準答案5.1 Set 的底層與去重邏輯Set 是一個無序、不重復的集合。它的底層實現(xiàn)有兩種編碼元素全是整數(shù)且數(shù)量少時用 intset整數(shù)集合元素是字符串或數(shù)量較大時用 hashtable。無論哪種編碼Set 都能保證添加重復元素時靜默忽略、不重復存儲。這一條命令實測就能證明 SADD tag:1001 java redis java (integer) 2 SMEMBERS tag:1001 1) java 2) redisSADD 返回 2說明第二個 java 被忽略了。這個去重能力是天然的不需要你在業(yè)務代碼里維護一個曾見過的清單。我在做去重邏輯時最省事的方案就是直接用一個 Set 的 key 存儲所有已處理的 ID每次新數(shù)據(jù)進來用 SISMEMBER 或 SADD 來判斷。SISMEMBER 返回 1 說明存在返回 0 說明不存在如果你想把判斷加加入合成一步那就看 SADD 的返回值——返回 1 說明添加成功原本不存在返回 0 說明原本就存在加了個寂寞。5.2 SADD/SREM/SISMEMBER集合操作與用戶標簽實戰(zhàn)Set 最常見的場景是給用戶打標簽。內(nèi)容平臺要給用戶打上科技愛好者數(shù)碼達人籃球迷等標簽用 Set 來做就是 SADD user:1001:tags 科技 數(shù)碼 籃球 (integer) 3 SREM user:1001:tags 科技 (integer) 1 SISMEMBER user:1001:tags 數(shù)碼 (integer) 1標簽的增刪查改都變成了集合操作非常自然。更妙的是當需要知道同時打了 A 標簽和 B 標簽的用戶時可以直接用 SINTER 求交集不用在業(yè)務代碼里做雙重循環(huán)。舉一個實際場景運營想篩選既關(guān)注數(shù)碼話題又活躍的用戶維護兩個 Set一個存關(guān)注數(shù)碼話題的用戶 ID一個存活躍用戶 ID然后 SINTER 取交集一次拿到人群包。這種基于 Set 的交并集運算在推薦系統(tǒng)的人群圈選里是標配。5.3 隨機類場景SPOP 和 SRANDMEMBER 的區(qū)別抽獎是 Set 的經(jīng)典玩法但 SPOP 和 SRANDMEMBER 兩個命令的分工經(jīng)常被搞混。SPOP 會從集合中隨機移除一個元素并返回它SRANDMEMBER 則只是隨機返回一個或多個元素不會移除。對應到業(yè)務上抽獎發(fā)獎獎品發(fā)放后不能重復發(fā)用 SPOP隨機展示推薦位、隨機抽一個用戶做調(diào)查但不改變用戶池用 SRANDMEMBER SADD lottery:20240101 u1 u2 u3 u4 (integer) 4 SPOP lottery:20240101 u2 SRANDMEMBER lottery:20240101 2 1) u3 2) u4我見過一個活動組的同學在抽獎接口里用 SRANDMEMBER 抽獎結(jié)果一個用戶被抽中兩次因為元素還在集合里。后來改成 SPOP中獎用戶立刻出池問題就沒了。另一個細節(jié)是 SPOP 支持 count 參數(shù)SPOP lottery:20240101 3 可以一次抽出 3 個不同的元素保證互不重復這在批量抽獎里非常實用不需要在代碼里循環(huán)多次調(diào) SPOP。5.4 Set 做存在性判斷從黑名單到布隆過濾器的取舍Set 還可以承擔一部分布隆過濾器的職責判斷一個元素是否存在時用 SISMEMBER時間復雜度 O(1)。比如黑名單、白名單、已讀列表、已發(fā)放權(quán)益列表都可以用 Set 來存。和布隆過濾器相比Set 的優(yōu)點是精確、無誤差缺點是內(nèi)存占用較高——每個元素都要真實存儲在內(nèi)存中。我在實戰(zhàn)中的做法是如果集合規(guī)模小幾萬到幾十萬直接用 Set 做存在性判斷省心省力如果規(guī)模到了千萬級甚至億級Set 內(nèi)存頂不住才考慮布隆過濾器。這里有一個折中的技巧可以把 Set 的 key 按業(yè)務維度切片比如 user:100x:blacklist把一個巨大的集合拆散到多個 key 上分擔單 key 的壓力同時讓 SISMEMBER 的命中路徑更短。切片的粒度要結(jié)合實際查詢模式別切出幾十萬個 key 把管理搞癱瘓。6. Sorted Set排行榜、延遲隊列與范圍查詢的關(guān)鍵武器6.1 Score 的含義與排序規(guī)則Sorted SetZSet是 Redis 五種類型里最特別的一個它給每個元素關(guān)聯(lián)了一個 double 類型的 score元素按 score 從小到大排序。如果你有復雜排序需求且同時要求插入性能ZSet 幾乎是唯一選擇。它的排序是穩(wěn)定的score 相同時按元素的字典序member 的字符串順序排列。 ZADD ranking:game 100 playerA 200 playerB 150 playerC (integer) 3 ZRANGE ranking:game 0 -1 WITHSCORES 1) playerA 2) 100 3) playerC 4) 150 5) playerB 6) 200注意 ZRANGE 默認是從小到大取也就是升序。如果你要排行榜從高到低可以用 ZREVRANGE從大到小或者 ZRANGE 加 REV 參數(shù)。很多面試題里會問ZSet 底層是什么答案是跳躍表加哈希表跳表負責排序和范圍查詢哈希表負責 O(1) 查找元素對應的 score。理解這一點你就明白了為什么 ZSet 能做按 score 取排名按排名取元素按 score 區(qū)間取元素三種維度的查詢而且效率都很高。6.2 ZADD/ZSCORE/ZRANK排行榜的完整實現(xiàn)路徑寫一個排行榜功能是 ZSet 的入門實操步驟并不復雜。第一步數(shù)據(jù)寫入。用 ZADD 把玩家 ID 和分數(shù)寫入 ZADD ranking:202401 1000 playerA (integer) 1 ZADD ranking:202401 1200 playerB (integer) 1 ZADD ranking:202401 800 playerC (integer) 1第二步查詢 TopN。用 ZREVRANGE 拿到榜單前三 ZREVRANGE ranking:202401 0 2 WITHSCORES 1) playerB 2) 1200 3) playerA 4) 1000 5) playerC 6) 800第三步給某個玩家加分。用 ZINCRBY 在現(xiàn)有 score 上累加 ZINCRBY ranking:202401 100 playerC 900第四步查某個玩家的排名。ZRANK 返回的是從 0 開始的升序排名ZREVRANK 返回降序排名 ZREVRANK ranking:202401 playerB (integer) 0有了這四步一個帶排名、加分、名次查詢的完整排行榜就通了。我在做排行榜時還會注意一個細節(jié)如果數(shù)據(jù)量很大ZRANGE 全量取出會導致網(wǎng)絡傳輸壓力很大所以接口層必須要分頁。很多新手直接 ZREVRANGE 0 -1 把整個排行榜拖回內(nèi)存再在內(nèi)存里分頁這是非常典型的性能反模式。正確做法是在 Redis 端就用 ZREVRANGE 的 start 和 stop 參數(shù)做分頁只拿當前頁需要的數(shù)據(jù)。6.3 ZSet 做延遲隊列的兩種思路與同分陷阱延遲隊列是 ZSet 的隱藏神技。思路很簡單把任務的執(zhí)行時間戳作為 score消費者用 ZRANGEBYSCORE 去拿到點該執(zhí)行的任務。我常用的實現(xiàn)方式有兩種。方式一輪詢掃描 ZADD delay:queue 1735689600 task:1001 ZRANGEBYSCORE delay:queue 0 1735689600 WITHSCORES LIMIT 0 10用一個后臺線程定時執(zhí)行 ZRANGEBYSCORE把 score 小于當前時間的任務取出來處理完再 ZREM 刪除。這個方案簡單、可控適合任務量不大的場景。方式二阻塞型使用 BZPOPMIN 可以阻塞等待score 最小且已被加入到集合中的元素彈出。但要注意BZPOPMIN 彈出的是整個 ZSet 中 score 最小的元素不是小于某個閾值的所有元素。所以如果你想實現(xiàn)嚴格的延遲隊列更穩(wěn)妥的還是輪詢方式。我再補充一個坑ZSet 的 score 是 double 類型用毫秒時間戳做 score 時精度完全夠但如果你用秒級時間戳同一秒內(nèi)大量任務會落到同一個 scoreZRANGEBYSCORE 的范圍取法就要額外考慮同秒任務的順序否則同一秒的任務你可能只取到一部分。做法是把時間戳精確到毫秒或者在任務里附帶一個自增序號來打破同分競爭。6.4 范圍查詢與冷熱數(shù)據(jù)的分級處理ZSet 里還有一個非常強大的能力就是按 score 范圍做切片查詢ZRANGEBYSCORE min max。做冷熱數(shù)據(jù)分級時可以把數(shù)據(jù)的最近活躍時間作為 score然后按時間窗口切出近期活躍和沉睡用戶。 ZADD active:users 1735689600 u1 ZADD active:users 1735603200 u2 ZRANGEBYSCORE active:users 1735603200 1735689600 1) u2 2) u1這個操作直接回答了哪些用戶在過去 24 小時內(nèi)有活躍行為。相比用時間戳字段去數(shù)據(jù)庫走索引ZSet 的優(yōu)勢是全內(nèi)存、O(log N) 的范圍查找、天然按時間排序。在一些用戶分層、營銷人群圈選的系統(tǒng)里這種用法非常常見。同樣要提醒ZSet 是內(nèi)存結(jié)構(gòu)存幾十萬上百萬元素還好千萬別把全量用戶都塞進一個 ZSet內(nèi)存和寫入壓力扛不住。要按業(yè)務域拆 key例如 active:202401、active:202402每個月一個新 key。6.5 ZSet 與 List、Set 的選擇取舍最后把決策問題講清楚。如果你還不知道某個場景該用 List、Set 還是 ZSet可以按這個思路判斷需要先進先出、按容量剪裁優(yōu)先 List需要唯一性、快速求交并集、隨機抽取優(yōu)先 Set需要按分數(shù)排序、按范圍取 TopN、帶權(quán)重取元素優(yōu)先 ZSet一個很好的類比是List 像排隊打飯的隊伍Set 像一個去重后的集合ZSet 更像一個帶分數(shù)標簽的有序排行榜。它們之間的轉(zhuǎn)換也經(jīng)常出現(xiàn)比如你先用 List 收集了一批待處理任務在去重環(huán)節(jié)轉(zhuǎn)成 Set最終需要按優(yōu)先級執(zhí)行時再轉(zhuǎn)成 ZSet。Redis 類型不是死的關(guān)鍵是每種類型擅長解決什么問題。7. 內(nèi)部編碼、內(nèi)存優(yōu)化與命令選型的經(jīng)驗總結(jié)7.1 五種類型的內(nèi)部編碼對照很多面試題里會問 Redis 的 encoding但實際調(diào)優(yōu)中它也是最有用的信息因為直接決定了內(nèi)存和性能。不同數(shù)據(jù)類型在不同條件下走不同編碼數(shù)據(jù)類型小數(shù)據(jù)量編碼大數(shù)據(jù)量編碼觸發(fā)轉(zhuǎn)換的關(guān)鍵配置Stringint / embstrraw字符串長度超過 44 字節(jié)走 rawHashziplisthashtablehash-max-ziplist-entries / hash-max-ziplist-valueListquicklist內(nèi)含 ziplistquicklistlist-max-ziplist-size / list-compress-depthSetintsethashtableset-max-intset-entriesZSetziplistskiplist dictzset-max-ziplist-entries / zset-max-ziplist-value我并不是建議你去背這些配置而是建議你在內(nèi)存水位異常時用 OBJECT ENCODING key 或 DEBUG OBJECT key 去看一個 key 當前的編碼 OBJECT ENCODING user:1001 ziplist DEBUG OBJECT user:1001 Value at:0x7f9f1c44b920 refcount:1 encoding:ziplist serializedlength:83 lru:4823112 lru_seconds_idle:120如果發(fā)現(xiàn)原本預期走緊湊編碼的 key 變成了 hashtable 或 raw往往是因為某個 value 太大或字段太多觸發(fā)了轉(zhuǎn)換。這時候你該做的不是盲目調(diào)大閾值而是審視數(shù)據(jù)模型是否合理。比如一個 Hash 的 field 漲到上萬個那不該調(diào)高 ziplist 閾值而是應該把大 Hash 拆成多個小 Hash按業(yè)務分桶。7.2 內(nèi)存優(yōu)化從 key 命名到緊湊編碼的三個層次Redis 內(nèi)存優(yōu)化的話題很容易被忽視因為很多人只有當內(nèi)存報警時才想起看但那時已經(jīng)晚了。我給出的優(yōu)化思路有三個層次。第一層控制 key 的數(shù)量與長度。一個 key 的名稱哪怕只多 20 個字節(jié)1000 萬個 key 就多出 200MB 內(nèi)存這還不算哈希表本身的膨脹。所以 key 命名要短而可讀比如 user:1001 而不是 full_user_name:1001:profile_cache:001。我看到過長 key 把內(nèi)存占到 30% 以上的真實案例教訓是命名的長度直接影響內(nèi)存成本。第二層優(yōu)選緊湊編碼。在前面編碼對照表里ziplist、intset、embstr 都是緊湊編碼在數(shù)據(jù)量小時內(nèi)存效率遠高于 hashtable 和 raw。合理設置閾值盡量讓小數(shù)據(jù)保持緊湊形態(tài)。需要提醒的是緊湊編碼下的讀性能未必差只是寫路徑更脆因為寫入可能觸發(fā)編碼轉(zhuǎn)換。所以更建議根據(jù)業(yè)務規(guī)模預估來設置閾值而不是拍腦袋把參數(shù)調(diào)大。第三層利用 key 聚合減少元數(shù)據(jù)開銷。Redis 每個 key 都要維護元數(shù)據(jù)類型、編碼、LRU、引用計數(shù)等key 數(shù)量越多元數(shù)據(jù)開銷越大。把業(yè)務上相關(guān)聯(lián)的子數(shù)據(jù)聚合到一個 Hash/ZSet/Set 里能顯著減少 key 的數(shù)量。比如點贊、收藏、評論三個計數(shù)用一個 Hash 存三個 field比用三個 key 存三個值更省內(nèi)存。但聚合也要有度單 key 過大又會導致讀寫放大所以聚合和拆分要根據(jù)實際訪問模式來平衡。7.3 O(N) 命令的紅線KEYS、HGETALL、SMEMBERS、LRANGERedis 在單線程模型下一個慢命令會阻塞所有其他命令。常用的 O(N) 命令里有幾個經(jīng)典紅線是必須記住的KEYS生產(chǎn)環(huán)境等于自殺千萬別用用 SCAN 代替HGETALL大 Hash 下會阻塞用 HSCAN 或按需 HGETSMEMBERS大 Set 下的全量輸出同理用 SSCANLRANGE大 List 下全量輸出同理按需 LRANGE start stopZRANGE大 ZSet 下全量輸出同理分頁取這里多說一句Redis 會為慢命令記錄 slowlog配置 slowlog-log-slower-than 可以設置閾值。實際排障時我經(jīng)常用 SLOWLOG GET 定位那些拖垮實例的罪魁禍首。建議上線前就把慢日志打開閾值設在 10 毫秒左右生產(chǎn)環(huán)境一旦出現(xiàn)慢查詢就知道誰在搗鬼 SLOWLOG GET 10 1) 1) (integer) 102 2) (integer) 1735689600 3) (integer) 2300 4) SLOWLOG7.4 類型選擇決策表遇到業(yè)務需求先查這張表我把常見業(yè)務需求直接映射到對應的數(shù)據(jù)類型方便你直接抄作業(yè)。這份經(jīng)驗匯總不保證覆蓋所有場景但能覆蓋八成常見需求業(yè)務需求推薦數(shù)據(jù)類型關(guān)鍵命令緩存單值、分布式鎖StringSET / GET / SETNX / SETEX緩存對象、按字段讀寫HashHSET / HGET / HGETALL會話、驗證碼短期存儲StringSETEX / GETDEL最新動態(tài)、時間線ListLPUSH / LTRIM / LRANGE輕量消息隊列ListLPUSH / BRPOP可靠消息隊列Stream或外部 MQXADD / XREADGROUP用戶標簽、去重SetSADD / SISMEMBER / SINTER隨機抽獎SetSPOP / SRANDMEMBER排行榜、TopNZSetZADD / ZINCRBY / ZREVRANGE延遲隊列ZSetZADD / ZRANGEBYSCORE / ZREM全局唯一計數(shù)StringINCR / DECR大規(guī)模存在性判斷RedisBloom布隆過濾器BF.ADD / BF.EXISTS這張表是我做技術(shù)選型時的第一反應表。它不解決這個業(yè)務到底要不要用 Redis的問題只解決確定了用 Redis 之后該用哪個類型的問題。接下來再想清楚 key 生命周期、過期策略、與數(shù)據(jù)庫的一致性整個方案就已經(jīng)成型了一半。7.5 從五大類型到 Stream、Bitmaps、HyperLogLog 的延伸寫完五大類型必須提一句 Redis 不止這五種。官方容易被忽視的還有 Bitmaps、HyperLogLog、Stream、地理空間類型 Geo。它們各有絕活Bitmaps 做在線狀態(tài)統(tǒng)計極省內(nèi)存HyperLogLog 用 12KB 就能做千萬級基數(shù)統(tǒng)計Geo 直接支持附近的人或店鋪查詢Stream 則彌補了 List 做可靠消息隊列的短板。我平時的習慣是先用五大類型解決 80% 的需求再根據(jù)場景引入這些專項類型。它們不是越多越好而是搞清楚每種類型在天平上的位置——內(nèi)存、準確度、實時性、可靠性四個維度分別取舍。8. 實際部署中的幾個翻車現(xiàn)場與搶救記錄8.1 大 Value 引發(fā)的阻塞與拆分真實翻車案例一某個老項目里用一個 String key 存儲了十幾 MB 的 JSON 數(shù)據(jù)啟動時一次性讀取平時基本不更新。結(jié)果某天業(yè)務方大量請求這個 keyRedis 響應突然飆到幾百毫秒。我用 STRLEN 檢查發(fā)現(xiàn) value 已經(jīng)很大又用 SLOWLOG 確認 GET 操作本身就是慢查詢。之所以慢不完全是網(wǎng)絡傳輸問題而是這個 key 的數(shù)據(jù)在 Redis 內(nèi)部要經(jīng)歷序列化、內(nèi)存拷貝、網(wǎng)絡輸出三個階段每個階段都被放大。后來我把這個 String 拆成多個小 key 按字段存儲或者改用 Hash 按字段讀取問題迎刃而解。這里的關(guān)鍵教訓是Redis 不適合存大對象超過幾百 KB 就要拆。真遇到不能拆的比如整存整取的外系統(tǒng)接口數(shù)據(jù)那就做好緩存失效策略和網(wǎng)絡超時并接受延遲上升的事實。8.2 過期策略與內(nèi)存淘汰的組合拳很多人在一個 Redis 實例里同時設置 TTL又開啟了 allkeys-lru 淘汰結(jié)果發(fā)現(xiàn)數(shù)據(jù)早早就被淘汰了總是丟失。這里有兩個機制的名字只差一字但行為截然不同過期機制expire是主動把過期數(shù)據(jù)刪除內(nèi)存淘汰eviction是在內(nèi)存達到 maxmemory 時按策略挑選 key 刪除。如果實例內(nèi)存很小又開了 allkeys-lru那么即使 key 還沒到 TTL也可能被 LRU 策略提前淘汰。解決辦法依據(jù)業(yè)務特點來定緩存型數(shù)據(jù)可以接受淘汰用 volatile-lru 或者 allkeys-lru 都行但像分布式鎖、限流計數(shù)這種狀態(tài)型數(shù)據(jù)絕不能依賴淘汰策略一定要設置合理的 TTL 并考慮持久化。另一個相關(guān)的坑是過期鍵在從庫上不會主動刪除。Redis 主從架構(gòu)里過期鍵的處理是主庫負責刪除然后向從庫發(fā)送 DEL。如果從庫被提升為主庫在舊主庫發(fā)送刪除命令之前從庫上的這些數(shù)據(jù)可能仍然可讀——這是主從切換后偶爾出現(xiàn)臟數(shù)據(jù)的一個原因。要減少這個窗口需要關(guān)注 repl-disable-tcp-nodelay 和同步延遲或者使用 Redis 7 的 WAITAOF 等機制提升數(shù)據(jù)一致性。8.3 用 MEMORY 和 OBJECT 命令做常規(guī)體檢真正的排障高手不會等故障發(fā)生才動手而是定期給 Redis 做體檢。我最常用的三個命令第一個是 MEMORY USAGE key查一個 key 實際占用內(nèi)存 MEMORY USAGE user:1001 (integer) 136第二個是 INFO memory查整體內(nèi)存分布、碎片率 mem_fragmentation_ratio 等 INFO memory # Memory used_memory:826032 used_memory_human:806.67K used_memory_rss:2396160 mem_fragmentation_ratio:2.90碎片率長期大于 1.5 或小于 1都要關(guān)注。大于 1.5 說明內(nèi)存碎片嚴重可以考慮啟用 activedefrag 或通過主從切換來整理小于 1 說明發(fā)生了 swapRedis 開始用磁盤性能會斷崖式下跌。第三個是 OBJECT ENCODING key查編碼是否符合預期。這三個命令組合起來一個 key 大約 10 秒內(nèi)就能完成內(nèi)存占用、碎片情況、編碼狀態(tài)的全面體檢。8.4 連接數(shù)打滿與命令超時的排查鏈路還有一次業(yè)務反饋所有接口都變慢我排查后發(fā)現(xiàn) Redis 連接數(shù)暴漲。連接數(shù)打滿的常見原因有幾個服務端連接池配置過大、客戶端沒有正確歸還連接、慢查詢導致單個連接占用時間過長、空閑連接沒有及時回收。這些原因的排查順序我從實際經(jīng)驗里總結(jié)成一條鏈路先看 deferred 和 rejected 連接數(shù)再用 CLIENT LIST 看連接來源分布再用 SLOWLOG 慢日志看是否有慢命令最后看客戶端連接池的 maxTotal 和 maxIdle 配置。這里特別提一個容易被忽略的點很多客戶端連接池的最大連接數(shù)默認值是大幾千但 Redis 服務端默認 maxclients 只有 10000。當服務實例多、每個實例又用盡連接池時很容易打滿。解決辦法是統(tǒng)一規(guī)劃連接池大小建議每個服務實例的連接數(shù)控制在幾百以內(nèi)并在客戶端配置合理的 minIdle 和 maxIdle避免連接被無意義地占用。另一個維度是給所有 Redis 命令設置合理的超時時間——連接超時設 200ms讀超時設 500ms一旦超時立即熔斷降級而不是無限等待把故障的影響控制在調(diào)用方。9. 寫給新手的幾條實戰(zhàn)心法9.1 先畫數(shù)據(jù)模型再寫命令我見過很多新人一上來就敲命令敲著敲著發(fā)現(xiàn)類型選錯了又要重構(gòu)。正確順序是先畫出業(yè)務數(shù)據(jù)模型——哪些是單值、哪些是對象、哪些是列表、哪些是集合、哪些需要排序然后對著五大類型做映射。這個過程不花 10 分鐘但能省下一天的重構(gòu)時間。畫數(shù)據(jù)模型時我的習慣是隨手寫一個數(shù)據(jù)字典格式很簡單key: user:1001 類型: Hash field: name / age / city / reg_time 用途: 用戶詳情緩存按字段讀取 TTL: 1 小時每個 key 都按這個格式在項目文檔里登記維護成本非常低但團隊協(xié)作時能避免很多這個 key 到底存的啥的口頭溝通。9.2 一套命令走天下還是按需組合Redis 的命令看起來多但常用的命令其實就是二十來個。我對新手的建議是別試圖背全命令但要把核心組合用熟。單值緩存組合SET GET DEL SETNX SETEX EXPIRE對象緩存組合HSET HGET HGETALL HDEL HINCRBY列表組合LPUSH RPOP LRANGE LTRIM LLEN集合組合SADD SREM SISMEMBER SINTER SPOP有序集合組合ZADD ZINCRBY ZRANGE ZREVRANGE ZRANGEBYSCORE每個組合都有自己的慣用法比如LPUSH LTRIM 做最新列表ZADD ZREVRANGE 做排行榜SADD 返回值做去重判斷。把慣用法記熟再配合 SCAN、OBJECT、MEMORY 等運維命令基本就能應對 95% 的開發(fā)場景。9.3 養(yǎng)成三個好習慣TTL、命名規(guī)范、監(jiān)控最后聊聊習慣技術(shù)選型再對習慣不好也會翻車。我總結(jié)成三條缺一不可。第一能設 TTL 一定要設 TTL。緩存型數(shù)據(jù)如果忘了設過期時間一旦數(shù)據(jù)源變化Redis 里的舊數(shù)據(jù)就會一直存在成為僵尸緩存。我見過一個項目所有 key 都沒設置過期時間后來數(shù)據(jù)不一致了排查了一星期最后發(fā)現(xiàn)是緩存沒失效。所有能設 TTL 的 key都應該設 TTL哪怕只是 10 分鐘。第二key 命名要有統(tǒng)一規(guī)范。一個可讀的命名體系能讓你在排障時不用憑空猜。我常用的規(guī)范是業(yè)務域:實體:ID:屬性例如 user:1001:profile:name。這種命名方式的好處是可以通過前綴用 SCAN 掃描出某個業(yè)務域的所有 key監(jiān)控平臺也能按前綴聚合統(tǒng)計。但注意千萬不要用 KEYS 命令去掃生產(chǎn)環(huán)境要用 SCAN。第三監(jiān)控必須前置。至少要有三個指標命中率hit_rate、內(nèi)存使用率、慢查詢數(shù)。命中率低了說明緩存設計有問題內(nèi)存漲了要提前擴容慢查詢多了要立刻排查。對接 Prometheus 加 Grafana 的 redis_exporter 是社區(qū)標配上線前就接好別等出了事故再裝。這三個習慣是零成本高回報的典型。很多人把注意力放在選型和命令上卻忽視了這些基礎工程能力最終在真實故障里付出代價?？梢哉fRedis 用得好不好一大半取決于這三點有沒有做到。我自己的體會是把這五種類型全部用熟只是第一層真正的高手會把它們當作樂高積木一樣自然地組合用 String 存令牌、用 Hash 存對象、用 List 做時間線、用 Set 做去重、用 ZSet 做排序然后在更復雜的場景里疊加 Stream、HyperLogLog 這些進階結(jié)構(gòu)。掌握每個結(jié)構(gòu)最擅長解決的那個問題比死記一百條命令有用得多。最后再分享一個小技巧遇到不確定該用哪種類型的方案先在命令行里用真實數(shù)據(jù)規(guī)模的小樣本跑一遍觀察內(nèi)存和耗時表現(xiàn)再做決定。這種先試驗后落地的習慣能幫你避免很多以為能用、一上線就出問題的大型返工。