Redis九種數(shù)據(jù)類型和應(yīng)用場景

原文標(biāo)題：2 萬字  + 20張圖｜ 細(xì)說 Redis 九種數(shù)據(jù)類型和應(yīng)用場景

我們都知道 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)用場景嗎？

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

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

1、String

介紹

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

 

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

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

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

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

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

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

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

如果字符串對象保存的是一個(gè)字符串，并且這個(gè)字符串的長度大于 32 字節(jié)，那么字符串對象將使用一個(gè)簡單動態(tài)字符串（SDS）來保存這個(gè)字符串，并將對象的編碼設(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ù)；因?yàn)?code>embstr編碼的字符串對象的所有數(shù)據(jù)都保存在一塊連續(xù)的內(nèi)存里面可以更好的利用 CPU 緩存提升性能。

但是 embstr 也有缺點(diǎn)的：

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

常用指令

普通字符串的基本操作：

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

批量設(shè)置 :

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

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

# 設(shè)置 key-value 類型的值
> SET number 0
OK
# 將 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è)置過期時(shí)間）
> EXPIRE name  60 
(integer) 1
# 查看數(shù)據(jù)還有多久過期
> TTL name 
(integer) 51

#設(shè)置 key-value 類型的值，并設(shè)置該key的過期時(shí)間為 60 秒
> SET key  value EX 60
OK
> SETEX key  60 value
OK

不存在就插入：

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

 

應(yīng)用場景

緩存對象

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

• 直接緩存整個(gè)對象的 JSON，命令例子：SET user:1 '{"name":"xiaolin", "age":18}'。采用將 key 進(jìn)行分離為 user:ID:屬性，采用 MSET 存儲，用 MGET 獲取各屬性值，命令例子：MSET user:1:name xiaolin user:1:age 18 user:2:name xiaomei user:2:age 20。

 

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

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

比如計(jì)算文章的閱讀量：

# 初始化文章的閱讀量
> 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
# 獲取對應(yīng)文章的閱讀量
> GET aritcle:readcount:1001
"3"

分布式鎖

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

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

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

SET lock_key unique_value NX PX 10000

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

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

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

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

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

2、List

介紹

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

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

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

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

• 如果列表的元素個(gè)數(shù)小于 512 個(gè)（默認(rèn)值，可由 list-max-ziplist-entries 配置），列表每個(gè)元素的值都小于 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 實(shí)現(xiàn)了，替代了雙向鏈表和壓縮列表。

常用命令

# 將一個(gè)或多個(gè)值value插入到key列表的表頭(最左邊)，最后的值在最前面
LPUSH key value [value ...] 
# 將一個(gè)或多個(gè)值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列表表頭彈出一個(gè)元素，沒有就阻塞timeout秒，如果timeout=0則一直阻塞
BLPOP key [key ...] timeout
# 從key列表表尾彈出一個(gè)元素，沒有就阻塞timeout秒，如果timeout=0則一直阻塞
BRPOP key [key ...] timeout

 

應(yīng)用場景

消息隊(duì)列

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

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

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

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

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

生產(chǎn)者使用 LPUSH key value[value...] 將消息插入到隊(duì)列的頭部，如果 key 不存在則會創(chuàng)建一個(gè)空的隊(duì)列再插入消息。

消費(fèi)者使用 RPOP key 依次讀取隊(duì)列的消息，先進(jìn)先出。

不過，在消費(fèi)者讀取數(shù)據(jù)時(shí)，有一個(gè)潛在的性能風(fēng)險(xiǎn)點(diǎn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3、Hash

介紹

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

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

 

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

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

• 如果哈希類型元素個(gè)數(shù)小于 512 個(gè)（默認(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)來實(shí)現(xiàn)了。

常用命令

# 存儲一個(gè)哈希表key的鍵值
HSET key field value   
# 獲取哈希表key對應(yīng)的field鍵值
HGET key field

# 在一個(gè)哈希表key中存儲多個(gè)鍵值對
HMSET key field value [field value...] 
# 批量獲取哈希表key中多個(gè)field鍵值
HMGET key field [field ...]       
# 刪除哈希表key中的field鍵值
HDEL key field [field ...]    

# 返回哈希表key中field的數(shù)量
HLEN key       
# 返回哈希表key中所有的鍵值
HGETALL key 

# 為哈希表key中field鍵的值加上增量n
HINCRBY key field n                         

 

應(yīng)用場景

緩存對象

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

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

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

# 存儲一個(gè)哈希表uid:1的鍵值
> HSET uid:1 name Tom age 15
2
# 存儲一個(gè)哈希表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 存儲其結(jié)構(gòu)如下圖：

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

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

購物車

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

涉及的命令如下：

• 添加商品：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 中，在回顯商品具體信息的時(shí)候，還需要拿著商品 id 查詢一次數(shù)據(jù)庫，獲取完整的商品的信息。

4、Set

介紹

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

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

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

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

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

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

• 如果集合中的元素都是整數(shù)且元素個(gè)數(shù)小于 512 （默認(rèn)值，set-maxintset-entries配置）個(gè)，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中的元素個(gè)數(shù)
SCARD key

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

# 從集合key中隨機(jī)選出count個(gè)元素，元素不從key中刪除
SRANDMEMBER key [count]
# 從集合key中隨機(jī)選出count個(gè)元素，元素從key中刪除
SPOP key [count]

Set運(yùn)算操作：

# 交集運(yùn)算
SINTER key [key ...]
# 將交集結(jié)果存入新集合destination中
SINTERSTORE destination key [key ...]

# 并集運(yùn)算
SUNION key [key ...]
# 將并集結(jié)果存入新集合destination中
SUNIONSTORE destination key [key ...]

# 差集運(yùn)算
SDIFF key [key ...]
# 將差集結(jié)果存入新集合destination中
SDIFFSTORE destination key [key ...]

 

應(yīng)用場景

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

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

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

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

點(diǎn)贊

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

uid:1 、uid:2、uid:3   三個(gè)用戶分別對 article:1 文章點(diǎn)贊了。

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

uid:1 取消了對 article:1 文章點(diǎn)贊。

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

獲取  article:1 文章所有點(diǎn)贊用戶 :

> SMEMBERS article:1
1) "uid:3"
2) "uid:2"

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

> SCARD article:1
(integer) 2

判斷用戶 uid:1 是否對文章 article:1 點(diǎn)贊了：

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

 

共同關(guān)注

Set 類型支持交集運(yùn)算，所以可以用來計(jì)算共同關(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:2
1) "7"
2) "8"
3) "9"

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

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

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

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

 

抽獎(jiǎng)活動

存儲某活動中中獎(jiǎng)的用戶名 ，Set 類型因?yàn)橛腥ブ毓δ?，可以保證同一個(gè)用戶不會中獎(jiǎng)兩次。

key為抽獎(jiǎng)活動名，value為員工名稱，把所有員工名稱放入抽獎(jiǎng)箱 ：

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

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

# 抽取 1 個(gè)一等獎(jiǎng)：
> SRANDMEMBER lucky 1
1) "Tom"
# 抽取 2 個(gè)二等獎(jiǎng)：
> SRANDMEMBER lucky 2
1) "Mark"
2) "Jerry"
# 抽取 3 個(gè)三等獎(jiǎng)：
> SRANDMEMBER lucky 3
1) "Sary"
2) "Tom"
3) "Jerry"

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

# 抽取一等獎(jiǎng)1個(gè)
> SPOP lucky 1
1) "Sary"
# 抽取二等獎(jiǎng)2個(gè)
> SPOP lucky 2
1) "Jerry"
2) "Mark"
# 抽取三等獎(jiǎng)3個(gè)
> SPOP lucky 3
1) "John"
2) "Sean"
3) "Lindy"

5、Zset

介紹

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

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

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

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

• 如果有序集合的元素個(gè)數(shù)小于 128 個(gè)，并且每個(gè)元素的值小于 64 字節(jié)時(shí)，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)來實(shí)現(xiàn)了。

常用命令

Zset 常用操作：

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

# 為有序集合key中元素member的分值加上increment
ZINCRBY 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 運(yùn)算操作（相比于 Set 類型，ZSet 類型沒有支持差集運(yùn)算）：

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

 

應(yīng)用場景

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

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

排行榜

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

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

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

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

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

查看某篇文章的贊數(shù)，可以使用 ZSCORE 命令（返回有序集合key中元素個(gè)數(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 WITHSCORES
1) "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 WITHSCORES
1) "arcticle:3"
2) "100"
3) "arcticle:5"
4) "150"
5) "arcticle:1"
6) "200"

 

電話、姓名排序

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

注意：不要在分?jǐn)?shù)不一致的 SortSet 集合中去使用 ZRANGEBYLEX和 ZREVRANGEBYLEX 指令，因?yàn)楂@取的結(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 (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"

 

6、BitMap

介紹

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

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

 

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

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

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

常用命令

bitmap 基本操作：

# 設(shè)置值，其中value只能是 0 和 1
SETBIT key offset value

# 獲取值
GETBIT key offset

# 獲取指定范圍內(nèi)值為 1 的個(gè)數(shù)
# start 和 end 以字節(jié)為單位
BITCOUNT key start end

bitmap 運(yùn)算操作：

# BitMap間的運(yùn)算
# operations 位移操作符，枚舉值
  AND 與運(yùn)算 &
  OR 或運(yùn)算 |
  XOR 異或 ^
  NOT 取反 ~
# result 計(jì)算的結(jié)果，會存儲在該key中
# key1 … keyn 參與運(yùn)算的key，可以有多個(gè)，空格分割，not運(yùn)算只能一個(gè)key
# 當(dāng) BITOP 處理不同長度的字符串時(shí)，較短的那個(gè)字符串所缺少的部分會被看作 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)計(jì)的場景，這里的二值狀態(tài)就是指集合元素的取值就只有 0 和 1 兩種，在記錄海量數(shù)據(jù)時(shí)，Bitmap 能夠有效地節(jié)省內(nèi)存空間。

簽到統(tǒng)計(jì)

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

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

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

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

SETBIT uid:sign:100:202206 2 1

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

GETBIT uid:sign:100:202206 2 

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

BITCOUNT uid:sign:100:202206

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

如何統(tǒng)計(jì)這個(gè)月首次打卡時(shí)間呢？

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

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

BITPOS uid:sign:100:202206 1

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

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

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

只需要一個(gè) 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)計(jì)出這連續(xù) 7 天連續(xù)打卡用戶總數(shù)呢？

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

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

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

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

Redis 提供了 BITOP operation destkey key [key ...]這個(gè)指令用于對一個(gè)或者多個(gè) key 的 Bitmap 進(jìn)行位元操作。

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

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

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

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

7、HyperLogLog

介紹

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

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

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

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

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

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

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

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

常見命令

HyperLogLog 命令很少，就三個(gè)。

# 添加指定元素到 HyperLogLog 中
PFADD key element [element ...]

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

# 將多個(gè) HyperLogLog 合并為一個(gè) HyperLogLog
PFMERGE destkey sourcekey [sourcekey ...]

 

應(yīng)用場景

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

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

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

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

PFADD page1:uv user1 user2 user3 user4 user5

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

PFCOUNT page1:uv

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

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

8、GEO

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

在日常生活中，我們越來越依賴搜索“附近的餐館”、在打車軟件上叫車，這些都離不開基于位置信息服務(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)部實(shí)現(xiàn)

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

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

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

常用命令

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

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

# 返回兩個(gè)給定位置之間的距離。
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 這兩個(gè)命令。

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

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

GEOADD cars:locations 116.034579 39.030452 33

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

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

GEORADIUS cars:locations 116.054579 39.030452 5 km ASC COUNT 10

 

9、Stream

介紹

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

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

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

常見命令

Stream 消息隊(duì)列操作命令：

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

 

應(yīng)用場景

消息隊(duì)列

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> XREADGROUP group group1 consumer1 Stream mymq >
(nil)

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

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

# 讓 group2 中的 consumer1 從 mymq 消息隊(duì)列中消費(fèi)一條消息
> XREADGROUP group group2 consumer1 count 1 Stream mymq >
1) 1) "mymq"
   2) 1) 1) "1654254953808-0"
         2) 1) "name"
            2) "xiaolin"
# 讓 group2 中的 consumer2 從 mymq 消息隊(duì)列中消費(fèi)一條消息
> XREADGROUP group group2 consumer2 count 1 Stream mymq >
1) 1) "mymq"
   2) 1) 1) "1654256265584-0"
         2) 1) "name"
            2) "xiaolincoding"
# 讓 group2 中的 consumer3 從 mymq 消息隊(duì)列中消費(fèi)一條消息
> XREADGROUP group group2 consumer3 count 1 Stream mymq >
1) 1) "mymq"
   2) 1) 1) "1654256271337-0"
         2) 1) "name"
            2) "Tom"

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

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

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

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

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

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

# 查看 group2 里 consumer2 已從 mymq 消息隊(duì)列中讀取了哪些消息
> 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

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

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

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

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

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

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

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

1、Redis Stream 消息會丟失嗎？

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

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

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

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

2、Redis Stream 消息可堆積嗎？

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

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

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

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

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

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

參考資料：

• 《Redis 核心技術(shù)與實(shí)戰(zhàn)》https://www.cnblogs.com/hunternet/p/12742390.htmlhttps://www.cnblogs.com/qdhxhz/p/15669348.htmlhttps://www.cnblogs.com/bbgs-xc/p/14376109.htmlhttp://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)實(shí)現(xiàn)的，主要是出于時(shí)間和空間的考慮，當(dāng)數(shù)據(jù)量小的時(shí)候使用更簡單的數(shù)據(jù)結(jié)構(gòu)，有利于節(jié)省內(nèi)存，提高性能。

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

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

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

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

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

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

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

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

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