2 萬字 + 20張圖｜ 細說 Redis 九種資料型別和應用場景

我們都知道 Redis 提供了豐富的資料型別，常見的有五種：String（字串），Hash（雜湊），List（列表），Set（集合）、Zset（有序集合）。

隨著 Redis 版本的更新，後面又支援了四種資料型別：BitMap（2.2 版新增）、HyperLogLog（2.8 版新增）、GEO（3.2 版新增）、Stream（5.0 版新增）。

每種資料物件都各自的應用場景，你能說出它們各自的應用場景嗎？

面試過程中，這個問題也很常被問到，又比如會舉例一個應用場景來問你，讓你說使用哪種 Redis 資料型別來實現。

所以，這次我們就來學習 Redis 資料型別的使用以及應用場景。篇幅比較長，大家收藏慢慢看。

String

介紹

String 是最基本的 key-value 結構，key 是唯一標識，value 是具體的值，value其實不僅是字串， 也可以是數字（整數或浮點數），value 最多可以容納的資料長度是 512M。

內部實現

String 型別的底層的資料結構實現主要是 int 和 SDS（簡單動態字串）。

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

• SDS  不僅可以儲存文字資料，還可以儲存二進位制資料。因為 SDS 使用 len 屬性的值而不是空字元來判斷字串是否結束，並且 SDS 的所有 API 都會以處理二進位制的方式來處理 SDS 存放在 buf[] 陣列裡的資料。所以 SDS 不光能存放文字資料，而且能儲存圖片、音訊、影片、壓縮檔案這樣的二進位制資料。
• **SDS 獲取字串長度的時間複雜度是 O(1)**。因為 C 語言的字串並不記錄自身長度，所以獲取長度的複雜度為 O(n)；而 SDS 結構裡用 len 屬性記錄了字串長度，所以複雜度為 O(1)。
• Redis 的 SDS API 是安全的，拼接字串不會造成緩衝區溢位。因為 SDS 在拼接字串之前會檢查 SDS 空間是否滿足要求，如果空間不夠會自動擴容，所以不會導致緩衝區溢位的問題。

字串物件的內部編碼（encoding）有 3 種 ：int、raw和 embstr。

如果一個字串物件儲存的是整數值，並且這個整數值可以用long型別來表示，那麼字串物件會將整數值儲存在字串物件結構的ptr屬性裡面（將void*轉換成 long），並將字串物件的編碼設定為int。

如果字串物件儲存的是一個字串，並且這個字元申的長度小於等於 32 位元組，那麼字串物件將使用一個簡單動態字串（SDS）來儲存這個字串，並將物件的編碼設定為embstr， embstr編碼是專門用於儲存短字串的一種最佳化編碼方式：

如果字串物件儲存的是一個字串，並且這個字串的長度大於 32 位元組，那麼字串物件將使用一個簡單動態字串（SDS）來儲存這個字串，並將物件的編碼設定為raw：

可以看到embstr和raw編碼都會使用SDS來儲存值，但不同之處在於embstr會透過一次記憶體分配函式來分配一塊連續的記憶體空間來儲存redisObject和SDS，而raw編碼會透過呼叫兩次記憶體分配函式來分別分配兩塊空間來儲存redisObject和SDS。Redis這樣做會有很多好處：

• embstr編碼將建立字串物件所需的記憶體分配次數從 raw 編碼的兩次降低為一次；
• 釋放 embstr編碼的字串物件同樣只需要呼叫一次記憶體釋放函式；
• 因為embstr編碼的字串物件的所有資料都儲存在一塊連續的記憶體裡面可以更好的利用 CPU 快取提升效能。

但是 embstr 也有缺點的：

• 如果字串的長度增加需要重新分配記憶體時，整個redisObject和sds都需要重新分配空間，所以embstr編碼的字串物件實際上是隻讀的，redis沒有為embstr編碼的字串物件編寫任何相應的修改程式。當我們對embstr編碼的字串物件執行任何修改命令（例如append）時，程式會先將物件的編碼從embstr轉換成raw，然後再執行修改命令。

常用指令

普通字串的基本操作：

# 設定 key-value 型別的值
> SET name lin
OK
# 根據 key 獲得對應的 value
> GET name
"lin"
# 判斷某個 key 是否存在
> EXISTS name
(integer) 1
# 返回 key 所儲存的字串值的長度
> STRLEN name
(integer) 3
# 刪除某個 key 對應的值
> DEL name
(integer) 1

批次設定 :

# 批次設定 key-value 型別的值
> MSET key1 value1 key2 value2 
OK
# 批次獲取多個 key 對應的 value
> MGET key1 key2 
1) "value1"
2) "value2"

計數器（字串的內容為整數的時候可以使用）：

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

過期（預設為永不過期）：

# 設定 key 在 60 秒後過期（該方法是針對已經存在的key設定過期時間）
> EXPIRE name  60 
(integer) 1
# 檢視資料還有多久過期
> TTL name 
(integer) 51

#設定 key-value 型別的值，並設定該key的過期時間為 60 秒
> SET key  value EX 60
OK
> SETEX key  60 value
OK

不存在就插入：

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

應用場景

快取物件

使用 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。

常規計數

因為 Redis 處理命令是單執行緒，所以執行命令的過程是原子的。因此 String 資料型別適合計數場景，比如計算訪問次數、點贊、轉發、庫存數量等等。

比如計算文章的閱讀量：

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

分散式鎖

SET 命令有個 NX 引數可以實現「key不存在才插入」，可以用它來實現分散式鎖：

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

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

SET lock_key unique_value NX PX 10000

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

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

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

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

這樣一來，就透過使用 SET 命令和 Lua 指令碼在 Redis 單節點上完成了分散式鎖的加鎖和解鎖。

List

介紹

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

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

內部實現

List 型別的底層資料結構是由雙向連結串列或壓縮列表實現的：

• 如果列表的元素個數小於 512 個（預設值，可由 list-max-ziplist-entries 配置），列表每個元素的值都小於 64 位元組（預設值，可由 list-max-ziplist-value 配置），Redis 會使用壓縮列表作為 List 型別的底層資料結構；
• 如果列表的元素不滿足上面的條件，Redis 會使用雙向連結串列作為 List 型別的底層資料結構；

但是在 Redis 3.2 版本之後，List 資料型別底層資料結構就只由 quicklist 實現了，替代了雙向連結串列和壓縮列表。

常用命令

# 將一個或多個值value插入到key列表的表頭(最左邊)，最後的值在最前面
LPUSH key value [value ...] 
# 將一個或多個值value插入到key列表的表尾(最右邊)
RPUSH key value [value ...]
# 移除並返回key列表的頭元素
LPOP key     
# 移除並返回key列表的尾元素
RPOP key 

# 返回列表key中指定區間內的元素，區間以偏移量start和stop指定，從0開始
LRANGE key start stop

# 從key列表表頭彈出一個元素，沒有就阻塞timeout秒，如果timeout=0則一直阻塞
BLPOP key [key ...] timeout
# 從key列表表尾彈出一個元素，沒有就阻塞timeout秒，如果timeout=0則一直阻塞
BRPOP key [key ...] timeout

應用場景

訊息佇列

訊息佇列在存取訊息時，必須要滿足三個需求，分別是訊息保序、處理重複的訊息和保證訊息可靠性。

Redis 的 List 和 Stream 兩種資料型別，就可以滿足訊息佇列的這三個需求。我們先來了解下基於 List 的訊息佇列實現方法，後面在介紹 Stream 資料型別時候，在詳細說說 Stream。

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

List 本身就是按先進先出的順序對資料進行存取的，所以，如果使用 List 作為訊息佇列儲存訊息的話，就已經能滿足訊息保序的需求了。

List 可以使用 LPUSH + RPOP （或者反過來，RPUSH+LPOP）命令實現訊息佇列。

• 生產者使用 LPUSH key value[value...] 將訊息插入到佇列的頭部，如果 key 不存在則會建立一個空的佇列再插入訊息。

• 消費者使用 RPOP key 依次讀取佇列的訊息，先進先出。

不過，在消費者讀取資料時，有一個潛在的效能風險點。

在生產者往 List 中寫入資料時，List 並不會主動地通知消費者有新訊息寫入，如果消費者想要及時處理訊息，就需要在程式中不停地呼叫 RPOP 命令（比如使用一個while(1)迴圈）。如果有新訊息寫入，RPOP命令就會返回結果，否則，RPOP命令返回空值，再繼續迴圈。

所以，即使沒有新訊息寫入List，消費者也要不停地呼叫 RPOP 命令，這就會導致消費者程式的 CPU 一直消耗在執行 RPOP 命令上，帶來不必要的效能損失。

為了解決這個問題，Redis提供了 BRPOP 命令。BRPOP命令也稱為阻塞式讀取，客戶端在沒有讀到佇列資料時，自動阻塞，直到有新的資料寫入佇列，再開始讀取新資料。和消費者程式自己不停地呼叫RPOP命令相比，這種方式能節省CPU開銷。

2、如何處理重複的訊息？

消費者要實現重複訊息的判斷，需要 2 個方面的要求：

• 每個訊息都有一個全域性的 ID。
• 消費者要記錄已經處理過的訊息的 ID。當收到一條訊息後，消費者程式就可以對比收到的訊息 ID 和記錄的已處理過的訊息 ID，來判斷當前收到的訊息有沒有經過處理。如果已經處理過，那麼，消費者程式就不再進行處理了。

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

例如，我們執行以下命令，就把一條全域性 ID 為 111000102、庫存量為 99 的訊息插入了訊息佇列：

> LPUSH mq "111000102:stock:99"
(integer) 1

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

當消費者程式從 List 中讀取一條訊息後，List 就不會再留存這條訊息了。所以，如果消費者程式在處理訊息的過程出現了故障或當機，就會導致訊息沒有處理完成，那麼，消費者程式再次啟動後，就沒法再次從 List 中讀取訊息了。

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

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

好了，到這裡可以知道基於 List 型別的訊息佇列，滿足訊息佇列的三大需求（訊息保序、處理重複的訊息和保證訊息可靠性）。

• 訊息保序：使用 LPUSH + RPOP；
• 阻塞讀取：使用 BRPOP；
• 重複訊息處理：生產者自行實現全域性唯一 ID；
• 訊息的可靠性：使用 BRPOPLPUSH

但是，在用 List 做訊息佇列時，如果生產者訊息傳送很快，而消費者處理訊息的速度比較慢，這就導致 List 中的訊息越積越多，給 Redis 的記憶體帶來很大壓力。

要解決這個問題，就要啟動多個消費者程式組成一個消費組，一起分擔處理 List 中的訊息。但是，List 型別並不支援消費組的實現。

這就要說起 Redis 從 5.0 版本開始提供的 Stream 資料型別了，Stream 同樣能夠滿足訊息佇列的三大需求，而且它還支援「消費組」形式的訊息讀取。

Hash

介紹

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

Hash 與 String 物件的區別如下圖所示:

內部實現

Hash 型別的底層資料結構是由壓縮列表或雜湊表實現的：

• 如果雜湊型別元素個數小於 512 個（預設值，可由 hash-max-ziplist-entries 配置），所有值小於 64 位元組（預設值，可由 hash-max-ziplist-value 配置）的話，Redis 會使用壓縮列表作為 Hash 型別的底層資料結構；
• 如果雜湊型別元素不滿足上面條件，Redis 會使用雜湊表作為 Hash 型別的 底層資料結構。

在 Redis 7.0 中，壓縮列表資料結構已經廢棄了，交由 listpack 資料結構來實現了。

常用命令

# 儲存一個雜湊表key的鍵值
HSET key field value   
# 獲取雜湊表key對應的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的數量
HLEN key       
# 返回雜湊表key中所有的鍵值
HGETALL key 

# 為雜湊表key中field鍵的值加上增量n
HINCRBY key field n                         

應用場景

快取物件

Hash 型別的 （key，field， value） 的結構與物件的（物件id， 屬性， 值）的結構相似，也可以用來儲存物件。

我們以使用者資訊為例，它在關係型資料庫中的結構是這樣的：

我們可以使用如下命令，將使用者物件的資訊儲存到 Hash 型別：

# 儲存一個雜湊表uid:1的鍵值
> HSET uid:1 name Tom age 15
2
# 儲存一個雜湊表uid:2的鍵值
> HSET uid:2 name Jerry age 13
2
# 獲取雜湊表使用者id為1中所有的鍵值
> HGETALL uid:1
1) "name"
2) "Tom"
3) "age"
4) "15"

Redis Hash 儲存其結構如下圖：

在介紹 String 型別的應用場景時有所介紹，String + Json也是儲存物件的一種方式，那麼儲存物件時，到底用 String + json 還是用 Hash 呢？

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

購物車

以使用者 id 為 key，商品 id 為 field，商品數量為 value，恰好構成了購物車的3個要素，如下圖所示。

涉及的命令如下：

• 新增商品：HSET  cart:{使用者id}  {商品id}  1
• 新增數量：HINCRBY  cart:{使用者id}  {商品id}  1
• 商品總數：HLEN  cart:{使用者id}
• 刪除商品：HDEL  cart:{使用者id}  {商品id}
• 獲取購物車所有商品：HGETALL  cart:{使用者id}

當前僅僅是將商品ID儲存到了Redis 中，在回顯商品具體資訊的時候，還需要拿著商品 id 查詢一次資料庫，獲取完整的商品的資訊。

Set

介紹

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

一個集合最多可以儲存 2^32-1 個元素。概念和數學中個的集合基本類似，可以交集，並集，差集等等，所以 Set 型別除了支援集合內的增刪改查，同時還支援多個集合取交集、並集、差集。

Set 型別和 List 型別的區別如下：

• List 可以儲存重複元素，Set 只能儲存非重複元素；
• List 是按照元素的先後順序儲存元素的，而 Set 則是無序方式儲存元素的。

內部實現

Set 型別的底層資料結構是由雜湊表或整數集合實現的：

• 如果集合中的元素都是整數且元素個數小於 512 （預設值，set-maxintset-entries配置）個，Redis 會使用整數集合作為 Set 型別的底層資料結構；
• 如果集合中的元素不滿足上面條件，則 Redis 使用雜湊表作為 Set 型別的底層資料結構。

常用命令

Set常用操作：

# 往集合key中存入元素，元素存在則忽略，若key不存在則新建
SADD key member [member ...]
# 從集合key中刪除元素
SREM key member [member ...] 
# 獲取集合key中所有元素
SMEMBERS key
# 獲取集合key中的元素個數
SCARD key

# 判斷member元素是否存在於集合key中
SISMEMBER key member

# 從集合key中隨機選出count個元素，元素不從key中刪除
SRANDMEMBER key [count]
# 從集合key中隨機選出count個元素，元素從key中刪除
SPOP key [count]

Set運算操作：

# 交集運算
SINTER key [key ...]
# 將交集結果存入新集合destination中
SINTERSTORE destination key [key ...]

# 並集運算
SUNION key [key ...]
# 將並集結果存入新集合destination中
SUNIONSTORE destination key [key ...]

# 差集運算
SDIFF key [key ...]
# 將差集結果存入新集合destination中
SDIFFSTORE destination key [key ...]

應用場景

集合的主要幾個特性，無序、不可重複、支援並交差等操作。

因此 Set 型別比較適合用來資料去重和保障資料的唯一性，還可以用來統計多個集合的交集、錯集和並集等，當我們儲存的資料是無序並且需要去重的情況下，比較適合使用集合型別進行儲存。

但是要提醒你一下，這裡有一個潛在的風險。Set 的差集、並集和交集的計算複雜度較高，在資料量較大的情況下，如果直接執行這些計算，會導致 Redis 例項阻塞。

在主從叢集中，為了避免主庫因為 Set 做聚合計算（交集、差集、並集）時導致主庫被阻塞，我們可以選擇一個從庫完成聚合統計，或者把資料返回給客戶端，由客戶端來完成聚合統計。

點贊

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:1
1) "uid:3"
2) "uid:2"

獲取 article:1 文章的點贊使用者數量：

> SCARD article:1
(integer) 2

判斷使用者 uid:1 是否對文章 article:1 點讚了：

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

共同關注

Set 型別支援交集運算，所以可以用來計算共同關注的好友、公眾號等。

key 可以是使用者id，value 則是已關注的公眾號的id。

uid:1 使用者關注公眾號 id 為 5、6、7、8、9，uid:2  使用者關注公眾號 id 為 7、8、9、10、11。

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

uid:1  和 uid:2  共同關注的公眾號：

# 獲取共同關注
> SINTER uid:1 uid:2
1) "7"
2) "8"
3) "9"

給  uid:2   推薦 uid:1 關注的公眾號：

> SDIFF uid:1 uid:2
1) "5"
2) "6"

驗證某個公眾號是否同時被  uid:1   或  uid:2   關注:

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

抽獎活動

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

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

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

如果允許重複中獎，可以使用 SRANDMEMBER 命令。

# 抽取 1 個一等獎：
> SRANDMEMBER lucky 1
1) "Tom"
# 抽取 2 個二等獎：
> SRANDMEMBER lucky 2
1) "Mark"
2) "Jerry"
# 抽取 3 個三等獎：
> SRANDMEMBER lucky 3
1) "Sary"
2) "Tom"
3) "Jerry"

如果不允許重複中獎，可以使用 SPOP 命令。

# 抽取一等獎1個
> SPOP lucky 1
1) "Sary"
# 抽取二等獎2個
> SPOP lucky 2
1) "Jerry"
2) "Mark"
# 抽取三等獎3個
> SPOP lucky 3
1) "John"
2) "Sean"
3) "Lindy"

Zset

介紹

Zset 型別（有序集合型別）相比於 Set 型別多了一個排序屬性 score（分值），對於有序集合 ZSet 來說，每個儲存元素相當於有兩個值組成的，一個是有序結合的元素值，一個是排序值。

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

內部實現

Zset 型別的底層資料結構是由壓縮列表或跳錶實現的：

• 如果有序集合的元素個數小於 128 個，並且每個元素的值小於 64 位元組時，Redis 會使用壓縮列表作為 Zset 型別的底層資料結構；
• 如果有序集合的元素不滿足上面的條件，Redis 會使用跳錶作為 Zset 型別的底層資料結構；

在 Redis 7.0 中，壓縮列表資料結構已經廢棄了，交由 listpack 資料結構來實現了。

常用命令

Zset 常用操作：

# 往有序集合key中加入帶分值元素
ZADD key score member [[score member]...]   
# 往有序集合key中刪除元素
ZREM key member [member...]                 
# 返回有序集合key中元素member的分值
ZSCORE key member
# 返回有序集合key中元素個數
ZCARD key 

# 為有序集合key中元素member的分值加上increment
ZINCRBY key increment member 

# 正序獲取有序集合key從start下標到stop下標的元素
ZRANGE key start stop [WITHSCORES]
# 倒序獲取有序集合key從start下標到stop下標的元素
ZREVRANGE key start stop [WITHSCORES]

# 返回有序集合中指定分數區間內的成員，分數由低到高排序。
ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]

# 返回指定成員區間內的成員，按字典正序排列, 分數必須相同。
ZRANGEBYLEX key min max [LIMIT offset count]
# 返回指定成員區間內的成員，按字典倒序排列, 分數必須相同
ZREVRANGEBYLEX key max min [LIMIT offset count]

Zset 運算操作（相比於 Set 型別，ZSet 型別沒有支援差集運算）：

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

應用場景

Zset 型別（Sorted Set，有序集合） 可以根據元素的權重來排序，我們可以自己來決定每個元素的權重值。比如說，我們可以根據元素插入 Sorted Set 的時間確定權重值，先插入的元素權重小，後插入的元素權重大。

在面對需要展示最新列表、排行榜等場景時，如果資料更新頻繁或者需要分頁顯示，可以優先考慮使用 Sorted Set。

排行榜

有序集合比較典型的使用場景就是排行榜。例如學生成績的排名榜、遊戲積分排行榜、影片播放排名、電商系統中商品的銷量排名等。

我們以博文點贊排名為例，小林發表了五篇博文，分別獲得贊為 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"

檢視某篇文章的贊數，可以使用 ZSCORE 命令（返回有序集合key中元素個數）：

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

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

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

獲取小林 100 贊到 200 讚的文章，可以使用 ZRANGEBYSCORE 命令（返回有序集合中指定分數區間內的成員，分數由低到高排序）：

> ZRANGEBYSCORE user:xiaolin:ranking 100 200 WITHSCORES
1) "arcticle:3"
2) "100"
3) "arcticle:5"
4) "150"
5) "arcticle:1"
6) "200"

電話、姓名排序

使用有序集合的 ZRANGEBYLEX 或 ZREVRANGEBYLEX 可以幫助我們實現電話號碼或姓名的排序，我們以 ZRANGEBYLEX （返回指定成員區間內的成員，按 key 正序排列，分數必須相同）為例。

注意：不要在分數不一致的 SortSet 集合中去使用 ZRANGEBYLEX和 ZREVRANGEBYLEX 指令，因為獲取的結果會不準確。

1、電話排序

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

> 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 (133
1) "13200111100"
2) "13210414300"
3) "13252110901"

獲取132、133號段的號碼：

> ZRANGEBYLEX phone [132 (134
1) "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 (B
1) "Aidehua"
2) "Aimini"

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

> ZRANGEBYLEX names [C [Z
1) "Gaodeng"
2) "Jake"
3) "Toumas"

BitMap

介紹

Bitmap，即點陣圖，是一串連續的二進位制陣列（0和1），可以透過偏移量（offset）定位元素。BitMap透過最小的單位bit來進行0|1的設定，表示某個元素的值或者狀態，時間複雜度為O(1)。

由於 bit 是計算機中最小的單位，使用它進行儲存將非常節省空間，特別適合一些資料量大且使用二值統計的場景。

內部實現

Bitmap 本身是用 String 型別作為底層資料結構實現的一種統計二值狀態的資料型別。

String 型別是會儲存為二進位制的位元組陣列，所以，Redis 就把位元組陣列的每個 bit 位利用起來，用來表示一個元素的二值狀態，你可以把 Bitmap 看作是一個 bit 陣列。

常用命令

bitmap 基本操作：

# 設定值，其中value只能是 0 和 1
SETBIT key offset value

# 獲取值
GETBIT key offset

# 獲取指定範圍內值為 1 的個數
# start 和 end 以位元組為單位
BITCOUNT key start end

bitmap 運算操作：

# BitMap間的運算
# operations 位移運算子，列舉值
  AND 與運算 &
  OR 或運算 |
  XOR 異或 ^
  NOT 取反 ~
# result 計算的結果，會儲存在該key中
# key1 … keyn 參與運算的key，可以有多個，空格分割，not運算只能一個key
# 當 BITOP 處理不同長度的字串時，較短的那個字串所缺少的部分會被看作 0。返回值是儲存到 destkey 的字串的長度（以位元組byte為單位），和輸入 key 中最長的字串長度相等。
BITOP [operations] [result] [key1] [keyn…]

# 返回指定key中第一次出現指定value(0/1)的位置
BITPOS [key] [value]

應用場景

Bitmap 型別非常適合二值狀態統計的場景，這裡的二值狀態就是指集合元素的取值就只有 0 和 1 兩種，在記錄海量資料時，Bitmap 能夠有效地節省記憶體空間。

簽到統計

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

簽到統計時，每個使用者一天的簽到用 1 個 bit 位就能表示，一個月（假設是 31 天）的簽到情況用 31 個 bit 位就可以，而一年的簽到也只需要用 365 個 bit 位，根本不用太複雜的集合型別。

假設我們要統計 ID 100 的使用者在 2022 年 6 月份的簽到情況，就可以按照下面的步驟進行操作。

第一步，執行下面的命令，記錄該使用者 6 月 3 號已簽到。

SETBIT uid:sign:100:202206 2 1

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

GETBIT uid:sign:100:202206 2 

第三步，統計該使用者在 6 月份的簽到次數。

BITCOUNT uid:sign:100:202206

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

如何統計這個月首次打卡時間呢？

Redis 提供了 BITPOS key bitValue [start] [end]指令，返回資料表示 Bitmap 中第一個值為 bitValue 的 offset 位置。

在預設情況下， 命令將檢測整個點陣圖， 使用者可以透過可選的 start 引數和 end 引數指定要檢測的範圍。所以我們可以透過執行這條命令來獲取 userID = 100 在 2022 年 6 月份首次打卡日期：

BITPOS uid:sign:100:202206 1

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

判斷使用者登陸態

Bitmap 提供了 GETBIT、SETBIT 操作，透過一個偏移值 offset 對 bit 陣列的 offset 位置的 bit 位進行讀寫操作，需要注意的是 offset 從 0 開始。

只需要一個 key = login_status 表示儲存使用者登陸狀態集合資料， 將使用者 ID 作為 offset，線上就設定為 1，下線設定 0。透過 GETBIT判斷對應的使用者是否線上。50000 萬 使用者只需要 6 MB 的空間。

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

第一步，執行以下指令，表示使用者已登入。

SETBIT login_status 10086 1

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

GETBIT login_status 10086

第三步，登出，將 offset 對應的 value 設定成 0。

SETBIT login_status 10086 0

連續簽到使用者總數

如何統計出這連續 7 天連續打卡使用者總數呢？

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

key 對應的集合的每個 bit 位的資料則是一個使用者在該日期的打卡記錄。

一共有 7 個這樣的 Bitmap，如果我們能對這 7 個 Bitmap 的對應的 bit 位做 『與』運算。同樣的 UserID offset 都是一樣的，當一個 userID 在 7 個 Bitmap 對應對應的 offset 位置的 bit = 1 就說明該使用者 7 天連續打卡。

結果儲存到一個新 Bitmap 中，我們再透過 BITCOUNT 統計 bit = 1 的個數便得到了連續打卡 3 天的使用者總數了。

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

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

舉個例子，比如將三個 bitmap 進行 AND 操作，並將結果儲存到 destmap 中，接著對 destmap 執行 BITCOUNT 統計。

# 與操作
BITOP AND destmap bitmap:01 bitmap:02 bitmap:03
# 統計 bit 位 =  1 的個數
BITCOUNT destmap

即使一天產生一個億的資料，Bitmap 佔用的記憶體也不大，大約佔 12 MB 的記憶體（10^8/8/1024/1024），7 天的 Bitmap 的記憶體開銷約為 84 MB。同時我們最好給 Bitmap 設定過期時間，讓 Redis 刪除過期的打卡資料，節省記憶體。

HyperLogLog

介紹

Redis HyperLogLog 是 Redis 2.8.9 版本新增的資料型別，是一種用於「統計基數」的資料集合型別，基數統計就是指統計一個集合中不重複的元素個數。但要注意，HyperLogLog 是統計規則是基於機率完成的，不是非常準確，標準誤算率是 0.81%。

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

HyperLogLog 的優點是，在輸入元素的數量或者體積非常非常大時，計算基數所需的記憶體空間總是固定的、並且是很小的。

在 Redis 裡面，每個 HyperLogLog 鍵只需要花費 12 KB 記憶體，就可以計算接近 2^64 個不同元素的基數，和元素越多就越耗費記憶體的 Set 和 Hash 型別相比，HyperLogLog 就非常節省空間。

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

用 Java 語言來說，一般 long 型別佔用 8 位元組，而 1 位元組有 8 位，即：1 byte = 8 bit，即 long 資料型別最大可以表示的數是：2^63-1。對應上面的2^64個數，假設此時有2^63-1這麼多個數，從 0 ~ 2^63-1，按照long以及1k = 1024 位元組的規則來計算記憶體總數，就是：((2^63-1) * 8/1024)K，這是很龐大的一個數，儲存空間遠遠超過12K，而 HyperLogLog 卻可以用 12K 就能統計完。

內部實現

HyperLogLog 的實現涉及到很多數學問題，太費腦子了，我也沒有搞懂。

常見命令

HyperLogLog 命令很少，就三個。

# 新增指定元素到 HyperLogLog 中
PFADD key element [element ...]

# 返回給定 HyperLogLog 的基數估算值。
PFCOUNT key [key ...]

# 將多個 HyperLogLog 合併為一個 HyperLogLog
PFMERGE destkey sourcekey [sourcekey ...]

應用場景

百萬級網頁 UV 計數

Redis HyperLogLog  優勢在於只需要花費 12 KB 記憶體，就可以計算接近 2^64 個元素的基數，和元素越多就越耗費記憶體的 Set 和 Hash 型別相比，HyperLogLog 就非常節省空間。

所以，非常適合統計百萬級以上的網頁 UV 的場景。

在統計 UV 時，你可以用 PFADD 命令（用於向 HyperLogLog 中新增新元素）把訪問頁面的每個使用者都新增到 HyperLogLog 中。

PFADD page1:uv user1 user2 user3 user4 user5

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

PFCOUNT page1:uv

不過，有一點需要你注意一下，HyperLogLog 的統計規則是基於機率完成的，所以它給出的統計結果是有一定誤差的，標準誤算率是 0.81%。

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

GEO

Redis GEO 是 Redis 3.2 版本新增的資料型別，主要用於儲存地理位置資訊，並對儲存的資訊進行操作。

在日常生活中，我們越來越依賴搜尋“附近的餐館”、在叫車軟體上叫車，這些都離不開基於位置資訊服務（Location-Based Service，LBS）的應用。LBS 應用訪問的資料是和人或物關聯的一組經緯度資訊，而且要能查詢相鄰的經緯度範圍，GEO 就非常適合應用在 LBS 服務的場景中。

內部實現

GEO 本身並沒有設計新的底層資料結構，而是直接使用了 Sorted Set 集合型別。

GEO 型別使用 GeoHash 編碼方法實現了經緯度到 Sorted Set 中元素權重分數的轉換，這其中的兩個關鍵機制就是「對二維地圖做區間劃分」和「對區間進行編碼」。一組經緯度落在某個區間後，就用區間的編碼值來表示，並把編碼值作為 Sorted Set 元素的權重分數。

這樣一來，我們就可以把經緯度儲存到 Sorted Set 中，利用 Sorted Set 提供的“按權重進行有序範圍查詢”的特性，實現 LBS 服務中頻繁使用的“搜尋附近”的需求。

常用命令

# 儲存指定的地理空間位置，可以將一個或多個經度(longitude)、緯度(latitude)、位置名稱(member)新增到指定的 key 中。
GEOADD key longitude latitude member [longitude latitude member ...]

# 從給定的 key 裡返回所有指定名稱(member)的位置（經度和緯度），不存在的返回 nil。
GEOPOS key member [member ...]

# 返回兩個給定位置之間的距離。
GEODIST key member1 member2 [m|km|ft|mi]

# 根據使用者給定的經緯度座標來獲取指定範圍內的地理位置集合。
GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]

應用場景

滴滴叫車

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

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

執行下面的這個命令，就可以把 ID 號為 33 的車輛的當前經緯度位置存入 GEO 集合中：

GEOADD cars:locations 116.034579 39.030452 33

當使用者想要尋找自己附近的網約車時，LBS 應用就可以使用 GEORADIUS 命令。

例如，LBS 應用執行下面的命令時，Redis 會根據輸入的使用者的經緯度資訊（116.054579，39.030452 ），查詢以這個經緯度為中心的 5 公里內的車輛資訊，並返回給 LBS 應用。

GEORADIUS cars:locations 116.054579 39.030452 5 km ASC COUNT 10

Stream

介紹

Redis Stream 是 Redis 5.0 版本新增加的資料型別，Redis 專門為訊息佇列設計的資料型別。

在前面介紹 List 型別實現的訊息佇列，有兩個問題：1. 生產者需要自行實現全域性唯一 ID；2. 不能以消費組形式消費資料。

基於 Stream 型別的訊息佇列就解決上面的問題，它不僅支援自動生成全域性唯一 ID，而且支援以消費組形式消費資料。

常見命令

Stream 訊息佇列操作命令：

• XADD：插入訊息，保證有序，可以自動生成全域性唯一 ID；
• XREAD：用於讀取訊息，可以按 ID 讀取資料；
• XREADGROUP：按消費組形式讀取訊息；
• XPENDING 和 XACK：
• XPENDING 命令可以用來查詢每個消費組內所有消費者已讀取但尚未確認的訊息，而 XACK 命令用於向訊息佇列確認訊息處理已完成。

應用場景

訊息佇列

生產者透過 XADD 命令插入一條訊息：

# * 表示讓 Redis 為插入的資料自動生成一個全域性唯一的 ID
# 往名稱為 mymq 的訊息佇列中插入一條訊息，訊息的鍵是 name，值是 xiaolin
> XADD mymq * name xiaolin
"1654254953808-0"

插入成功後會返回全域性唯一的 ID："1654254953808-0"。訊息的全域性唯一 ID 由兩部分組成：

• 第一部分“1654254953808”是資料插入時，以毫秒為單位計算的當前伺服器時間；
• 第二部分表示插入訊息在當前毫秒內的訊息序號，這是從 0 開始編號的。例如，“1654254953808-0”就表示在“1654254953808”毫秒內的第 1 條訊息。

消費者透過 XREAD 命令從訊息佇列中讀取訊息時，可以指定一個訊息 ID，並從這個訊息 ID 的下一條訊息開始進行讀取（注意是輸入訊息 ID 的下一條資訊開始讀取，不是查詢輸入ID的訊息）。

# 從 ID 號為 1654254953807-0 的訊息開始，讀取後續的所有訊息（示例中一共 1 條）。
> XREAD Stream mymq 1654254953807-0
1) 1) "mymq"
   2) 1) 1) "1654254953808-0"
         2) 1) "name"
            2) "xiaolin"

如果想要實現阻塞讀（當沒有資料時，阻塞住），可以呼叫 XRAED 時設定 block 配置項，實現類似於 BRPOP 的阻塞讀取操作。

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

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

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

Stream 可以以使用 XGROUP 建立消費組，建立消費組之後，Stream 可以使用 XREADGROUP 命令讓消費組內的消費者讀取訊息。

建立一個名為 group1 的消費組，這個消費組消費的訊息佇列是 mymq：

# 建立一個名為 group1 的消費組
> XGROUP create mymq group1 0
OK

消費組 group1 內的消費者  consumer1 從 mymq 訊息佇列中讀取所有訊息的命令如下：

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

訊息佇列中的訊息一旦被消費組裡的一個消費者讀取了，就不能再被該消費組內的其他消費者讀取了。

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

> XREADGROUP group group1 consumer1 Stream mymq >
(nil)

使用消費組的目的是讓組內的多個消費者共同分擔讀取訊息，所以，我們通常會讓每個消費者讀取部分訊息，從而實現訊息讀取負載在多個消費者間是均衡分佈的。

例如，我們執行下列命令，讓 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 實現的訊息佇列，如何保證消費者在發生故障或當機再次重啟後，仍然可以讀取未處理完的訊息？

Streams 會自動使用內部佇列（也稱為 PENDING List）留存消費組裡每個消費者讀取的訊息，直到消費者使用 XACK 命令通知 Streams“訊息已經處理完成”。

如果消費者沒有成功處理訊息，它就不會給 Streams 傳送 XACK 命令，訊息仍然會留存。此時，消費者可以在重啟後，用 XPENDING 命令檢視已讀取、但尚未確認處理完成的訊息。

例如，我們來檢視一下 group2 中各個消費者已讀取、但尚未確認的訊息個數，命令如下：

127.0.0.1:6379> XPENDING mymq group2
1) (integer) 3
2) "1654254953808-0"  # 表示 group2 中所有消費者讀取的訊息最小 ID
3) "1654256271337-0"  # 表示 group2 中所有消費者讀取的訊息最大 ID
4) 1) 1) "consumer1"
      2) "1"
   2) 1) "consumer2"
      2) "1"
   3) 1) "consumer3"
      2) "1"

如果想檢視某個消費者具體讀取了哪些資料，可以執行下面的命令：

# 檢視 group2 裡 consumer2 已從 mymq 訊息佇列中讀取了哪些訊息
> XPENDING mymq group2 - + 10 consumer2
1) 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

當我們再使用 XPENDING 命令檢視時，就可以看到，consumer2 已經沒有已讀取、但尚未確認處理的訊息了。

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

好了，基於 Stream 實現的訊息佇列就說到這裡了，小結一下：

• 訊息保序：XADD/XREAD
• 阻塞讀取：XREAD block
• 重複訊息處理：Stream 在使用  XADD 命令，會自動生成全域性唯一 ID；
• 訊息可靠性：內部使用 PENDING List 自動儲存訊息，使用 XPENDING 命令檢視消費組已經讀取但是未被確認的訊息，消費者使用 XACK 確認訊息；
• 支援消費組形式消費資料

Redis 基於 Stream 訊息佇列與專業的訊息佇列有哪些差距？

一個專業的訊息佇列，必須要做到兩大塊：

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

1、Redis Stream 訊息會丟失嗎？

使用一個訊息佇列，其實就分為三大塊：生產者、佇列中介軟體、消費者，所以要保證訊息就是保證三個環節都不能丟失資料。

Redis Stream 訊息佇列能不能保證三個環節都不丟失資料？

• Redis 生產者會不會丟訊息？生產者會不會丟訊息，取決於生產者對於異常情況的處理是否合理。從訊息被生產出來，然後提交給 MQ 的過程中，只要能正常收到 （ MQ 中介軟體） 的 ack 確認響應，就表示傳送成功，所以只要處理好返回值和異常，如果返回異常則進行訊息重發，那麼這個階段是不會出現訊息丟失的。
• Redis 消費者會不會丟訊息？不會，因為 Stream （ MQ 中介軟體）會自動使用內部佇列（也稱為 PENDING List）留存消費組裡每個消費者讀取的訊息，但是未被確認的訊息。消費者可以在重啟後，用 XPENDING 命令檢視已讀取、但尚未確認處理完成的訊息。等到消費者執行完業務邏輯後，再傳送消費確認 XACK 命令，也能保證訊息的不丟失。
• Redis 佇列中介軟體會不會丟訊息？會，Redis 在以下 2 個場景下，都會導致資料丟失：
• AOF 持久化配置為每秒寫盤，但這個寫盤過程是非同步的，Redis 當機時會存在資料丟失的可能
• 主從複製也是非同步的，主從切換時，也存在丟失資料的可能。

可以看到，Redis 在佇列中介軟體環節無法保證訊息不丟。像 RabbitMQ 或 Kafka 這類專業的佇列中介軟體，在使用時是部署一個叢集，生產者在釋出訊息時，佇列中介軟體通常會寫「多個節點」，也就是有多個副本，這樣一來，即便其中一個節點掛了，也能保證叢集的資料不丟失。

2、Redis Stream 訊息可堆積嗎？

Redis 的資料都儲存在記憶體中，這就意味著一旦發生訊息積壓，則會導致 Redis 的記憶體持續增長，如果超過機器記憶體上限，就會面臨被 OOM 的風險。所以 Redis 的 Stream 提供了可以指定佇列最大長度的功能，就是為了避免這種情況發生。

但 Kafka、RabbitMQ 專業的訊息佇列它們的資料都是儲存在磁碟上，當訊息積壓時，無非就是多佔用一些磁碟空間。

因此，把 Redis 當作佇列來使用時，會面臨的 2 個問題：

• Redis 本身可能會丟資料；
• 面對訊息擠壓，記憶體資源會緊張；

所以，能不能將 Redis 作為訊息佇列來使用，關鍵看你的業務場景：

• 如果你的業務場景足夠簡單，對於資料丟失不敏感，而且訊息積壓機率比較小的情況下，把 Redis 當作佇列是完全可以的。
• 如果你的業務有海量訊息，訊息積壓的機率比較大，並且不能接受資料丟失，那麼還是用專業的訊息佇列中介軟體吧。

參考資料：

• 《Redis 核心技術與實戰》
• 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

總結

Redis 常見的五種資料型別：**String（字串），Hash（雜湊），List（列表），Set（集合）及 Zset(sorted set：有序集合)**。

這五種資料型別都由多種資料結構實現的，主要是出於時間和空間的考慮，當資料量小的時候使用更簡單的資料結構，有利於節省記憶體，提高效能。

這五種資料型別與底層資料結構對應關係圖如下，左邊是 Redis 3.0版本的，也就是《Redis 設計與實現》這本書講解的版本，現在看還是有點過時了，右邊是現在 Github 最新的 Redis 程式碼的。

可以看到，Redis 資料型別的底層資料結構隨著版本的更新也有所不同，比如：

• 在 Redis 3.0 版本中 List 物件的底層資料結構由「雙向連結串列」或「壓縮表列表」實現，但是在 3.2 版本之後，List 資料型別底層資料結構是由 quicklist 實現的；
• 在最新的 Redis 程式碼中，壓縮列表資料結構已經廢棄了，交由 listpack 資料結構來實現了。

Redis 五種資料型別的應用場景：

• String 型別的應用場景：快取物件、常規計數、分散式鎖等。
• List 型別的應用場景：訊息佇列（有兩個問題：1. 生產者需要自行實現全域性唯一 ID；2. 不能以消費組形式消費資料）等。
• Hash 型別：快取物件、購物車等。
• Set 型別：聚合計算（並集、交集、差集）場景，比如點贊、共同關注、抽獎活動等。
• Zset 型別：排序場景，比如排行榜、電話和姓名排序等。

Redis 後續版本又支援四種資料型別，它們的應用場景如下：

• BitMap（2.2 版新增）：二值狀態統計的場景，比如簽到、判斷使用者登陸狀態、連續簽到使用者總數等；
• HyperLogLog（2.8 版新增）：海量資料基數統計的場景，比如百萬級網頁 UV 計數等；
• GEO（3.2 版新增）：儲存地理位置資訊的場景，比如滴滴叫車；
• Stream（5.0 版新增）：訊息佇列，相比於基於 List 型別實現的訊息佇列，有這兩個特有的特性：自動生成全域性唯一訊息ID，支援以消費組形式消費資料。

針對 Redis 是否適合做訊息佇列，關鍵看你的業務場景：

• 如果你的業務場景足夠簡單，對於資料丟失不敏感，而且訊息積壓機率比較小的情況下，把 Redis 當作佇列是完全可以的。
• 如果你的業務有海量訊息，訊息積壓的機率比較大，並且不能接受資料丟失，那麼還是用專業的訊息佇列中介軟體吧。