1. 從“鍵值對(duì)”到“十大數(shù)據(jù)類型”Redis的進(jìn)化之路提到Redis很多人的第一反應(yīng)就是“緩存”。沒(méi)錯(cuò)它憑借其內(nèi)存級(jí)的讀寫速度和簡(jiǎn)單的鍵值對(duì)模型成為了緩存界的“扛把子”。但如果你對(duì)Redis的認(rèn)知還停留在簡(jiǎn)單的set key value和get key那可能就錯(cuò)過(guò)了它最強(qiáng)大的部分。Redis之所以能從一個(gè)簡(jiǎn)單的緩存中間件進(jìn)化成如今被廣泛認(rèn)可的“數(shù)據(jù)結(jié)構(gòu)服務(wù)器”其核心就在于它提供的豐富數(shù)據(jù)類型。這不僅僅是五個(gè)、八個(gè)而是整整十種內(nèi)置的數(shù)據(jù)結(jié)構(gòu)類型。每一種類型都不是憑空設(shè)計(jì)而是為了解決特定場(chǎng)景下的數(shù)據(jù)建模難題將原本需要在應(yīng)用層通過(guò)復(fù)雜代碼和多次查詢才能實(shí)現(xiàn)的功能內(nèi)化為了原子性的命令操作。我見(jiàn)過(guò)不少項(xiàng)目初期為了圖省事把所有數(shù)據(jù)都序列化成JSON字符串然后一股腦地用String類型存進(jìn)Redis。上線初期相安無(wú)事隨著業(yè)務(wù)增長(zhǎng)各種奇葩需求就來(lái)了“給這個(gè)用戶的積分排個(gè)名”、“統(tǒng)計(jì)一下最近一周登錄過(guò)的用戶”、“把這個(gè)商品列表按價(jià)格排序分頁(yè)給我”……這時(shí)候面對(duì)一堆字符串要么在應(yīng)用層做繁重的計(jì)算拖慢整體性能要么頻繁與數(shù)據(jù)庫(kù)交互失去了緩存的意義。這就是沒(méi)有用對(duì)數(shù)據(jù)類型的典型困境。Redis的十大數(shù)據(jù)類型就是十種應(yīng)對(duì)特定場(chǎng)景的“武器”。理解它們本質(zhì)上是在學(xué)習(xí)如何根據(jù)數(shù)據(jù)的訪問(wèn)模式來(lái)選擇合適的存儲(chǔ)結(jié)構(gòu)從而用最少的資源最高效地滿足業(yè)務(wù)需求。這不僅僅是API調(diào)用的問(wèn)題更是一種數(shù)據(jù)建模和系統(tǒng)設(shè)計(jì)的思維。接下來(lái)我就結(jié)合自己這些年踩過(guò)的坑和總結(jié)的經(jīng)驗(yàn)帶你徹底搞懂這十種類型看看它們各自在什么場(chǎng)景下能發(fā)揮出最大威力。2. 基石類型String字符串的深度解析與實(shí)戰(zhàn)誤區(qū)String是Redis最基本的數(shù)據(jù)類型也是其他所有類型的基石。但千萬(wàn)別小看它“簡(jiǎn)單”往往意味著靈活和高效。一個(gè)Redis字符串value最多可以是512MB這足以存儲(chǔ)一張不小的圖片序列化后的數(shù)據(jù)或一篇長(zhǎng)文章。### 2.1 不只是文本String的二進(jìn)制安全與多功能命令String是二進(jìn)制安全的。這意味著它可以存儲(chǔ)任何數(shù)據(jù)比如序列化的對(duì)象、圖片的字節(jié)流而不僅僅是文本。其核心命令SET、GET、DEL大家都很熟悉但它的威力遠(yuǎn)不止于此。原子計(jì)數(shù)器這是String最經(jīng)典的應(yīng)用之一。INCR、DECR、INCRBY這些命令是原子操作在高并發(fā)場(chǎng)景下無(wú)需加鎖即可實(shí)現(xiàn)精準(zhǔn)計(jì)數(shù)用于文章閱讀量、用戶點(diǎn)贊數(shù)、庫(kù)存扣減等場(chǎng)景再合適不過(guò)。SET article:1001:views 0 INCR article:1001:views # 閱讀量1并發(fā)安全批量操作與過(guò)期管理MSET/MGET用于批量操作減少網(wǎng)絡(luò)開(kāi)銷。SETEX、PSETEX可以在設(shè)值的同時(shí)設(shè)置過(guò)期時(shí)間秒/毫秒級(jí)是實(shí)現(xiàn)緩存失效的標(biāo)配。位操作BitMap這是String類型一個(gè)隱藏的“大招”。通過(guò)SETBIT、GETBIT、BITCOUNT、BITOP等命令你可以把String當(dāng)作一個(gè)巨大的位數(shù)組來(lái)操作。每個(gè)用戶ID對(duì)應(yīng)一個(gè)偏移量只需一個(gè)比特位就能標(biāo)記其狀態(tài)如是否簽到、是否在線極大地節(jié)省了內(nèi)存。# 記錄用戶uid1001在2023-10-01是否簽到假設(shè)該日期偏移量為365 SETBIT sign:2023:10:01 1001 1 # 檢查是否簽到 GETBIT sign:2023:10:01 1001 # 統(tǒng)計(jì)當(dāng)天簽到總?cè)藬?shù) BITCOUNT sign:2023:10:01### 2.2 實(shí)戰(zhàn)避坑濫用String與序列化陷阱String雖然萬(wàn)能但濫用就是最大的坑。誤區(qū)一萬(wàn)物皆可JSON String。這是最常見(jiàn)的反模式。比如存儲(chǔ)一個(gè)用戶信息{“name”: “張三”, “age”: 30}用String存儲(chǔ)后如果你想修改年齡必須GET回來(lái)在應(yīng)用層反序列化、修改、再序列化、最后SET回去。這個(gè)過(guò)程涉及網(wǎng)絡(luò)IO和序列化開(kāi)銷且非原子性。更合適的做法是使用Hash類型。誤區(qū)二忽略過(guò)期時(shí)間導(dǎo)致內(nèi)存泄漏。用Redis作緩存一定要設(shè)置合理的過(guò)期時(shí)間TTL。我曾經(jīng)排查過(guò)一個(gè)線上問(wèn)題Redis內(nèi)存持續(xù)增長(zhǎng)直至寫滿觸發(fā)淘汰原因就是大量緩存鍵未設(shè)置TTL變成了“永久緩存”。使用EXPIRE命令或直接在SET時(shí)用EX/PX選項(xiàng)是必須養(yǎng)成的習(xí)慣。誤區(qū)三大Key問(wèn)題。如果一個(gè)String的value非常大比如幾百KB甚至上MB在對(duì)其進(jìn)行GET、SET甚至過(guò)期刪除時(shí)會(huì)導(dǎo)致主線程阻塞影響其他命令的執(zhí)行。對(duì)于大文本或大對(duì)象需要考慮是否應(yīng)該拆分或者使用其他更適合的結(jié)構(gòu)。String是入口但絕非終點(diǎn)。當(dāng)你發(fā)現(xiàn)自己在用String存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)或需要復(fù)雜操作時(shí)就該考慮下面這些更專業(yè)的類型了。3. 結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)首選Hash哈希的精細(xì)化管理之道當(dāng)你的數(shù)據(jù)是一個(gè)對(duì)象Object擁有多個(gè)字段Field時(shí)Hash類型就是為你量身定做的。它類似于編程語(yǔ)言中的MapString, String適合存儲(chǔ)一個(gè)實(shí)體的多個(gè)屬性比如用戶、商品、配置項(xiàng)。### 3.1 Hash的核心優(yōu)勢(shì)原子操作與內(nèi)存效率與將整個(gè)對(duì)象序列化成String相比Hash有兩個(gè)壓倒性優(yōu)勢(shì)原子性字段操作你可以單獨(dú)對(duì)某個(gè)字段進(jìn)行HSET、HGET、HINCRBY而無(wú)需讀寫整個(gè)對(duì)象。這對(duì)于頻繁更新部分字段的場(chǎng)景如更新用戶最后登錄時(shí)間、增加商品庫(kù)存性能提升巨大且是原子性的。內(nèi)存優(yōu)化Redis的Hash在元素較少時(shí)采用一種稱為ziplist壓縮列表的緊湊編碼方式比將每個(gè)字段分開(kāi)存儲(chǔ)成獨(dú)立的String鍵要節(jié)省大量?jī)?nèi)存。這對(duì)于存儲(chǔ)海量小對(duì)象如用戶會(huì)話、商品SKU屬性至關(guān)重要。# 存儲(chǔ)一個(gè)用戶信息 HSET user:1001 name “張三” age 30 city “北京” # 單獨(dú)獲取年齡 HGET user:1001 age # 原子性地增加年齡 HINCRBY user:1001 age 1 # 獲取所有字段和值 HGETALL user:1001### 3.2 場(chǎng)景對(duì)比與使用邊界Hash并非沒(méi)有缺點(diǎn)。HGETALL命令在字段非常多時(shí)會(huì)返回一個(gè)巨大的回復(fù)可能阻塞客戶端。此時(shí)可以使用HSCAN進(jìn)行漸進(jìn)式遍歷。另外Hash不支持直接對(duì)內(nèi)部的多個(gè)field進(jìn)行范圍查詢或排序這是它的設(shè)計(jì)邊界。那么何時(shí)用String何時(shí)用Hash用String數(shù)據(jù)是一個(gè)不可分割的整體讀寫總是以整個(gè)單位進(jìn)行如緩存一個(gè)完整的HTML頁(yè)面、一個(gè)序列化的配置對(duì)象?；蛘咝枰玫絊tring特有的位圖、計(jì)數(shù)器功能。用Hash數(shù)據(jù)是結(jié)構(gòu)化的你需要頻繁地、獨(dú)立地訪問(wèn)或修改其中的部分字段。典型場(chǎng)景就是各種“對(duì)象”的緩存用戶會(huì)話Session、商品信息、文章元數(shù)據(jù)等。一個(gè)經(jīng)驗(yàn)法則是如果你在應(yīng)用層代碼里經(jīng)常需要從一個(gè)大JSON字符串中解析出某個(gè)特定字段那么是時(shí)候改用Hash了。4. 有序集合與列表List與Sorted Set的排序藝術(shù)當(dāng)數(shù)據(jù)需要體現(xiàn)順序時(shí)List和Sorted Set就該登場(chǎng)了。它們都維護(hù)著元素的順序但實(shí)現(xiàn)方式和適用場(chǎng)景截然不同。### 4.1 List列表靈活的雙端隊(duì)列與消息隊(duì)列Redis的List是一個(gè)雙向鏈表這意味著在頭部和尾部進(jìn)行插入刪除操作的時(shí)間復(fù)雜度是O(1)非常高效。它的核心能力是序列和排隊(duì)。消息隊(duì)列簡(jiǎn)易版利用LPUSH生產(chǎn)消息和BRPOP阻塞式消費(fèi)消息可以構(gòu)建一個(gè)簡(jiǎn)單的消息隊(duì)列。BRPOP在沒(méi)有元素時(shí)會(huì)阻塞連接避免了消費(fèi)者輪詢的空轉(zhuǎn)消耗。# 生產(chǎn)者 LPUSH myqueue “task1” # 消費(fèi)者阻塞等待超時(shí)時(shí)間5秒 BRPOP myqueue 5注意這只是一個(gè)基礎(chǔ)模型。對(duì)于需要ACK、重試、死信隊(duì)列等復(fù)雜功能的場(chǎng)景建議使用專業(yè)的消息中間件如RabbitMQ或Kafka。Redis Stream類型后面會(huì)講到也是一個(gè)更強(qiáng)大的選擇。最新列表LPUSHLTRIM是一個(gè)經(jīng)典組合可以輕松實(shí)現(xiàn)一個(gè)固定長(zhǎng)度的最新動(dòng)態(tài)列表比如網(wǎng)站的最新100條評(píng)論。LPUSH latest:comments “評(píng)論C” LTRIM latest:comments 0 99 # 永遠(yuǎn)只保留最新的100條實(shí)戰(zhàn)坑點(diǎn)List的索引訪問(wèn)LINDEX效率是O(N)性能隨列表長(zhǎng)度線性下降切忌用它來(lái)實(shí)現(xiàn)隨機(jī)訪問(wèn)。它的優(yōu)勢(shì)在于頭尾操作和范圍獲取LRANGE。### 4.2 Sorted Set有序集合排行榜與范圍查詢的利器如果說(shuō)List是按插入順序排序那么Sorted Set就是按一個(gè)顯式的分?jǐn)?shù)Score來(lái)排序。它是Redis數(shù)據(jù)類型中最具特色的之一結(jié)合了Set的去重性和按分?jǐn)?shù)排序的能力。核心數(shù)據(jù)結(jié)構(gòu)每個(gè)元素都是一個(gè)成員Member- 分?jǐn)?shù)Score對(duì)。成員唯一分?jǐn)?shù)用于排序雙精度浮點(diǎn)數(shù)。分?jǐn)?shù)可以相同此時(shí)按成員的字典序排序。排行榜實(shí)現(xiàn)這是Sorted Set的“殺手級(jí)”應(yīng)用。無(wú)論是游戲積分榜、商品銷量榜還是熱門文章列表都能輕松應(yīng)對(duì)。ZADD leaderboard 95 “Alice” 87 “Bob” 95 “Charlie” ZREVRANGE leaderboard 0 2 WITHSCORES # 獲取前三名降序 ZRANK leaderboard “Bob” # 獲取Bob的排名升序排名范圍查詢Range Query你可以高效地獲取分?jǐn)?shù)在某個(gè)區(qū)間內(nèi)的所有成員ZRANGEBYSCORE。這可以用來(lái)實(shí)現(xiàn)諸如“查找價(jià)格在100到200之間的所有商品ID”、“獲取昨天下午3點(diǎn)到5點(diǎn)所有在線用戶”等功能。集合運(yùn)算ZUNIONSTORE、ZINTERSTORE可以對(duì)多個(gè)有序集合進(jìn)行并集、交集計(jì)算并將結(jié)果存為新集合。例如可以計(jì)算同時(shí)出現(xiàn)在“一周熱門”和“本月熱門”兩個(gè)榜單中的文章。Sorted Set的內(nèi)部實(shí)現(xiàn)是跳躍表SkipList和哈希表的結(jié)合保證了范圍查詢和單點(diǎn)查詢的高效。它的一個(gè)高級(jí)用法是將時(shí)間戳作為分?jǐn)?shù)成員作為事件ID這樣就可以構(gòu)建一個(gè)時(shí)間軸或延遲隊(duì)列。5. 去重與集合運(yùn)算Set的基礎(chǔ)與高級(jí)玩法Set集合是一個(gè)無(wú)序的、元素唯一的容器。它的基礎(chǔ)應(yīng)用是去重但它的集合運(yùn)算能力才是真正的價(jià)值所在。### 5.1 基礎(chǔ)去重與隨機(jī)元素去重快速判斷一個(gè)元素是否存在SISMEMBER或存儲(chǔ)一個(gè)不重復(fù)的集合如文章的標(biāo)簽、用戶的所有好友ID。SADD article:1001:tags “數(shù)據(jù)庫(kù)” “緩存” “Redis” SISMEMBER article:1001:tags “緩存” # 返回1表示存在隨機(jī)抽取SRANDMEMBER或SPOP彈出命令非常適合實(shí)現(xiàn)抽獎(jiǎng)、隨機(jī)推薦等場(chǎng)景。例如從所有參與活動(dòng)的用戶中隨機(jī)抽取10名幸運(yùn)者。# 假設(shè) sadd activity:users user1 user2 ... user10000 SRANDMEMBER activity:users 10 # 抽取10個(gè)不重復(fù)的用戶不刪除 SPOP activity:users 10 # 抽取10個(gè)用戶并從集合中移除### 5.2 強(qiáng)大的集合運(yùn)算社交關(guān)系與數(shù)據(jù)過(guò)濾Set的SINTER交集、SUNION并集、SDIFF差集命令為復(fù)雜的數(shù)據(jù)關(guān)系查詢提供了原子性的解決方案。共同關(guān)注/好友在社交網(wǎng)絡(luò)中查找A和B的共同好友就是計(jì)算兩個(gè)用戶好友集合的交集。SINTER friends:user:A friends:user:B興趣標(biāo)簽推薦計(jì)算擁有相似標(biāo)簽的用戶。可以先找出與目標(biāo)用戶標(biāo)簽集合交集最大的其他用戶。數(shù)據(jù)過(guò)濾假設(shè)有一個(gè)“黑名單IP”集合和一個(gè)“今日訪問(wèn)IP”集合SDIFF可以快速找出不在黑名單中的訪問(wèn)IP。這些運(yùn)算在服務(wù)端原子性完成避免了在應(yīng)用層進(jìn)行多次查詢和循環(huán)比對(duì)性能極高。但需要注意當(dāng)參與運(yùn)算的集合非常大時(shí)這些命令可能會(huì)比較耗時(shí)在阻塞Redis主線程。對(duì)于大數(shù)據(jù)集可以考慮使用SSCAN迭代并結(jié)合客戶端計(jì)算或者將結(jié)果緩存起來(lái)。6. 地理空間與基數(shù)統(tǒng)計(jì)Geo與HyperLogLog的專項(xiàng)突破Redis在后續(xù)版本中引入了更專門化的數(shù)據(jù)類型用于解決特定領(lǐng)域的高頻問(wèn)題。### 6.1 Geo地理空間索引附近的人與地點(diǎn)搜索Geo本質(zhì)上是使用Sorted SetZSET的一種特殊封裝將二維的地理坐標(biāo)經(jīng)緯度通過(guò)Geohash算法編碼成一維的分?jǐn)?shù)Score從而利用ZSET的有序特性實(shí)現(xiàn)附近位置的查詢。核心命令GEOADD添加地理位置GEODIST計(jì)算兩點(diǎn)距離GEORADIUS/GEORADIUSBYMEMBER查詢指定半徑內(nèi)的元素。GEOADD restaurants 116.404 39.915 “全聚德” 116.408 39.920 “東來(lái)順” GEORADIUS restaurants 116.405 39.915 5 km WITHDIST # 查找5公里內(nèi)的餐廳并返回距離實(shí)現(xiàn)原理理解其基于ZSET實(shí)現(xiàn)很重要。這意味著你可以用ZREM刪除一個(gè)地點(diǎn)用ZRANGE查看所有地點(diǎn)雖然沒(méi)意義但更重要的是你可以利用ZSET的所有特性。例如給每個(gè)地點(diǎn)附帶一個(gè)“熱度”分?jǐn)?shù)然后按距離和熱度進(jìn)行綜合查詢這需要一些客戶端計(jì)算。精度與性能Geo的精度對(duì)于大多數(shù)LBS應(yīng)用如附近商家、打車已經(jīng)足夠。它的性能遠(yuǎn)高于在關(guān)系數(shù)據(jù)庫(kù)中用ST_Distance_Sphere函數(shù)進(jìn)行計(jì)算。但要注意數(shù)據(jù)量極大上千萬(wàn)時(shí)范圍查詢的復(fù)雜度是O(NlogM)仍需評(píng)估性能。### 6.2 HyperLogLog基數(shù)統(tǒng)計(jì)海量數(shù)據(jù)去重計(jì)數(shù)HyperLogLog是一種概率數(shù)據(jù)結(jié)構(gòu)用于估算一個(gè)集合中不重復(fù)元素的數(shù)量基數(shù)。它的最大優(yōu)勢(shì)是占用空間極小且固定。一個(gè)HyperLogLog鍵只需要約12KB內(nèi)存就能以標(biāo)準(zhǔn)誤差小于1%的精度統(tǒng)計(jì)接近2^64個(gè)不同元素的基數(shù)典型場(chǎng)景統(tǒng)計(jì)一個(gè)大型網(wǎng)站每日的獨(dú)立訪客數(shù)UV。如果使用Set來(lái)存儲(chǔ)每個(gè)用戶的ID對(duì)于億級(jí)用戶量?jī)?nèi)存消耗是災(zāi)難性的。而使用HyperLogLog每天只需要12KB。PFADD uv:2023-10-01 “user_id_1” “user_id_2” “user_id_1” # 添加元素自動(dòng)去重 PFCOUNT uv:2023-10-01 # 估算當(dāng)天的UV PFMERGE uv:2023-10-week1 uv:2023-10-01 uv:2023-10-02 # 合并多天的數(shù)據(jù)估算整周的UV重要限制HyperLogLog只提供計(jì)數(shù)無(wú)法獲取具體的元素內(nèi)容也無(wú)法判斷某個(gè)特定元素是否已經(jīng)添加過(guò)。它只回答“大約有多少個(gè)不重復(fù)的元素”這個(gè)問(wèn)題。對(duì)于需要精確去重或獲取明細(xì)的場(chǎng)景它不適用。實(shí)戰(zhàn)心得PFADD和PFCOUNT都是非常快的O(1)操作。合并多個(gè)HLLPFMERGE也是高效的。它通常用于替代那些“只需要一個(gè)大概數(shù)字”的Set場(chǎng)景是節(jié)省內(nèi)存的神器。7. 位圖與流Bitmap與Stream的擴(kuò)展應(yīng)用這兩種類型可以看作是基礎(chǔ)類型的威力加強(qiáng)版分別擴(kuò)展了String和List的能力邊界。### 7.1 Bitmap位圖極致的空間利用如前文在String類型中提到的Bitmap是通過(guò)String類型的位操作命令實(shí)現(xiàn)的。但它解決的問(wèn)題如此典型以至于我們常常將其視為一個(gè)獨(dú)立的數(shù)據(jù)類型。它的核心價(jià)值在于用最小的空間表示大量的布爾狀態(tài)。用戶行為標(biāo)記除了簽到還可以用于記錄用戶是否閱讀過(guò)某條消息、是否擁有某項(xiàng)權(quán)限、是否完成某個(gè)新手任務(wù)等。每個(gè)用戶只需要一個(gè)比特位。大數(shù)據(jù)量下的特征篩選假設(shè)有1億用戶需要篩選出“女性”且“活躍”的用戶?？梢詣?chuàng)建兩個(gè)Bitmap一個(gè)標(biāo)記性別一個(gè)標(biāo)記活躍狀態(tài)。通過(guò)BITOP命令對(duì)兩個(gè)位圖進(jìn)行AND運(yùn)算得到的結(jié)果位圖中值為1的位對(duì)應(yīng)的用戶ID就是目標(biāo)用戶。這個(gè)操作的速度極快且內(nèi)存消耗極小1億用戶約需12.5MB。SETBIT gender:female 1001 1 SETBIT active:20231001 1001 1 BITOP AND result:target gender:female active:20231001 GETBIT result:target 1001 # 結(jié)果為1表示用戶1001符合條件注意事項(xiàng)Bitmap的偏移量offset是整數(shù)。如果你的用戶ID不是連續(xù)的整數(shù)需要建立一個(gè)從用戶ID到偏移量的映射關(guān)系這可能會(huì)增加一些復(fù)雜度。通?？梢允褂糜脩鬒D的自增主鍵部分作為偏移量。### 7.2 Stream流完善的消息隊(duì)列與事件溯源Redis 5.0引入的Stream類型旨在彌補(bǔ)List作為消息隊(duì)列時(shí)的功能缺失提供了一個(gè)完整的、支持多消費(fèi)者組的、可持久化的消息隊(duì)列解決方案。核心概念消息Stream中的一條記錄包含一個(gè)唯一的ID通常由時(shí)間戳-序列號(hào)組成和多個(gè)鍵值對(duì)字段。消費(fèi)者組允許多個(gè)消費(fèi)者共同消費(fèi)同一個(gè)Stream組內(nèi)消費(fèi)者負(fù)載均衡每條消息只會(huì)被組內(nèi)的一個(gè)消費(fèi)者處理。Pending List已投遞給消費(fèi)者但尚未被確認(rèn)ACK的消息列表用于處理消費(fèi)失敗后的重試。與List的對(duì)比特性List (LPUSH/BRPOP)Stream消息回溯消費(fèi)后即刪除無(wú)法重現(xiàn)消息持久化可重復(fù)讀取多消費(fèi)者一個(gè)消息只能被一個(gè)消費(fèi)者獲取支持消費(fèi)者組組內(nèi)競(jìng)爭(zhēng)消費(fèi)確認(rèn)機(jī)制無(wú)彈出即視為成功有顯式ACK機(jī)制失敗可重投阻塞訂閱支持支持功能更豐富功能完整性簡(jiǎn)單完整支持消息ID范圍查詢、監(jiān)控等# 生產(chǎn)者添加消息 XADD mystream * user “Alice” action “l(fā)ogin” # 創(chuàng)建消費(fèi)者組 XGROUP CREATE mystream mygroup 0 # 消費(fèi)者從組內(nèi)讀取消息 XREADGROUP GROUP mygroup consumer1 COUNT 1 STREAMS mystream # 消費(fèi)者確認(rèn)消息處理完成 XACK mystream mygroup message-id適用場(chǎng)景Stream非常適合需要可靠消息傳遞、順序性、且希望用Redis統(tǒng)一技術(shù)棧的場(chǎng)景。例如用戶活動(dòng)追蹤Event Sourcing、微服務(wù)間的異步通信、日志收集等。它比List更可靠但比Kafka、RabbitMQ等專業(yè)消息隊(duì)列更輕量功能上也有所取舍。8. 概率去重與地理圍欄Bloom Filter的客戶端實(shí)現(xiàn)與GEO進(jìn)階除了內(nèi)置類型Redis還可以通過(guò)模塊或客戶端算法支持更多高級(jí)數(shù)據(jù)結(jié)構(gòu)。其中布隆過(guò)濾器的應(yīng)用尤為廣泛。### 8.1 Bloom Filter布隆過(guò)濾器存在性校驗(yàn)的守門員Redis自身沒(méi)有內(nèi)置Bloom Filter但可以通過(guò)RedisBloom模塊或直接在客戶端利用Bitmap實(shí)現(xiàn)。它的作用是以極小的空間代價(jià)快速判斷一個(gè)元素“一定不存在”或“可能存在”于一個(gè)超大集合中。工作原理使用多個(gè)哈希函數(shù)將一個(gè)元素映射到位數(shù)組Bitmap的多個(gè)位置上并將這些位置置為1。查詢時(shí)如果該元素對(duì)應(yīng)的所有位置都是1則它“可能存在”如果任何一個(gè)位置是0則它“一定不存在”。典型應(yīng)用緩存穿透防護(hù)在查詢數(shù)據(jù)庫(kù)前先用Bloom Filter判斷鍵是否存在。如果Bloom Filter說(shuō)“不存在”則直接返回空避免對(duì)數(shù)據(jù)庫(kù)的無(wú)效查詢。因?yàn)锽loom Filter不會(huì)漏報(bào)不存在的一定會(huì)判否所以能有效攔截惡意的不存在Key請(qǐng)求。推薦去重在新聞推薦中判斷一篇新文章是否已經(jīng)推薦給過(guò)某個(gè)用戶。使用Bloom Filter可以快速過(guò)濾掉絕大部分已讀文章只在“可能存在”的情況下才去查詢精確的已讀記錄庫(kù)大幅降低查詢壓力。實(shí)現(xiàn)方式服務(wù)端模塊加載RedisBloom模塊后可以使用BF.ADD、BF.EXISTS等命令最為方便?？蛻舳怂惴˙itmap在應(yīng)用層實(shí)現(xiàn)哈希和位運(yùn)算將Redis的Bitmap作為存儲(chǔ)介質(zhì)。這種方式更靈活但需要自己維護(hù)。重要缺陷Bloom Filter有誤判率False Positive即可能將不存在的元素誤判為存在。誤判率可以通過(guò)增加位數(shù)組大小和使用更多哈希函數(shù)來(lái)降低但無(wú)法消除。因此它只適用于那些可以接受偶爾誤判、但對(duì)“不存在”的判斷要求絕對(duì)準(zhǔn)確的場(chǎng)景。### 8.2 GEO的進(jìn)階思考距離計(jì)算與范圍查詢的代價(jià)雖然Geo用起來(lái)很簡(jiǎn)單但在設(shè)計(jì)大規(guī)模LBS系統(tǒng)時(shí)還需要考慮更深層次的問(wèn)題距離計(jì)算負(fù)載GEORADIUS命令在查詢時(shí)需要計(jì)算中心點(diǎn)與集合內(nèi)每個(gè)點(diǎn)的距離。當(dāng)集合內(nèi)元素?cái)?shù)量巨大例如全球所有店鋪時(shí)即使使用地理哈希預(yù)先篩選計(jì)算量依然可觀。常見(jiàn)的優(yōu)化策略是分級(jí)索引例如先按國(guó)家、城市等大范圍篩選出一個(gè)子集再在這個(gè)子集上執(zhí)行精確的Geo查詢。結(jié)果排序與分頁(yè)GEORADIUS默認(rèn)返回所有結(jié)果如果范圍內(nèi)元素很多返回的數(shù)據(jù)量會(huì)很大。雖然可以用COUNT選項(xiàng)限制但分頁(yè)是個(gè)難題因?yàn)槊看尾樵兊姆秶枪潭ǖ膫鹘y(tǒng)的LIMIT offset, count模式在這里不適用除非配合SCAN。一種做法是先獲取所有元素的ID和距離在客戶端進(jìn)行排序和分頁(yè)但這會(huì)帶來(lái)額外的網(wǎng)絡(luò)和計(jì)算開(kāi)銷。動(dòng)態(tài)位置更新對(duì)于移動(dòng)對(duì)象如車輛、外賣員位置頻繁更新。頻繁調(diào)用GEOADD更新坐標(biāo)是可行的但要注意這本質(zhì)上是ZADD操作。如果對(duì)象數(shù)量極多更新頻率極高可能會(huì)對(duì)Redis造成寫入壓力。需要根據(jù)業(yè)務(wù)容忍度適當(dāng)降低位置更新的頻率。理解這些底層細(xì)節(jié)能幫助你在享受Redis Geo便利的同時(shí)提前規(guī)避性能瓶頸設(shè)計(jì)出更健壯的LBS服務(wù)。9. 類型選擇決策樹(shù)與混合使用策略面對(duì)十種類型如何選擇我總結(jié)了一個(gè)簡(jiǎn)單的決策流程可以幫你快速定位方向需要存儲(chǔ)一個(gè)簡(jiǎn)單的值或計(jì)數(shù)器嗎-String需要存儲(chǔ)一個(gè)對(duì)象多個(gè)字段嗎-Hash需要維護(hù)一個(gè)有序的序列且經(jīng)常從兩端操作嗎-List需要去重或者做集合運(yùn)算交集、并集嗎-Set需要按某個(gè)分?jǐn)?shù)排序或者按分?jǐn)?shù)范圍查詢嗎-Sorted Set需要處理地理位置和附近搜索嗎-Geo需要估算海量數(shù)據(jù)的唯一值數(shù)量嗎-HyperLogLog需要記錄大量的布爾狀態(tài)是/否嗎-Bitmap需要可靠的消息隊(duì)列或多消費(fèi)者流處理嗎-Stream然而真實(shí)的業(yè)務(wù)場(chǎng)景往往更復(fù)雜混合使用多種類型才是高級(jí)玩法。例如場(chǎng)景實(shí)現(xiàn)一個(gè)帶點(diǎn)贊計(jì)數(shù)的文章評(píng)論列表并按熱度排序。評(píng)論列表使用List存儲(chǔ)每條評(píng)論的IDLPUSH保證時(shí)間序。評(píng)論內(nèi)容使用Hash存儲(chǔ)評(píng)論ID到詳細(xì)內(nèi)容作者、正文、時(shí)間的映射。點(diǎn)贊數(shù)使用String計(jì)數(shù)器或Hash中的字段鍵名為comment:點(diǎn)贊數(shù)。點(diǎn)贊用戶記錄防重復(fù)點(diǎn)贊使用Set鍵名為comment:liked_users存儲(chǔ)點(diǎn)贊用戶ID。評(píng)論熱度榜使用Sorted Set成員是評(píng)論ID分?jǐn)?shù)是點(diǎn)贊數(shù)或一個(gè)綜合熱度分點(diǎn)贊數(shù)時(shí)間衰減。每當(dāng)有點(diǎn)贊事件更新對(duì)應(yīng)評(píng)論ID的分?jǐn)?shù)。通過(guò)這種組合你可以高效地實(shí)現(xiàn)列表分頁(yè)獲取、單條評(píng)論詳情讀取、點(diǎn)贊的原子操作和熱度排序所有操作都在Redis內(nèi)完成極大地減輕了數(shù)據(jù)庫(kù)的壓力。10. 性能、內(nèi)存與持久化類型選擇背后的工程考量選擇了正確的類型并不意味著萬(wàn)事大吉。在工程實(shí)踐中你必須關(guān)注它們對(duì)性能和內(nèi)存的影響。### 10.1 內(nèi)存編碼的奧秘ziplist, intset, skiplistRedis為了節(jié)省內(nèi)存對(duì)小尺寸的數(shù)據(jù)結(jié)構(gòu)采用了特殊的緊湊編碼方式Hash/List/ZSet元素較少時(shí)會(huì)采用ziplist壓縮列表編碼將所有元素緊湊地存儲(chǔ)在一起。Set元素較少且均為整數(shù)時(shí)會(huì)采用intset整數(shù)集合編碼。當(dāng)元素?cái)?shù)量或大小超過(guò)配置的閾值時(shí)它們會(huì)轉(zhuǎn)換為標(biāo)準(zhǔn)的hashtable、linkedlist、skiplist等結(jié)構(gòu)。通過(guò)OBJECT ENCODING key命令可以查看一個(gè)鍵的內(nèi)部編碼。理解這一點(diǎn)很重要盲目追求“小”可能適得其反。如果你為了利用ziplist而刻意將一個(gè)大Hash拆分成無(wú)數(shù)個(gè)tiny hash反而會(huì)因?yàn)楣芾泶罅挎I的元數(shù)據(jù)而浪費(fèi)更多內(nèi)存。需要根據(jù)實(shí)際數(shù)據(jù)規(guī)模和訪問(wèn)模式調(diào)整redis.conf中如hash-max-ziplist-entries等參數(shù)找到最佳平衡點(diǎn)。### 10.2 大Key與熱Key的監(jiān)控與治理大Key通常指value size過(guò)大如10KB的String 元素?cái)?shù)量5000的Hash/Set/ZSet的Key。大Key會(huì)導(dǎo)致DEL命令阻塞、網(wǎng)絡(luò)傳輸慢、內(nèi)存分配不均等問(wèn)題。可以使用redis-cli --bigkeys掃描或通過(guò)MEMORY USAGE命令分析。治理方法包括拆分如將大Hash按字段前綴拆成多個(gè)小Hash、壓縮客戶端壓縮value、使用更適合的數(shù)據(jù)結(jié)構(gòu)如用HyperLogLog替代大Set做基數(shù)統(tǒng)計(jì)。熱Key指訪問(wèn)頻率非常高的Key。熱Key會(huì)造成單實(shí)例負(fù)載過(guò)高成為性能瓶頸。監(jiān)控可以通過(guò)redis-cli --hotkeys需開(kāi)啟maxmemory-policy為L(zhǎng)FU或分析慢查詢?nèi)罩尽＝鉀Q方案包括本地緩存如Guava Cache、讀寫分離、使用Redis Cluster將熱Key通過(guò)hash tag強(qiáng)制分配到獨(dú)立slot等。### 10.3 持久化與數(shù)據(jù)安全數(shù)據(jù)類型的選擇不影響RDB或AOF持久化機(jī)制但會(huì)影響持久化文件的大小和恢復(fù)速度。例如一個(gè)包含百萬(wàn)成員的Set其AOF日志文件會(huì)記錄大量的SADD命令。在極端情況下考慮禁用某些重寫成本高昂的命令。更重要的是無(wú)論使用何種類型都要理解SAVE/BGSAVERDB快照和appendfsyncAOF刷盤策略的配置根據(jù)業(yè)務(wù)對(duì)數(shù)據(jù)安全性和性能的要求做出權(quán)衡。通常建議同時(shí)開(kāi)啟RDB和AOF用RDB做冷備用AOF保證數(shù)據(jù)完整性。11. 從命令到設(shè)計(jì)數(shù)據(jù)類型在真實(shí)架構(gòu)中的角色讓我們看一個(gè)更綜合的案例設(shè)計(jì)一個(gè)簡(jiǎn)易的社交網(wǎng)絡(luò)“關(guān)注/粉絲”與“動(dòng)態(tài)推送”系統(tǒng)。關(guān)系存儲(chǔ)Set類型存儲(chǔ)關(guān)注列表和粉絲列表followings:user:{uid}和followers:user:{uid}。SADD/SREM用于添加/取消關(guān)注SCARD用于獲取數(shù)量SINTER用于計(jì)算共同關(guān)注。動(dòng)態(tài)發(fā)布與推送寫擴(kuò)散當(dāng)用戶發(fā)布一條動(dòng)態(tài)時(shí)除了存入數(shù)據(jù)庫(kù)我們執(zhí)行LPUSH將動(dòng)態(tài)ID寫入自己的動(dòng)態(tài)列表posts:user:{uid}。獲取自己的所有粉絲ID從followers:user:{uid}。對(duì)每個(gè)粉絲ID執(zhí)行LPUSH dynamic:feed:{follower_uid}將動(dòng)態(tài)ID推送到他們的個(gè)人Feed流中。這里每個(gè)用戶的Feed流就是一個(gè)List。這種“寫擴(kuò)散”模式讀性能極佳直接LRANGE分頁(yè)但寫操作成本高適合粉絲數(shù)不多的場(chǎng)景如普通社交。動(dòng)態(tài)拉取讀擴(kuò)散對(duì)于粉絲數(shù)巨大的大V采用“讀擴(kuò)散”。發(fā)布動(dòng)態(tài)時(shí)只存入一個(gè)全局的Sorted Set中分?jǐn)?shù)為發(fā)布時(shí)間戳ZADD global:posts timestamp post_id。當(dāng)用戶查看Feed時(shí)系統(tǒng)需要獲取他的關(guān)注列表followings:user:{uid}。對(duì)這些關(guān)注用戶的ID執(zhí)行ZUNIONSTORE合并他們發(fā)布的動(dòng)態(tài)可以預(yù)先為每個(gè)用戶維護(hù)一個(gè)Sorted Setposts:user:{uid}。從合并后的臨時(shí)Sorted Set中按分?jǐn)?shù)倒序分頁(yè)獲取動(dòng)態(tài)ID。這種模式寫輕讀重適合粉絲量巨大的場(chǎng)景但需要更復(fù)雜的聚合邏輯且可能用到ZUNIONSTORE這種較重命令。熱點(diǎn)動(dòng)態(tài)排行使用一個(gè)全局的Sorted Set如hot:posts成員是動(dòng)態(tài)ID分?jǐn)?shù)是熱度值點(diǎn)贊數(shù)權(quán)重 評(píng)論數(shù)權(quán)重 時(shí)間衰減。每當(dāng)有點(diǎn)贊、評(píng)論事件就更新對(duì)應(yīng)動(dòng)態(tài)的分?jǐn)?shù)。首頁(yè)的熱榜直接從這個(gè)ZSet中獲取。在這個(gè)案例中Set、List、Sorted Set各司其職共同構(gòu)建了核心功能。選擇“寫擴(kuò)散”還是“讀擴(kuò)散”就是根據(jù)數(shù)據(jù)模型用戶粉絲量對(duì)讀寫壓力的權(quán)衡這比單純記住命令要重要得多。理解Redis的十大數(shù)據(jù)類型絕不是背誦API手冊(cè)而是學(xué)習(xí)一種用“數(shù)據(jù)結(jié)構(gòu)服務(wù)器”的思維來(lái)建模和解決實(shí)際問(wèn)題的能力。從簡(jiǎn)單的緩存鍵值到復(fù)雜的關(guān)系運(yùn)算、流處理、地理搜索Redis提供了一套豐富而高效的原語(yǔ)。真正的功夫在于如何根據(jù)你的數(shù)據(jù)特征和訪問(wèn)模式像搭積木一樣靈活、混合地運(yùn)用這些類型構(gòu)建出既快又省的內(nèi)存數(shù)據(jù)層。下次當(dāng)你設(shè)計(jì)一個(gè)功能時(shí)不妨先問(wèn)問(wèn)自己這個(gè)數(shù)據(jù)在Redis里應(yīng)該長(zhǎng)什么樣