我們都知道 Redis 提供了豐富的數(shù)據(jù)類型，常見的有五種：String（字符串），Hash（哈希），List（列表），Set（集合）、Zset（有序集合）。

隨著 Redis 版本的更新，后面又支持了四種數(shù)據(jù)類型：BitMap（2.2 版新增）、HyperLogLog（2.8 版新增）、GEO（3.2 版新增）、Stream（5.0 版新增）。

每種數(shù)據(jù)對象都各自的應(yīng)用場景，你能說出它們各自的應(yīng)用場景嗎？

面試過程中，這個問題也很常被問到，又比如會舉例一個應(yīng)用場景來問你，讓你說使用哪種 Redis 數(shù)據(jù)類型來實現(xiàn)。

所以，這次我們就來學(xué)習(xí) Redis 數(shù)據(jù)類型的使用以及應(yīng)用場景。篇幅比較長，大家收藏慢慢看。

String

介紹

String 是最基本的 key-value 結(jié)構(gòu)，key 是唯一標(biāo)識，value 是具體的值，value其實不僅是字符串， 也可以是數(shù)字（整數(shù)或浮點數(shù)），value 最多可以容納的數(shù)據(jù)長度是 512M。

內(nèi)部實現(xiàn)

String 類型的底層的數(shù)據(jù)結(jié)構(gòu)實現(xiàn)主要是 int 和 SDS（簡單動態(tài)字符串）。

SDS 和我們認(rèn)識的 C 字符串不太一樣，之所以沒有使用 C 語言的字符串表示，因為 SDS 相比于 C 的原生字符串：

• SDS 不僅可以保存文本數(shù)據(jù)，還可以保存二進制數(shù)據(jù)。因為 SDS 使用 len 屬性的值而不是空字符來判斷字符串是否結(jié)束，并且 SDS 的所有 API 都會以處理二進制的方式來處理 SDS 存放在 buf[] 數(shù)組里的數(shù)據(jù)。所以 SDS 不光能存放文本數(shù)據(jù)，而且能保存圖片、音頻、視頻、壓縮文件這樣的二進制數(shù)據(jù)。
• **SDS 獲取字符串長度的時間復(fù)雜度是 O(1)**。因為 C 語言的字符串并不記錄自身長度，所以獲取長度的復(fù)雜度為 O(n)；而 SDS 結(jié)構(gòu)里用 len 屬性記錄了字符串長度，所以復(fù)雜度為 O(1)。
• Redis 的 SDS API 是安全的，拼接字符串不會造成緩沖區(qū)溢出。因為 SDS 在拼接字符串之前會檢查 SDS 空間是否滿足要求，如果空間不夠會自動擴容，所以不會導(dǎo)致緩沖區(qū)溢出的問題。

字符串對象的內(nèi)部編碼（encoding）有 3 種 ：int、raw和 embstr。

如果一個字符串對象保存的是整數(shù)值，并且這個整數(shù)值可以用long類型來表示，那么字符串對象會將整數(shù)值保存在字符串對象結(jié)構(gòu)的ptr屬性里面（將void*轉(zhuǎn)換成 long），并將字符串對象的編碼設(shè)置為int。

如果字符串對象保存的是一個字符串，并且這個字符申的長度小于等于 32 字節(jié)，那么字符串對象將使用一個簡單動態(tài)字符串（SDS）來保存這個字符串，并將對象的編碼設(shè)置為embstr， embstr編碼是專門用于保存短字符串的一種優(yōu)化編碼方式：

如果字符串對象保存的是一個字符串，并且這個字符串的長度大于 32 字節(jié)，那么字符串對象將使用一個簡單動態(tài)字符串（SDS）來保存這個字符串，并將對象的編碼設(shè)置為raw：

可以看到embstr和raw編碼都會使用SDS來保存值，但不同之處在于embstr會通過一次內(nèi)存分配函數(shù)來分配一塊連續(xù)的內(nèi)存空間來保存redisObject和SDS，而raw編碼會通過調(diào)用兩次內(nèi)存分配函數(shù)來分別分配兩塊空間來保存redisObject和SDS。Redis這樣做會有很多好處：

• embstr編碼將創(chuàng)建字符串對象所需的內(nèi)存分配次數(shù)從 raw 編碼的兩次降低為一次；
• 釋放 embstr編碼的字符串對象同樣只需要調(diào)用一次內(nèi)存釋放函數(shù)；
• 因為embstr編碼的字符串對象的所有數(shù)據(jù)都保存在一塊連續(xù)的內(nèi)存里面可以更好的利用 CPU 緩存提升性能。

但是 embstr 也有缺點的：

• 如果字符串的長度增加需要重新分配內(nèi)存時，整個redisObject和sds都需要重新分配空間，所以embstr編碼的字符串對象實際上是只讀的，redis沒有為embstr編碼的字符串對象編寫任何相應(yīng)的修改程序。當(dāng)我們對embstr編碼的字符串對象執(zhí)行任何修改命令（例如append）時，程序會先將對象的編碼從embstr轉(zhuǎn)換成raw，然后再執(zhí)行修改命令。

常用指令

普通字符串的基本操作：

# 設(shè)置 key-value 類型的值> SET name linOK# 根據(jù) key 獲得對應(yīng)的 value> GET name”lin”# 判斷某個 key 是否存在> EXISTS name(integer) 1# 返回 key 所儲存的字符串值的長度> STRLEN name(integer) 3# 刪除某個 key 對應(yīng)的值> DEL name(integer) 1

批量設(shè)置 :

# 批量設(shè)置 key-value 類型的值> MSET key1 value1 key2 value2 OK# 批量獲取多個 key 對應(yīng)的 value> MGET key1 key2 1) “value1″2) “value2”

計數(shù)器（字符串的內(nèi)容為整數(shù)的時候可以使用）：

# 設(shè)置 key-value 類型的值> SET number 0OK# 將 key 中儲存的數(shù)字值增一> INCR number(integer) 1# 將key中存儲的數(shù)字值加 10> INCRBY number 10(integer) 11# 將 key 中儲存的數(shù)字值減一> DECR number(integer) 10# 將key中存儲的數(shù)字值鍵 10> DECRBY number 10(integer) 0

過期（默認(rèn)為永不過期）：

# 設(shè)置 key 在 60 秒后過期（該方法是針對已經(jīng)存在的key設(shè)置過期時間）> EXPIRE name 60 (integer) 1# 查看數(shù)據(jù)還有多久過期> TTL name (integer) 51#設(shè)置 key-value 類型的值，并設(shè)置該key的過期時間為 60 秒> SET key value EX 60OK> SETEX key 60 valueOK

不存在就插入：

# 不存在就插入（not exists）>SETNX key value(integer) 1

應(yīng)用場景

緩存對象

使用 String 來緩存對象有兩種方式：

• 直接緩存整個對象的 JSON，命令例子：SET user:1 ‘{“name”:”xiaolin”, “age”:18}’。
• 采用將 key 進行分離為 user:ID:屬性，采用 MSET 存儲，用 MGET 獲取各屬性值，命令例子：MSET user:1:name xiaolin user:1:age 18 user:2:name xiaomei user:2:age 20。

常規(guī)計數(shù)

因為 Redis 處理命令是單線程，所以執(zhí)行命令的過程是原子的。因此 String 數(shù)據(jù)類型適合計數(shù)場景，比如計算訪問次數(shù)、點贊、轉(zhuǎn)發(fā)、庫存數(shù)量等等。

比如計算文章的閱讀量：

# 初始化文章的閱讀量> SET aritcle:readcount:1001 0OK#閱讀量+1> INCR aritcle:readcount:1001(integer) 1#閱讀量+1> INCR aritcle:readcount:1001(integer) 2#閱讀量+1> INCR aritcle:readcount:1001(integer) 3# 獲取對應(yīng)文章的閱讀量> GET aritcle:readcount:1001″3″

分布式鎖

SET 命令有個 NX 參數(shù)可以實現(xiàn)「key不存在才插入」，可以用它來實現(xiàn)分布式鎖：

• 如果 key 不存在，則顯示插入成功，可以用來表示加鎖成功；
• 如果 key 存在，則會顯示插入失敗，可以用來表示加鎖失敗。

一般而言，還會對分布式鎖加上過期時間，分布式鎖的命令如下：

SET lock_key unique_value NX PX 10000

• lock_key 就是 key 鍵；
• unique_value 是客戶端生成的唯一的標(biāo)識；
• NX 代表只在 lock_key 不存在時，才對 lock_key 進行設(shè)置操作；
• PX 10000 表示設(shè)置 lock_key 的過期時間為 10s，這是為了避免客戶端發(fā)生異常而無法釋放鎖。

而解鎖的過程就是將 lock_key 鍵刪除，但不能亂刪，要保證執(zhí)行操作的客戶端就是加鎖的客戶端。所以，解鎖的時候，我們要先判斷鎖的 unique_value 是否為加鎖客戶端，是的話，才將 lock_key 鍵刪除。

可以看到，解鎖是有兩個操作，這時就需要 Lua 腳本來保證解鎖的原子性，因為 Redis 在執(zhí)行 Lua 腳本時，可以以原子性的方式執(zhí)行，保證了鎖釋放操作的原子性。

// 釋放鎖時，先比較 unique_value 是否相等，避免鎖的誤釋放if redis.call(“get”,KEYS[1]) == ARGV[1] then return redis.call(“del”,KEYS[1])else return 0end

這樣一來，就通過使用 SET 命令和 Lua 腳本在 Redis 單節(jié)點上完成了分布式鎖的加鎖和解鎖。

List

介紹

List 列表是簡單的字符串列表，按照插入順序排序，可以從頭部或尾部向 List 列表添加元素。

列表的最大長度為 2^32 – 1，也即每個列表支持超過 40 億個元素。

內(nèi)部實現(xiàn)

List 類型的底層數(shù)據(jù)結(jié)構(gòu)是由雙向鏈表或壓縮列表實現(xiàn)的：

• 如果列表的元素個數(shù)小于 512 個（默認(rèn)值，可由 list-max-ziplist-entries 配置），列表每個元素的值都小于 64 字節(jié)（默認(rèn)值，可由 list-max-ziplist-value配置），Redis 會使用壓縮列表作為 List 類型的底層數(shù)據(jù)結(jié)構(gòu)；
• 如果列表的元素不滿足上面的條件，Redis 會使用雙向鏈表作為 List 類型的底層數(shù)據(jù)結(jié)構(gòu)；

但是在 Redis 3.2 版本之后，List 數(shù)據(jù)類型底層數(shù)據(jù)結(jié)構(gòu)就只由 quicklist 實現(xiàn)了，替代了雙向鏈表和壓縮列表。

常用命令

# 將一個或多個值value插入到key列表的表頭(最左邊)，最后的值在最前面LPUSH key value [value …] # 將一個或多個值value插入到key列表的表尾(最右邊)RPUSH key value [value …]# 移除并返回key列表的頭元素LPOP key # 移除并返回key列表的尾元素RPOP key # 返回列表key中指定區(qū)間內(nèi)的元素，區(qū)間以偏移量start和stop指定，從0開始LRANGE key start stop# 從key列表表頭彈出一個元素，沒有就阻塞timeout秒，如果timeout=0則一直阻塞BLPOP key [key …] timeout# 從key列表表尾彈出一個元素，沒有就阻塞timeout秒，如果timeout=0則一直阻塞BRPOP key [key …] timeout

應(yīng)用場景

消息隊列

消息隊列在存取消息時，必須要滿足三個需求，分別是消息保序、處理重復(fù)的消息和保證消息可靠性。

Redis 的 List 和 Stream 兩種數(shù)據(jù)類型，就可以滿足消息隊列的這三個需求。我們先來了解下基于 List 的消息隊列實現(xiàn)方法，后面在介紹 Stream 數(shù)據(jù)類型時候，在詳細說說 Stream。

1、如何滿足消息保序需求？

List 本身就是按先進先出的順序?qū)?shù)據(jù)進行存取的，所以，如果使用 List 作為消息隊列保存消息的話，就已經(jīng)能滿足消息保序的需求了。

List 可以使用 LPUSH + RPOP （或者反過來，RPUSH+LPOP）命令實現(xiàn)消息隊列。

• 生產(chǎn)者使用 LPUSH key value[value…] 將消息插入到隊列的頭部，如果 key 不存在則會創(chuàng)建一個空的隊列再插入消息。
• 消費者使用 RPOP key 依次讀取隊列的消息，先進先出。

不過，在消費者讀取數(shù)據(jù)時，有一個潛在的性能風(fēng)險點。

在生產(chǎn)者往 List 中寫入數(shù)據(jù)時，List 并不會主動地通知消費者有新消息寫入，如果消費者想要及時處理消息，就需要在程序中不停地調(diào)用 RPOP 命令（比如使用一個while(1)循環(huán)）。如果有新消息寫入，RPOP命令就會返回結(jié)果，否則，RPOP命令返回空值，再繼續(xù)循環(huán)。

所以，即使沒有新消息寫入List，消費者也要不停地調(diào)用 RPOP 命令，這就會導(dǎo)致消費者程序的 CPU 一直消耗在執(zhí)行 RPOP 命令上，帶來不必要的性能損失。

為了解決這個問題，Redis提供了 BRPOP 命令。BRPOP命令也稱為阻塞式讀取，客戶端在沒有讀到隊列數(shù)據(jù)時，自動阻塞，直到有新的數(shù)據(jù)寫入隊列，再開始讀取新數(shù)據(jù)。和消費者程序自己不停地調(diào)用RPOP命令相比，這種方式能節(jié)省CPU開銷。

2、如何處理重復(fù)的消息？

消費者要實現(xiàn)重復(fù)消息的判斷，需要 2 個方面的要求：

• 每個消息都有一個全局的 ID。
• 消費者要記錄已經(jīng)處理過的消息的 ID。當(dāng)收到一條消息后，消費者程序就可以對比收到的消息 ID 和記錄的已處理過的消息 ID，來判斷當(dāng)前收到的消息有沒有經(jīng)過處理。如果已經(jīng)處理過，那么，消費者程序就不再進行處理了。

但是 List 并不會為每個消息生成 ID 號，所以我們需要自行為每個消息生成一個全局唯一ID，生成之后，我們在用 LPUSH 命令把消息插入 List 時，需要在消息中包含這個全局唯一 ID。

例如，我們執(zhí)行以下命令，就把一條全局 ID 為 111000102、庫存量為 99 的消息插入了消息隊列：

> LPUSH mq “111000102:stock:99″(integer) 1

3、如何保證消息可靠性？

當(dāng)消費者程序從 List 中讀取一條消息后，List 就不會再留存這條消息了。所以，如果消費者程序在處理消息的過程出現(xiàn)了故障或宕機，就會導(dǎo)致消息沒有處理完成，那么，消費者程序再次啟動后，就沒法再次從 List 中讀取消息了。

為了留存消息，List 類型提供了 BRPOPLPUSH 命令，這個命令的作用是讓消費者程序從一個 List 中讀取消息，同時，Redis 會把這個消息再插入到另一個 List（可以叫作備份 List）留存。

這樣一來，如果消費者程序讀了消息但沒能正常處理，等它重啟后，就可以從備份 List 中重新讀取消息并進行處理了。

好了，到這里可以知道基于 List 類型的消息隊列，滿足消息隊列的三大需求（消息保序、處理重復(fù)的消息和保證消息可靠性）。

• 消息保序：使用 LPUSH + RPOP；
• 阻塞讀?。菏褂?BRPOP；
• 重復(fù)消息處理：生產(chǎn)者自行實現(xiàn)全局唯一 ID；
• 消息的可靠性：使用 BRPOPLPUSH

但是，在用 List 做消息隊列時，如果生產(chǎn)者消息發(fā)送很快，而消費者處理消息的速度比較慢，這就導(dǎo)致 List 中的消息越積越多，給 Redis 的內(nèi)存帶來很大壓力。

要解決這個問題，就要啟動多個消費者程序組成一個消費組，一起分擔(dān)處理 List 中的消息。但是，List 類型并不支持消費組的實現(xiàn)。

這就要說起 Redis 從 5.0 版本開始提供的 Stream 數(shù)據(jù)類型了，Stream 同樣能夠滿足消息隊列的三大需求，而且它還支持「消費組」形式的消息讀取。

Hash

介紹

Hash 是一個鍵值對（key – value）集合，其中 value 的形式入：value=[{field1，value1}，…{fieldN，valueN}]。Hash 特別適合用于存儲對象。

Hash 與 String 對象的區(qū)別如下圖所示:

內(nèi)部實現(xiàn)

Hash 類型的底層數(shù)據(jù)結(jié)構(gòu)是由壓縮列表或哈希表實現(xiàn)的：

• 如果哈希類型元素個數(shù)小于 512 個（默認(rèn)值，可由 hash-max-ziplist-entries 配置），所有值小于 64 字節(jié)（默認(rèn)值，可由 hash-max-ziplist-value 配置）的話，Redis 會使用壓縮列表作為 Hash 類型的底層數(shù)據(jù)結(jié)構(gòu)；
• 如果哈希類型元素不滿足上面條件，Redis 會使用哈希表作為 Hash 類型的 底層數(shù)據(jù)結(jié)構(gòu)。

在 Redis 7.0 中，壓縮列表數(shù)據(jù)結(jié)構(gòu)已經(jīng)廢棄了，交由 listpack 數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)了。

常用命令

# 存儲一個哈希表key的鍵值HSET key field value # 獲取哈希表key對應(yīng)的field鍵值HGET key field# 在一個哈希表key中存儲多個鍵值對HMSET key field value [field value…] # 批量獲取哈希表key中多個field鍵值HMGET key field [field …] # 刪除哈希表key中的field鍵值HDEL key field [field …] # 返回哈希表key中field的數(shù)量HLEN key # 返回哈希表key中所有的鍵值HGETALL key # 為哈希表key中field鍵的值加上增量nHINCRBY key field n

應(yīng)用場景

緩存對象

Hash 類型的 （key，field， value） 的結(jié)構(gòu)與對象的（對象id， 屬性， 值）的結(jié)構(gòu)相似，也可以用來存儲對象。

我們以用戶信息為例，它在關(guān)系型數(shù)據(jù)庫中的結(jié)構(gòu)是這樣的：

我們可以使用如下命令，將用戶對象的信息存儲到 Hash 類型：

# 存儲一個哈希表uid:1的鍵值> HSET uid:1 name Tom age 152# 存儲一個哈希表uid:2的鍵值> HSET uid:2 name Jerry age 132# 獲取哈希表用戶id為1中所有的鍵值> HGETALL uid:11) “name”2) “Tom”3) “age”4) “15”

Redis Hash 存儲其結(jié)構(gòu)如下圖：

在介紹 String 類型的應(yīng)用場景時有所介紹，String + Json也是存儲對象的一種方式，那么存儲對象時，到底用 String + json 還是用 Hash 呢？

一般對象用 String + Json 存儲，對象中某些頻繁變化的屬性可以考慮抽出來用 Hash 類型存儲。

購物車

以用戶 id 為 key，商品 id 為 field，商品數(shù)量為 value，恰好構(gòu)成了購物車的3個要素，如下圖所示。

涉及的命令如下：

• 添加商品：HSET cart:{用戶id} {商品id} 1
• 添加數(shù)量：HINCRBY cart:{用戶id} {商品id} 1
• 商品總數(shù)：HLEN cart:{用戶id}
• 刪除商品：HDEL cart:{用戶id} {商品id}
• 獲取購物車所有商品：HGETALL cart:{用戶id}

當(dāng)前僅僅是將商品ID存儲到了Redis 中，在回顯商品具體信息的時候，還需要拿著商品 id 查詢一次數(shù)據(jù)庫，獲取完整的商品的信息。

Set

介紹

Set 類型是一個無序并唯一的鍵值集合，它的存儲順序不會按照插入的先后順序進行存儲。

一個集合最多可以存儲 2^32-1 個元素。概念和數(shù)學(xué)中個的集合基本類似，可以交集，并集，差集等等，所以 Set 類型除了支持集合內(nèi)的增刪改查，同時還支持多個集合取交集、并集、差集。

Set 類型和 List 類型的區(qū)別如下：

• List 可以存儲重復(fù)元素，Set 只能存儲非重復(fù)元素；
• List 是按照元素的先后順序存儲元素的，而 Set 則是無序方式存儲元素的。

內(nèi)部實現(xiàn)

Set 類型的底層數(shù)據(jù)結(jié)構(gòu)是由哈希表或整數(shù)集合實現(xiàn)的：

• 如果集合中的元素都是整數(shù)且元素個數(shù)小于 512 （默認(rèn)值，set-maxintset-entries配置）個，Redis 會使用整數(shù)集合作為 Set 類型的底層數(shù)據(jù)結(jié)構(gòu)；
• 如果集合中的元素不滿足上面條件，則 Redis 使用哈希表作為 Set 類型的底層數(shù)據(jù)結(jié)構(gòu)。

常用命令

Set常用操作：

# 往集合key中存入元素，元素存在則忽略，若key不存在則新建SADD key member [member …]# 從集合key中刪除元素SREM key member [member …] # 獲取集合key中所有元素SMEMBERS key# 獲取集合key中的元素個數(shù)SCARD key# 判斷member元素是否存在于集合key中SISMEMBER key member# 從集合key中隨機選出count個元素，元素不從key中刪除SRANDMEMBER key [count]# 從集合key中隨機選出count個元素，元素從key中刪除SPOP key [count]

Set運算操作：

# 交集運算SINTER key [key …]# 將交集結(jié)果存入新集合destination中SINTERSTORE destination key [key …]# 并集運算SUNION key [key …]# 將并集結(jié)果存入新集合destination中SUNIONSTORE destination key [key …]# 差集運算SDIFF key [key …]# 將差集結(jié)果存入新集合destination中SDIFFSTORE destination key [key …]

應(yīng)用場景

集合的主要幾個特性，無序、不可重復(fù)、支持并交差等操作。

因此 Set 類型比較適合用來數(shù)據(jù)去重和保障數(shù)據(jù)的唯一性，還可以用來統(tǒng)計多個集合的交集、錯集和并集等，當(dāng)我們存儲的數(shù)據(jù)是無序并且需要去重的情況下，比較適合使用集合類型進行存儲。

但是要提醒你一下，這里有一個潛在的風(fēng)險。Set 的差集、并集和交集的計算復(fù)雜度較高，在數(shù)據(jù)量較大的情況下，如果直接執(zhí)行這些計算，會導(dǎo)致 Redis 實例阻塞。

在主從集群中，為了避免主庫因為 Set 做聚合計算（交集、差集、并集）時導(dǎo)致主庫被阻塞，我們可以選擇一個從庫完成聚合統(tǒng)計，或者把數(shù)據(jù)返回給客戶端，由客戶端來完成聚合統(tǒng)計。

點贊

Set 類型可以保證一個用戶只能點一個贊，這里舉例子一個場景，key 是文章id，value 是用戶id。

uid:1 、uid:2、uid:3 三個用戶分別對 article:1 文章點贊了。

# uid:1 用戶對文章 article:1 點贊> SADD article:1 uid:1(integer) 1# uid:2 用戶對文章 article:1 點贊> SADD article:1 uid:2(integer) 1# uid:3 用戶對文章 article:1 點贊> SADD article:1 uid:3(integer) 1

uid:1 取消了對 article:1 文章點贊。

> SREM article:1 uid:1(integer) 1

獲取 article:1 文章所有點贊用戶 :

> SMEMBERS article:11) “uid:3″2) “uid:2”

獲取 article:1 文章的點贊用戶數(shù)量：

> SCARD article:1(integer) 2

判斷用戶 uid:1 是否對文章 article:1 點贊了：

> SISMEMBER article:1 uid:1(integer) 0 # 返回0說明沒點贊，返回1則說明點贊了

共同關(guān)注

Set 類型支持交集運算，所以可以用來計算共同關(guān)注的好友、公眾號等。

key 可以是用戶id，value 則是已關(guān)注的公眾號的id。

uid:1 用戶關(guān)注公眾號 id 為 5、6、7、8、9，uid:2 用戶關(guān)注公眾號 id 為 7、8、9、10、11。

# uid:1 用戶關(guān)注公眾號 id 為 5、6、7、8、9> SADD uid:1 5 6 7 8 9(integer) 5# uid:2 用戶關(guān)注公眾號 id 為 7、8、9、10、11> SADD uid:2 7 8 9 10 11(integer) 5

uid:1 和 uid:2 共同關(guān)注的公眾號：

# 獲取共同關(guān)注> SINTER uid:1 uid:21) “7”2) “8”3) “9”

給 uid:2 推薦 uid:1 關(guān)注的公眾號：

> SDIFF uid:1 uid:21) “5”2) “6”

驗證某個公眾號是否同時被 uid:1 或 uid:2 關(guān)注:

> SISMEMBER uid:1 5(integer) 1 # 返回0，說明關(guān)注了> SISMEMBER uid:2 5(integer) 0 # 返回0，說明沒關(guān)注

抽獎活動

存儲某活動中中獎的用戶名 ，Set 類型因為有去重功能，可以保證同一個用戶不會中獎兩次。

key為抽獎活動名，value為員工名稱，把所有員工名稱放入抽獎箱 ：

>SADD lucky Tom Jerry John Sean Marry Lindy Sary Mark(integer) 5

如果允許重復(fù)中獎，可以使用 SRANDMEMBER 命令。

# 抽取 1 個一等獎：> SRANDMEMBER lucky 11) “Tom”# 抽取 2 個二等獎：> SRANDMEMBER lucky 21) “Mark”2) “Jerry”# 抽取 3 個三等獎：> SRANDMEMBER lucky 31) “Sary”2) “Tom”3) “Jerry”

如果不允許重復(fù)中獎，可以使用 SPOP 命令。

# 抽取一等獎1個> SPOP lucky 11) “Sary”# 抽取二等獎2個> SPOP lucky 21) “Jerry”2) “Mark”# 抽取三等獎3個> SPOP lucky 31) “John”2) “Sean”3) “Lindy”

Zset

介紹

Zset 類型（有序集合類型）相比于 Set 類型多了一個排序?qū)傩?score（分值），對于有序集合 ZSet 來說，每個存儲元素相當(dāng)于有兩個值組成的，一個是有序結(jié)合的元素值，一個是排序值。

有序集合保留了集合不能有重復(fù)成員的特性（分值可以重復(fù)），但不同的是，有序集合中的元素可以排序。

內(nèi)部實現(xiàn)

Zset 類型的底層數(shù)據(jù)結(jié)構(gòu)是由壓縮列表或跳表實現(xiàn)的：

• 如果有序集合的元素個數(shù)小于 128 個，并且每個元素的值小于 64 字節(jié)時，Redis 會使用壓縮列表作為 Zset 類型的底層數(shù)據(jù)結(jié)構(gòu)；
• 如果有序集合的元素不滿足上面的條件，Redis 會使用跳表作為 Zset 類型的底層數(shù)據(jù)結(jié)構(gòu)；

在 Redis 7.0 中，壓縮列表數(shù)據(jù)結(jié)構(gòu)已經(jīng)廢棄了，交由 listpack 數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)了。

常用命令

Zset 常用操作：

# 往有序集合key中加入帶分值元素ZADD key score member [[score member]…] # 往有序集合key中刪除元素ZREM key member [member…] # 返回有序集合key中元素member的分值ZSCORE key member# 返回有序集合key中元素個數(shù)ZCARD key # 為有序集合key中元素member的分值加上incrementZINCRBY key increment member # 正序獲取有序集合key從start下標(biāo)到stop下標(biāo)的元素ZRANGE key start stop [WITHSCORES]# 倒序獲取有序集合key從start下標(biāo)到stop下標(biāo)的元素ZREVRANGE key start stop [WITHSCORES]# 返回有序集合中指定分?jǐn)?shù)區(qū)間內(nèi)的成員，分?jǐn)?shù)由低到高排序。ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]# 返回指定成員區(qū)間內(nèi)的成員，按字典正序排列, 分?jǐn)?shù)必須相同。ZRANGEBYLEX key min max [LIMIT offset count]# 返回指定成員區(qū)間內(nèi)的成員，按字典倒序排列, 分?jǐn)?shù)必須相同ZREVRANGEBYLEX key max min [LIMIT offset count]

Zset 運算操作（相比于 Set 類型，ZSet 類型沒有支持差集運算）：

# 并集計算(相同元素分值相加)，numberkeys一共多少個key，WEIGHTS每個key對應(yīng)的分值乘積ZUNIONSTORE destkey numberkeys key [key…] # 交集計算(相同元素分值相加)，numberkeys一共多少個key，WEIGHTS每個key對應(yīng)的分值乘積ZINTERSTORE destkey numberkeys key [key…]

應(yīng)用場景

Zset 類型（Sorted Set，有序集合） 可以根據(jù)元素的權(quán)重來排序，我們可以自己來決定每個元素的權(quán)重值。比如說，我們可以根據(jù)元素插入 Sorted Set 的時間確定權(quán)重值，先插入的元素權(quán)重小，后插入的元素權(quán)重大。

在面對需要展示最新列表、排行榜等場景時，如果數(shù)據(jù)更新頻繁或者需要分頁顯示，可以優(yōu)先考慮使用 Sorted Set。

排行榜

有序集合比較典型的使用場景就是排行榜。例如學(xué)生成績的排名榜、游戲積分排行榜、視頻播放排名、電商系統(tǒng)中商品的銷量排名等。

我們以博文點贊排名為例，小林發(fā)表了五篇博文，分別獲得贊為 200、40、100、50、150。

# arcticle:1 文章獲得了200個贊> ZADD user:xiaolin:ranking 200 arcticle:1(integer) 1# arcticle:2 文章獲得了40個贊> ZADD user:xiaolin:ranking 40 arcticle:2(integer) 1# arcticle:3 文章獲得了100個贊> ZADD user:xiaolin:ranking 100 arcticle:3(integer) 1# arcticle:4 文章獲得了50個贊> ZADD user:xiaolin:ranking 50 arcticle:4(integer) 1# arcticle:5 文章獲得了150個贊> ZADD user:xiaolin:ranking 150 arcticle:5(integer) 1

文章 arcticle:4 新增一個贊，可以使用 ZINCRBY 命令（為有序集合key中元素member的分值加上increment）：

> ZINCRBY user:xiaolin:ranking 1 arcticle:4″51″

查看某篇文章的贊數(shù)，可以使用 ZSCORE 命令（返回有序集合key中元素個數(shù)）：

> ZSCORE user:xiaolin:ranking arcticle:4″50″

獲取小林文章贊數(shù)最多的 3 篇文章，可以使用 ZREVRANGE 命令（倒序獲取有序集合 key 從start下標(biāo)到stop下標(biāo)的元素）：

# WITHSCORES 表示把 score 也顯示出來> ZREVRANGE user:xiaolin:ranking 0 2 WITHSCORES1) “arcticle:1″2) “200”3) “arcticle:5″4) “150”5) “arcticle:3″6) “100”

獲取小林 100 贊到 200 贊的文章，可以使用 ZRANGEBYSCORE 命令（返回有序集合中指定分?jǐn)?shù)區(qū)間內(nèi)的成員，分?jǐn)?shù)由低到高排序）：

> ZRANGEBYSCORE user:xiaolin:ranking 100 200 WITHSCORES1) “arcticle:3″2) “100”3) “arcticle:5″4) “150”5) “arcticle:1″6) “200”

電話、姓名排序

使用有序集合的 ZRANGEBYLEX 或 ZREVRANGEBYLEX 可以幫助我們實現(xiàn)電話號碼或姓名的排序，我們以 ZRANGEBYLEX （返回指定成員區(qū)間內(nèi)的成員，按 key 正序排列，分?jǐn)?shù)必須相同）為例。

注意：不要在分?jǐn)?shù)不一致的 SortSet 集合中去使用 ZRANGEBYLEX和 ZREVRANGEBYLEX 指令，因為獲取的結(jié)果會不準(zhǔn)確。

1、電話排序

我們可以將電話號碼存儲到 SortSet 中，然后根據(jù)需要來獲取號段：

> ZADD phone 0 13100111100 0 13110114300 0 13132110901 (integer) 3> ZADD phone 0 13200111100 0 13210414300 0 13252110901 (integer) 3> ZADD phone 0 13300111100 0 13310414300 0 13352110901 (integer) 3

獲取所有號碼:

> ZRANGEBYLEX phone – +1) “13100111100”2) “13110114300”3) “13132110901”4) “13200111100”5) “13210414300”6) “13252110901”7) “13300111100”8) “13310414300”9) “13352110901”

獲取 132 號段的號碼：

> ZRANGEBYLEX phone [132 (1331) “13200111100”2) “13210414300”3) “13252110901”

獲取132、133號段的號碼：

> ZRANGEBYLEX phone [132 (1341) “13200111100”2) “13210414300”3) “13252110901”4) “13300111100”5) “13310414300”6) “13352110901”

2、姓名排序

> zadd names 0 Toumas 0 Jake 0 Bluetuo 0 Gaodeng 0 Aimini 0 Aidehua (integer) 6

獲取所有人的名字:

> ZRANGEBYLEX names – +1) “Aidehua”2) “Aimini”3) “Bluetuo”4) “Gaodeng”5) “Jake”6) “Toumas”

獲取名字中大寫字母A開頭的所有人：

> ZRANGEBYLEX names [A (B1) “Aidehua”2) “Aimini”

獲取名字中大寫字母 C 到 Z 的所有人：

> ZRANGEBYLEX names [C [Z1) “Gaodeng”2) “Jake”3) “Toumas”

BitMap

介紹

Bitmap，即位圖，是一串連續(xù)的二進制數(shù)組（0和1），可以通過偏移量（offset）定位元素。BitMap通過最小的單位bit來進行0|1的設(shè)置，表示某個元素的值或者狀態(tài)，時間復(fù)雜度為O(1)。

由于 bit 是計算機中最小的單位，使用它進行儲存將非常節(jié)省空間，特別適合一些數(shù)據(jù)量大且使用二值統(tǒng)計的場景。

內(nèi)部實現(xiàn)

Bitmap 本身是用 String 類型作為底層數(shù)據(jù)結(jié)構(gòu)實現(xiàn)的一種統(tǒng)計二值狀態(tài)的數(shù)據(jù)類型。

String 類型是會保存為二進制的字節(jié)數(shù)組，所以，Redis 就把字節(jié)數(shù)組的每個 bit 位利用起來，用來表示一個元素的二值狀態(tài)，你可以把 Bitmap 看作是一個 bit 數(shù)組。

常用命令

bitmap 基本操作：

# 設(shè)置值，其中value只能是 0 和 1SETBIT key offset value# 獲取值GETBIT key offset# 獲取指定范圍內(nèi)值為 1 的個數(shù)# start 和 end 以字節(jié)為單位BITCOUNT key start end

bitmap 運算操作：

# BitMap間的運算# operations 位移操作符，枚舉值 AND 與運算 & OR 或運算 | XOR 異或 ^ NOT 取反 ~# result 計算的結(jié)果，會存儲在該key中# key1 … keyn 參與運算的key，可以有多個，空格分割，not運算只能一個key# 當(dāng) BITOP 處理不同長度的字符串時，較短的那個字符串所缺少的部分會被看作 0。返回值是保存到 destkey 的字符串的長度（以字節(jié)byte為單位），和輸入 key 中最長的字符串長度相等。BITOP [operations] [result] [key1] [keyn…]# 返回指定key中第一次出現(xiàn)指定value(0/1)的位置BITPOS [key] [value]

應(yīng)用場景

Bitmap 類型非常適合二值狀態(tài)統(tǒng)計的場景，這里的二值狀態(tài)就是指集合元素的取值就只有 0 和 1 兩種，在記錄海量數(shù)據(jù)時，Bitmap 能夠有效地節(jié)省內(nèi)存空間。

簽到統(tǒng)計

在簽到打卡的場景中，我們只用記錄簽到（1）或未簽到（0），所以它就是非常典型的二值狀態(tài)。

簽到統(tǒng)計時，每個用戶一天的簽到用 1 個 bit 位就能表示，一個月（假設(shè)是 31 天）的簽到情況用 31 個 bit 位就可以，而一年的簽到也只需要用 365 個 bit 位，根本不用太復(fù)雜的集合類型。

假設(shè)我們要統(tǒng)計 ID 100 的用戶在 2022 年 6 月份的簽到情況，就可以按照下面的步驟進行操作。

第一步，執(zhí)行下面的命令，記錄該用戶 6 月 3 號已簽到。

SETBIT uid:sign:100:202206 2 1

第二步，檢查該用戶 6 月 3 日是否簽到。

GETBIT uid:sign:100:202206 2

第三步，統(tǒng)計該用戶在 6 月份的簽到次數(shù)。

BITCOUNT uid:sign:100:202206

這樣，我們就知道該用戶在 6 月份的簽到情況了。

如何統(tǒng)計這個月首次打卡時間呢？

Redis 提供了 BITPOS key bitValue [start] [end]指令，返回數(shù)據(jù)表示 Bitmap 中第一個值為 bitValue 的 offset 位置。

在默認(rèn)情況下， 命令將檢測整個位圖， 用戶可以通過可選的 start 參數(shù)和 end 參數(shù)指定要檢測的范圍。所以我們可以通過執(zhí)行這條命令來獲取 userID = 100 在 2022 年 6 月份首次打卡日期：

BITPOS uid:sign:100:202206 1

需要注意的是，因為 offset 從 0 開始的，所以我們需要將返回的 value + 1 。

判斷用戶登陸態(tài)

Bitmap 提供了 GETBIT、SETBIT 操作，通過一個偏移值 offset 對 bit 數(shù)組的 offset 位置的 bit 位進行讀寫操作，需要注意的是 offset 從 0 開始。

只需要一個 key = login_status 表示存儲用戶登陸狀態(tài)集合數(shù)據(jù)， 將用戶 ID 作為 offset，在線就設(shè)置為 1，下線設(shè)置 0。通過 GETBIT判斷對應(yīng)的用戶是否在線。50000 萬 用戶只需要 6 MB 的空間。

假如我們要判斷 ID = 10086 的用戶的登陸情況：

第一步，執(zhí)行以下指令，表示用戶已登錄。

SETBIT login_status 10086 1

第二步，檢查該用戶是否登陸，返回值 1 表示已登錄。

GETBIT login_status 10086

第三步，登出，將 offset 對應(yīng)的 value 設(shè)置成 0。

SETBIT login_status 10086 0

連續(xù)簽到用戶總數(shù)

如何統(tǒng)計出這連續(xù) 7 天連續(xù)打卡用戶總數(shù)呢？

我們把每天的日期作為 Bitmap 的 key，userId 作為 offset，若是打卡則將 offset 位置的 bit 設(shè)置成 1。

key 對應(yīng)的集合的每個 bit 位的數(shù)據(jù)則是一個用戶在該日期的打卡記錄。

一共有 7 個這樣的 Bitmap，如果我們能對這 7 個 Bitmap 的對應(yīng)的 bit 位做 『與』運算。同樣的 UserID offset 都是一樣的，當(dāng)一個 userID 在 7 個 Bitmap 對應(yīng)對應(yīng)的 offset 位置的 bit = 1 就說明該用戶 7 天連續(xù)打卡。

結(jié)果保存到一個新 Bitmap 中，我們再通過 BITCOUNT 統(tǒng)計 bit = 1 的個數(shù)便得到了連續(xù)打卡 3 天的用戶總數(shù)了。

Redis 提供了 BITOP operation destkey key [key …]這個指令用于對一個或者多個 key 的 Bitmap 進行位元操作。

• opration 可以是 and、OR、NOT、XOR。當(dāng) BITOP 處理不同長度的字符串時，較短的那個字符串所缺少的部分會被看作 0 。空的 key 也被看作是包含 0 的字符串序列。

舉個例子，比如將三個 bitmap 進行 AND 操作，并將結(jié)果保存到 destmap 中，接著對 destmap 執(zhí)行 BITCOUNT 統(tǒng)計。

# 與操作BITOP AND destmap bitmap:01 bitmap:02 bitmap:03# 統(tǒng)計 bit 位 = 1 的個數(shù)BITCOUNT destmap

即使一天產(chǎn)生一個億的數(shù)據(jù)，Bitmap 占用的內(nèi)存也不大，大約占 12 MB 的內(nèi)存（10^8/8/1024/1024），7 天的 Bitmap 的內(nèi)存開銷約為 84 MB。同時我們最好給 Bitmap 設(shè)置過期時間，讓 Redis 刪除過期的打卡數(shù)據(jù)，節(jié)省內(nèi)存。

HyperLogLog

介紹

Redis HyperLogLog 是 Redis 2.8.9 版本新增的數(shù)據(jù)類型，是一種用于「統(tǒng)計基數(shù)」的數(shù)據(jù)集合類型，基數(shù)統(tǒng)計就是指統(tǒng)計一個集合中不重復(fù)的元素個數(shù)。但要注意，HyperLogLog 是統(tǒng)計規(guī)則是基于概率完成的，不是非常準(zhǔn)確，標(biāo)準(zhǔn)誤算率是 0.81%。

所以，簡單來說 HyperLogLog 提供不精確的去重計數(shù)。

HyperLogLog 的優(yōu)點是，在輸入元素的數(shù)量或者體積非常非常大時，計算基數(shù)所需的內(nèi)存空間總是固定的、并且是很小的。

在 Redis 里面，每個 HyperLogLog 鍵只需要花費 12 KB 內(nèi)存，就可以計算接近 2^64 個不同元素的基數(shù)，和元素越多就越耗費內(nèi)存的 Set 和 Hash 類型相比，HyperLogLog 就非常節(jié)省空間。

這什么概念？舉個例子給大家對比一下。

用 Java 語言來說，一般 long 類型占用 8 字節(jié)，而 1 字節(jié)有 8 位，即：1 byte = 8 bit，即 long 數(shù)據(jù)類型最大可以表示的數(shù)是：2^63-1。對應(yīng)上面的2^64個數(shù)，假設(shè)此時有2^63-1這么多個數(shù)，從 0 ~ 2^63-1，按照long以及1k = 1024 字節(jié)的規(guī)則來計算內(nèi)存總數(shù)，就是：((2^63-1) * 8/1024)K，這是很龐大的一個數(shù)，存儲空間遠遠超過12K，而HyperLogLog 卻可以用 12K 就能統(tǒng)計完。

內(nèi)部實現(xiàn)

HyperLogLog 的實現(xiàn)涉及到很多數(shù)學(xué)問題，太費腦子了，我也沒有搞懂。

常見命令

HyperLogLog 命令很少，就三個。

# 添加指定元素到 HyperLogLog 中PFADD key element [element …]# 返回給定 HyperLogLog 的基數(shù)估算值。PFCOUNT key [key …]# 將多個 HyperLogLog 合并為一個 HyperLogLogPFMERGE destkey sourcekey [sourcekey …]

應(yīng)用場景

百萬級網(wǎng)頁 UV 計數(shù)

Redis HyperLogLog 優(yōu)勢在于只需要花費 12 KB 內(nèi)存，就可以計算接近 2^64 個元素的基數(shù)，和元素越多就越耗費內(nèi)存的 Set 和 Hash 類型相比，HyperLogLog 就非常節(jié)省空間。

所以，非常適合統(tǒng)計百萬級以上的網(wǎng)頁 UV 的場景。

在統(tǒng)計 UV 時，你可以用 PFADD 命令（用于向 HyperLogLog 中添加新元素）把訪問頁面的每個用戶都添加到 HyperLogLog 中。

PFADD page1:uv user1 user2 user3 user4 user5

接下來，就可以用 PFCOUNT 命令直接獲得 page1 的 UV 值了，這個命令的作用就是返回 HyperLogLog 的統(tǒng)計結(jié)果。

PFCOUNT page1:uv

不過，有一點需要你注意一下，HyperLogLog 的統(tǒng)計規(guī)則是基于概率完成的，所以它給出的統(tǒng)計結(jié)果是有一定誤差的，標(biāo)準(zhǔn)誤算率是 0.81%。

這也就意味著，你使用 HyperLogLog 統(tǒng)計的 UV 是 100 萬，但實際的 UV 可能是 101 萬。雖然誤差率不算大，但是，如果你需要精確統(tǒng)計結(jié)果的話，最好還是繼續(xù)用 Set 或 Hash 類型。

GEO

Redis GEO 是 Redis 3.2 版本新增的數(shù)據(jù)類型，主要用于存儲地理位置信息，并對存儲的信息進行操作。

在日常生活中，我們越來越依賴搜索“附近的餐館”、在打車軟件上叫車，這些都離不開基于位置信息服務(wù)（Location-Based Service，LBS）的應(yīng)用。LBS 應(yīng)用訪問的數(shù)據(jù)是和人或物關(guān)聯(lián)的一組經(jīng)緯度信息，而且要能查詢相鄰的經(jīng)緯度范圍，GEO 就非常適合應(yīng)用在 LBS 服務(wù)的場景中。

內(nèi)部實現(xiàn)

GEO 本身并沒有設(shè)計新的底層數(shù)據(jù)結(jié)構(gòu)，而是直接使用了 Sorted Set 集合類型。

GEO 類型使用 GeoHash 編碼方法實現(xiàn)了經(jīng)緯度到 Sorted Set 中元素權(quán)重分?jǐn)?shù)的轉(zhuǎn)換，這其中的兩個關(guān)鍵機制就是「對二維地圖做區(qū)間劃分」和「對區(qū)間進行編碼」。一組經(jīng)緯度落在某個區(qū)間后，就用區(qū)間的編碼值來表示，并把編碼值作為 Sorted Set 元素的權(quán)重分?jǐn)?shù)。

這樣一來，我們就可以把經(jīng)緯度保存到 Sorted Set 中，利用 Sorted Set 提供的“按權(quán)重進行有序范圍查找”的特性，實現(xiàn) LBS 服務(wù)中頻繁使用的“搜索附近”的需求。

常用命令

# 存儲指定的地理空間位置，可以將一個或多個經(jīng)度(longitude)、緯度(latitude)、位置名稱(member)添加到指定的 key 中。GEOADD key longitude latitude member [longitude latitude member …]# 從給定的 key 里返回所有指定名稱(member)的位置（經(jīng)度和緯度），不存在的返回 nil。GEOPOS key member [member …]# 返回兩個給定位置之間的距離。GEODIST key member1 member2 [m|km|ft|mi]# 根據(jù)用戶給定的經(jīng)緯度坐標(biāo)來獲取指定范圍內(nèi)的地理位置集合。GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]

應(yīng)用場景

滴滴叫車

這里以滴滴叫車的場景為例，介紹下具體如何使用 GEO 命令：GEOADD 和 GEORADIUS 這兩個命令。

假設(shè)車輛 ID 是 33，經(jīng)緯度位置是（116.034579，39.030452），我們可以用一個 GEO 集合保存所有車輛的經(jīng)緯度，集合 key 是 cars:locations。

執(zhí)行下面的這個命令，就可以把 ID 號為 33 的車輛的當(dāng)前經(jīng)緯度位置存入 GEO 集合中：

GEOADD cars:locations 116.034579 39.030452 33

當(dāng)用戶想要尋找自己附近的網(wǎng)約車時，LBS 應(yīng)用就可以使用 GEORADIUS 命令。

例如，LBS 應(yīng)用執(zhí)行下面的命令時，Redis 會根據(jù)輸入的用戶的經(jīng)緯度信息（116.054579，39.030452 ），查找以這個經(jīng)緯度為中心的 5 公里內(nèi)的車輛信息，并返回給 LBS 應(yīng)用。

GEORADIUS cars:locations 116.054579 39.030452 5 km ASC COUNT 10

Stream

介紹

Redis Stream 是 Redis 5.0 版本新增加的數(shù)據(jù)類型，Redis 專門為消息隊列設(shè)計的數(shù)據(jù)類型。

在前面介紹 List 類型實現(xiàn)的消息隊列，有兩個問題：1. 生產(chǎn)者需要自行實現(xiàn)全局唯一 ID；2. 不能以消費組形式消費數(shù)據(jù)。

基于 Stream 類型的消息隊列就解決上面的問題，它不僅支持自動生成全局唯一 ID，而且支持以消費組形式消費數(shù)據(jù)。

常見命令

Stream 消息隊列操作命令：

• XADD：插入消息，保證有序，可以自動生成全局唯一 ID；
• XREAD：用于讀取消息，可以按 ID 讀取數(shù)據(jù)；
• XREADGROUP：按消費組形式讀取消息；
• XPENDING 和 XACK：
• XPENDING 命令可以用來查詢每個消費組內(nèi)所有消費者已讀取但尚未確認(rèn)的消息，而 XACK 命令用于向消息隊列確認(rèn)消息處理已完成。

應(yīng)用場景

消息隊列

生產(chǎn)者通過 XADD 命令插入一條消息：

# * 表示讓 Redis 為插入的數(shù)據(jù)自動生成一個全局唯一的 ID# 往名稱為 mymq 的消息隊列中插入一條消息，消息的鍵是 name，值是 xiaolin> XADD mymq * name xiaolin”1654254953808-0″

插入成功后會返回全局唯一的 ID：”1654254953808-0″。消息的全局唯一 ID 由兩部分組成：

• 第一部分“1654254953808”是數(shù)據(jù)插入時，以毫秒為單位計算的當(dāng)前服務(wù)器時間；
• 第二部分表示插入消息在當(dāng)前毫秒內(nèi)的消息序號，這是從 0 開始編號的。例如，“1654254953808-0”就表示在“1654254953808”毫秒內(nèi)的第 1 條消息。

消費者通過 XREAD 命令從消息隊列中讀取消息時，可以指定一個消息 ID，并從這個消息 ID 的下一條消息開始進行讀?。ㄗ⒁馐禽斎胂?ID 的下一條信息開始讀取，不是查詢輸入ID的消息）。

# 從 ID 號為 1654254953807-0 的消息開始，讀取后續(xù)的所有消息（示例中一共 1 條）。> XREAD Stream mymq 1654254953807-01) 1) “mymq” 2) 1) 1) “1654254953808-0” 2) 1) “name” 2) “xiaolin”

如果想要實現(xiàn)阻塞讀（當(dāng)沒有數(shù)據(jù)時，阻塞?。?，可以調(diào)用 XRAED 時設(shè)定 block 配置項，實現(xiàn)類似于 BRPOP 的阻塞讀取操作。

比如，下面這命令，設(shè)置了 block 10000 的配置項，10000 的單位是毫秒，表明 XREAD 在讀取最新消息時，如果沒有消息到來，XREAD 將阻塞 10000 毫秒（即 10 秒），然后再返回。

# 命令最后的“$”符號表示讀取最新的消息> XREAD block 10000 Stream mymq $(nil)(10.00s)

前面介紹的這些操作 List 也支持的，接下來看看 Stream 特有的功能。

Stream 可以以使用 XGROUP 創(chuàng)建消費組，創(chuàng)建消費組之后，Stream 可以使用 XREADGROUP 命令讓消費組內(nèi)的消費者讀取消息。

創(chuàng)建一個名為 group1 的消費組，這個消費組消費的消息隊列是 mymq：

# 創(chuàng)建一個名為 group1 的消費組> XGROUP create mymq group1 0OK

消費組 group1 內(nèi)的消費者 consumer1 從 mymq 消息隊列中讀取所有消息的命令如下：

# 命令最后的參數(shù)“>”，表示從第一條尚未被消費的消息開始讀取。> XREADGROUP group group1 consumer1 Stream mymq >1) 1) “mymq” 2) 1) 1) “1654254953808-0” 2) 1) “name” 2) “xiaolin”

消息隊列中的消息一旦被消費組里的一個消費者讀取了，就不能再被該消費組內(nèi)的其他消費者讀取了。

比如說，我們執(zhí)行完剛才的 XREADGROUP 命令后，再執(zhí)行一次同樣的命令，此時讀到的就是空值了：

> XREADGROUP group group1 consumer1 Stream mymq >(nil)

使用消費組的目的是讓組內(nèi)的多個消費者共同分擔(dān)讀取消息，所以，我們通常會讓每個消費者讀取部分消息，從而實現(xiàn)消息讀取負載在多個消費者間是均衡分布的。

例如，我們執(zhí)行下列命令，讓 group2 中的 consumer1、2、3 各自讀取一條消息。

# 讓 group2 中的 consumer1 從 mymq 消息隊列中消費一條消息> XREADGROUP group group2 consumer1 count 1 Stream mymq >1) 1) “mymq” 2) 1) 1) “1654254953808-0” 2) 1) “name” 2) “xiaolin”# 讓 group2 中的 consumer2 從 mymq 消息隊列中消費一條消息> XREADGROUP group group2 consumer2 count 1 Stream mymq >1) 1) “mymq” 2) 1) 1) “1654256265584-0” 2) 1) “name” 2) “xiaolincoding”# 讓 group2 中的 consumer3 從 mymq 消息隊列中消費一條消息> XREADGROUP group group2 consumer3 count 1 Stream mymq >1) 1) “mymq” 2) 1) 1) “1654256271337-0” 2) 1) “name” 2) “Tom”

基于 Stream 實現(xiàn)的消息隊列，如何保證消費者在發(fā)生故障或宕機再次重啟后，仍然可以讀取未處理完的消息？

Streams 會自動使用內(nèi)部隊列（也稱為 PENDING List）留存消費組里每個消費者讀取的消息，直到消費者使用 XACK 命令通知 Streams“消息已經(jīng)處理完成”。

如果消費者沒有成功處理消息，它就不會給 Streams 發(fā)送 XACK 命令，消息仍然會留存。此時，消費者可以在重啟后，用 XPENDING 命令查看已讀取、但尚未確認(rèn)處理完成的消息。

例如，我們來查看一下 group2 中各個消費者已讀取、但尚未確認(rèn)的消息個數(shù)，命令如下：

127.0.0.1:6379> XPENDING mymq group21) (integer) 32) “1654254953808-0” # 表示 group2 中所有消費者讀取的消息最小 ID3) “1654256271337-0” # 表示 group2 中所有消費者讀取的消息最大 ID4) 1) 1) “consumer1” 2) “1” 2) 1) “consumer2” 2) “1” 3) 1) “consumer3” 2) “1”

如果想查看某個消費者具體讀取了哪些數(shù)據(jù)，可以執(zhí)行下面的命令：

# 查看 group2 里 consumer2 已從 mymq 消息隊列中讀取了哪些消息> XPENDING mymq group2 – + 10 consumer21) 1) “1654256265584-0” 2) “consumer2” 3) (integer) 410700 4) (integer) 1

可以看到，consumer2 已讀取的消息的 ID 是 1654256265584-0。

一旦消息 1654256265584-0 被 consumer2 處理了，consumer2 就可以使用 XACK 命令通知 Streams，然后這條消息就會被刪除。

> XACK mymq group2 1654256265584-0(integer) 1

當(dāng)我們再使用 XPENDING 命令查看時，就可以看到，consumer2 已經(jīng)沒有已讀取、但尚未確認(rèn)處理的消息了。

> XPENDING mymq group2 – + 10 consumer2(empty array)

好了，基于 Stream 實現(xiàn)的消息隊列就說到這里了，小結(jié)一下：

• 消息保序：XADD/XREAD
• 阻塞讀?。篨READ block
• 重復(fù)消息處理：Stream 在使用 XADD 命令，會自動生成全局唯一 ID；
• 消息可靠性：內(nèi)部使用 PENDING List 自動保存消息，使用 XPENDING 命令查看消費組已經(jīng)讀取但是未被確認(rèn)的消息，消費者使用 XACK 確認(rèn)消息；
• 支持消費組形式消費數(shù)據(jù)

Redis 基于 Stream 消息隊列與專業(yè)的消息隊列有哪些差距？

一個專業(yè)的消息隊列，必須要做到兩大塊：

• 消息不丟。
• 消息可堆積。

1、Redis Stream 消息會丟失嗎？

使用一個消息隊列，其實就分為三大塊：生產(chǎn)者、隊列中間件、消費者，所以要保證消息就是保證三個環(huán)節(jié)都不能丟失數(shù)據(jù)。

Redis Stream 消息隊列能不能保證三個環(huán)節(jié)都不丟失數(shù)據(jù)？

• Redis 生產(chǎn)者會不會丟消息？生產(chǎn)者會不會丟消息，取決于生產(chǎn)者對于異常情況的處理是否合理。從消息被生產(chǎn)出來，然后提交給 MQ 的過程中，只要能正常收到 （ MQ 中間件） 的 ack 確認(rèn)響應(yīng)，就表示發(fā)送成功，所以只要處理好返回值和異常，如果返回異常則進行消息重發(fā)，那么這個階段是不會出現(xiàn)消息丟失的。
• Redis 消費者會不會丟消息？不會，因為 Stream （ MQ 中間件）會自動使用內(nèi)部隊列（也稱為 PENDING List）留存消費組里每個消費者讀取的消息，但是未被確認(rèn)的消息。消費者可以在重啟后，用 XPENDING 命令查看已讀取、但尚未確認(rèn)處理完成的消息。等到消費者執(zhí)行完業(yè)務(wù)邏輯后，再發(fā)送消費確認(rèn) XACK 命令，也能保證消息的不丟失。
• Redis 隊列中間件會不會丟消息？會，Redis 在以下 2 個場景下，都會導(dǎo)致數(shù)據(jù)丟失：
• AOF 持久化配置為每秒寫盤，但這個寫盤過程是異步的，Redis 宕機時會存在數(shù)據(jù)丟失的可能
• 主從復(fù)制也是異步的，主從切換時，也存在丟失數(shù)據(jù)的可能。

可以看到，Redis 在隊列中間件環(huán)節(jié)無法保證消息不丟。像 RabbitMQ 或 Kafka 這類專業(yè)的隊列中間件，在使用時是部署一個集群，生產(chǎn)者在發(fā)布消息時，隊列中間件通常會寫「多個節(jié)點」，也就是有多個副本，這樣一來，即便其中一個節(jié)點掛了，也能保證集群的數(shù)據(jù)不丟失。

2、Redis Stream 消息可堆積嗎？

Redis 的數(shù)據(jù)都存儲在內(nèi)存中，這就意味著一旦發(fā)生消息積壓，則會導(dǎo)致 Redis 的內(nèi)存持續(xù)增長，如果超過機器內(nèi)存上限，就會面臨被 OOM 的風(fēng)險。所以 Redis 的 Stream 提供了可以指定隊列最大長度的功能，就是為了避免這種情況發(fā)生。

但 Kafka、RabbitMQ 專業(yè)的消息隊列它們的數(shù)據(jù)都是存儲在磁盤上，當(dāng)消息積壓時，無非就是多占用一些磁盤空間。

因此，把 Redis 當(dāng)作隊列來使用時，會面臨的 2 個問題：

• Redis 本身可能會丟數(shù)據(jù)；
• 面對消息擠壓，內(nèi)存資源會緊張；

所以，能不能將 Redis 作為消息隊列來使用，關(guān)鍵看你的業(yè)務(wù)場景：

• 如果你的業(yè)務(wù)場景足夠簡單，對于數(shù)據(jù)丟失不敏感，而且消息積壓概率比較小的情況下，把 Redis 當(dāng)作隊列是完全可以的。
• 如果你的業(yè)務(wù)有海量消息，消息積壓的概率比較大，并且不能接受數(shù)據(jù)丟失，那么還是用專業(yè)的消息隊列中間件吧。

參考資料：

• 《Redis 核心技術(shù)與實戰(zhàn)》
• https://www.cnblogs.com/hunternet/p/12742390.html
• https://www.cnblogs.com/qdhxhz/p/15669348.html
• https://www.cnblogs.com/bbgs-xc/p/14376109.html
• http://kaito-kidd.com/2021/04/19/can-redis-be-used-as-a-queue/

總結(jié)

Redis 常見的五種數(shù)據(jù)類型：**String（字符串），Hash（哈希），List（列表），Set（集合）及 Zset(sorted set：有序集合)**。

這五種數(shù)據(jù)類型都由多種數(shù)據(jù)結(jié)構(gòu)實現(xiàn)的，主要是出于時間和空間的考慮，當(dāng)數(shù)據(jù)量小的時候使用更簡單的數(shù)據(jù)結(jié)構(gòu)，有利于節(jié)省內(nèi)存，提高性能。

這五種數(shù)據(jù)類型與底層數(shù)據(jù)結(jié)構(gòu)對應(yīng)關(guān)系圖如下，左邊是 Redis 3.0版本的，也就是《Redis 設(shè)計與實現(xiàn)》這本書講解的版本，現(xiàn)在看還是有點過時了，右邊是現(xiàn)在 Github 最新的 Redis 代碼的。

可以看到，Redis 數(shù)據(jù)類型的底層數(shù)據(jù)結(jié)構(gòu)隨著版本的更新也有所不同，比如：

• 在 Redis 3.0 版本中 List 對象的底層數(shù)據(jù)結(jié)構(gòu)由「雙向鏈表」或「壓縮表列表」實現(xiàn)，但是在 3.2 版本之后，List 數(shù)據(jù)類型底層數(shù)據(jù)結(jié)構(gòu)是由 quicklist 實現(xiàn)的；
• 在最新的 Redis 代碼中，壓縮列表數(shù)據(jù)結(jié)構(gòu)已經(jīng)廢棄了，交由 listpack 數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)了。

Redis 五種數(shù)據(jù)類型的應(yīng)用場景：

• String 類型的應(yīng)用場景：緩存對象、常規(guī)計數(shù)、分布式鎖等。
• List 類型的應(yīng)用場景：消息隊列（有兩個問題：1. 生產(chǎn)者需要自行實現(xiàn)全局唯一 ID；2. 不能以消費組形式消費數(shù)據(jù)）等。
• Hash 類型：緩存對象、購物車等。
• Set 類型：聚合計算（并集、交集、差集）場景，比如點贊、共同關(guān)注、抽獎活動等。
• Zset 類型：排序場景，比如排行榜、電話和姓名排序等。

Redis 后續(xù)版本又支持四種數(shù)據(jù)類型，它們的應(yīng)用場景如下：

• BitMap（2.2 版新增）：二值狀態(tài)統(tǒng)計的場景，比如簽到、判斷用戶登陸狀態(tài)、連續(xù)簽到用戶總數(shù)等；
• HyperLogLog（2.8 版新增）：海量數(shù)據(jù)基數(shù)統(tǒng)計的場景，比如百萬級網(wǎng)頁 UV 計數(shù)等；
• GEO（3.2 版新增）：存儲地理位置信息的場景，比如滴滴叫車；
• Stream（5.0 版新增）：消息隊列，相比于基于 List 類型實現(xiàn)的消息隊列，有這兩個特有的特性：自動生成全局唯一消息ID，支持以消費組形式消費數(shù)據(jù)。

針對 Redis 是否適合做消息隊列，關(guān)鍵看你的業(yè)務(wù)場景：

• 如果你的業(yè)務(wù)場景足夠簡單，對于數(shù)據(jù)丟失不敏感，而且消息積壓概率比較小的情況下，把 Redis 當(dāng)作隊列是完全可以的。
• 如果你的業(yè)務(wù)有海量消息，消息積壓的概率比較大，并且不能接受數(shù)據(jù)丟失，那么還是用專業(yè)的消息隊列中間件吧。

原文鏈接：https://mp.weixin.qq.com/s/r9_0xpRsp2ubgyvpiyMfuw