把Redis當作佇列來用,你好大的膽子……

語言: CN / TW / HK

前言

經常聽到很多人討論,關於「把 Redis 當作佇列來用是否合適」的問題。

有些人表示贊成,他們認為 Redis 很輕量,用作佇列很方便。

也些人則反對,認為 Redis 會「丟」資料,最好還是用「專業」的佇列中介軟體更穩妥。

究竟哪種方案更好呢?

這篇文章,我就和你聊一聊把 Redis 當作佇列,究竟是否合適這個問題。

我會從簡單到複雜,一步步帶你梳理其中的細節,把這個問題真正的講清楚。

看完這篇文章後,我希望你對這個問題你會有全新的認識。

在文章的最後,我還會告訴你關於「技術選型」的思路,文章有點長,希望你可以耐心讀完。

一、從最簡單的開始:List 佇列

首先,我們先從最簡單的場景開始講起。

如果你的業務需求足夠簡單,想把 Redis 當作佇列來使用,肯定最先想到的就是使用 List 這個資料型別。

因為 List 底層的實現就是一個「連結串列」,在頭部和尾部操作元素,時間複雜度都是 O(1),這意味著它非常符合訊息佇列的模型。

如果把 List 當作佇列,你可以這麼來用。

生產者使用 LPUSH 釋出訊息:

127.0.0.1:6379> LPUSH queue msg1
(integer) 1
127.0.0.1:6379> LPUSH queue msg2
(integer) 2

消費者這一側,使用 RPOP 拉取訊息:

127.0.0.1:6379> RPOP queue
"msg1"
127.0.0.1:6379> RPOP queue
"msg2"

這個模型非常簡單,也很容易理解。

但這裡有個小問題,當佇列中已經沒有訊息了,消費者在執行 RPOP 時,會返回 NULL。

127.0.0.1:6379> RPOP queue
(nil) // 沒訊息了

而我們在編寫消費者邏輯時,一般是一個「死迴圈」,這個邏輯需要不斷地從佇列中拉取訊息進行處理,虛擬碼一般會這麼寫:

while true:
msg = redis.rpop("queue")
// 沒有訊息,繼續迴圈
if msg == null:
continue
// 處理訊息
handle(msg)

如果此時佇列為空,那消費者依舊會頻繁拉取訊息,這會造成「CPU 空轉」,不僅浪費 CPU 資源,還會對 Redis 造成壓力。

怎麼解決這個問題呢?

也很簡單,當佇列為空時,我們可以「休眠」一會,再去嘗試拉取訊息。程式碼可以修改成這樣:

while true:
msg = redis.rpop("queue")
// 沒有訊息,休眠2s
if msg == null:
sleep(2)
continue
// 處理訊息
handle(msg)

這就解決了 CPU 空轉問題。

這個問題雖然解決了,但又帶來另外一個問題:當消費者在休眠等待時,有新訊息來了,那消費者處理新訊息就會存在「延遲」。

假設設定的休眠時間是 2s,那新訊息最多存在 2s 的延遲。

要想縮短這個延遲,只能減小休眠的時間。但休眠時間越小,又有可能引發 CPU 空轉問題。

魚和熊掌不可兼得。

那如何做,既能及時處理新訊息,還能避免 CPU 空轉呢?

Redis 是否存在這樣一種機制:如果佇列為空,消費者在拉取訊息時就「阻塞等待」,一旦有新訊息過來,就通知我的消費者立即處理新訊息呢?

幸運的是,Redis 確實提供了「阻塞式」拉取訊息的命令:BRPOP / BLPOP,這裡的 B 指的是阻塞(Block)。

現在,你可以這樣來拉取訊息了:

while true:
// 沒訊息阻塞等待,0表示不設定超時時間
msg = redis.brpop("queue", 0)
if msg == null:
continue
// 處理訊息
handle(msg)

使用 BRPOP 這種阻塞式方式拉取訊息時,還支援傳入一個「超時時間」,如果設定為 0,則表示不設定超時,直到有新訊息才返回,否則會在指定的超時時間後返回 NULL。

這個方案不錯,既兼顧了效率,還避免了 CPU 空轉問題,一舉兩得。

注意:如果設定的超時時間太長,這個連線太久沒有活躍過,可能會被 Redis Server 判定為無效連線,之後 Redis Server 會強制把這個客戶端踢下線。所以,採用這種方案,客戶端要有重連機制。

解決了訊息處理不及時的問題,你可以再思考一下,這種佇列模型,有什麼缺點?

我們一起來分析一下:

  • 不支援重複消費: 消費者拉取訊息後,這條訊息就從 List 中刪除了,無法被其它消費者再次消費,即不支援多個消費者消費同一批資料

  • 訊息丟失: 消費者拉取到訊息後,如果發生異常宕機,那這條訊息就丟失了

第一個問題是功能上的,使用 List 做訊息佇列,它僅僅支援最簡單的,一組生產者對應一組消費者,不能滿足多組生產者和消費者的業務場景。

第二個問題就比較棘手了,因為從 List 中 POP 一條訊息出來後,這條訊息就會立即從連結串列中刪除了。也就是說,無論消費者是否處理成功,這條訊息都沒辦法再次消費了。

這也意味著,如果消費者在處理訊息時異常宕機,那這條訊息就相當於丟失了。

針對這 2 個問題怎麼解決呢?我們一個個來看。

二、釋出/訂閱模型:Pub/Sub

從名字就能看出來,這個模組是 Redis 專門是針對「釋出/訂閱」這種佇列模型設計的。

它正好可以解決前面提到的第一個問題:重複消費。

即多組生產者、消費者的場景,我們來看它是如何做的。

Redis 提供了 PUBLISH / SUBSCRIBE 命令,來完成釋出、訂閱的操作。

假設你想開啟 2 個消費者,同時消費同一批資料,就可以按照以下方式來實現。

首先,使用 SUBSCRIBE 命令,啟動 2 個消費者,並「訂閱」同一個佇列。

// 2個消費者 都訂閱一個佇列
127.0.0.1:6379> SUBSCRIBE queue
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "queue"
3) (integer) 1

此時,2 個消費者都會被阻塞住,等待新訊息的到來。

之後,再啟動一個生產者,釋出一條訊息。

127.0.0.1:6379> PUBLISH queue msg1
(integer) 1

這時,2 個消費者就會解除阻塞,收到生產者發來的新訊息。

127.0.0.1:6379> SUBSCRIBE queue
// 收到新訊息
1) "message"
2) "queue"
3) "msg1"

看到了麼,使用 Pub/Sub 這種方案,既支援阻塞式拉取訊息,還很好地滿足了多組消費者,消費同一批資料的業務需求。

除此之外,Pub/Sub 還提供了「匹配訂閱」模式,允許消費者根據一定規則,訂閱「多個」自己感興趣的佇列。

// 訂閱符合規則的佇列
127.0.0.1:6379> PSUBSCRIBE queue.*
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "queue.*"
3) (integer) 1

這裡的消費者,訂閱了 queue.* 相關的佇列訊息。

之後,生產者分別向 queue.p1 和 queue.p2 釋出訊息。

127.0.0.1:6379> PUBLISH queue.p1 msg1
(integer) 1
127.0.0.1:6379> PUBLISH queue.p2 msg2
(integer) 1

這時再看消費者,它就可以接收到這 2 個生產者的訊息了。

127.0.0.1:6379> PSUBSCRIBE queue.*
Reading messages... (press Ctrl-C to quit)
...
// 來自queue.p1的訊息
1) "pmessage"
2) "queue.*"
3) "queue.p1"
4) "msg1"
// 來自queue.p2的訊息
1) "pmessage"
2) "queue.*"
3) "queue.p2"
4) "msg2"

我們可以看到,Pub/Sub 最大的優勢就是,支援多組生產者、消費者處理訊息。

講完了它的優點,那它有什麼缺點呢?

其實,Pub/Sub 最大問題是: 丟資料

如果發生以下場景,就有可能導致資料丟失:

  • 消費者下線

  • Redis 宕機

  • 訊息堆積

究竟是怎麼回事?

這其實與 Pub/Sub 的實現方式有很大關係。

Pub/Sub 在實現時非常簡單,它沒有基於任何資料型別,也沒有做任何的資料儲存,它只是單純地為生產者、消費者建立「資料轉發通道」,把符合規則的資料,從一端轉發到另一端。

一個完整的釋出、訂閱訊息處理流程是這樣的:

  • 消費者訂閱指定佇列,Redis 就會記錄一個對映關係:佇列->消費者

  • 生產者向這個佇列釋出訊息,那 Redis 就從對映關係中找出對應的消費者,把訊息轉發給它

看到了麼,整個過程中,沒有任何的資料儲存,一切都是實時轉發的。

這種設計方案,就導致了上面提到的那些問題。

例如,如果一個消費者異常掛掉了,它再重新上線後,只能接收新的訊息,在下線期間生產者釋出的訊息,因為找不到消費者,都會被丟棄掉。

如果所有消費者都下線了,那生產者釋出的訊息,因為找不到任何一個消費者,也會全部「丟棄」。

所以,當你在使用 Pub/Sub 時,一定要注意: 消費者必須先訂閱佇列,生產者才能釋出訊息,否則訊息會丟失。

這也是前面講例子時,我們讓消費者先訂閱佇列,之後才讓生產者釋出訊息的原因。

另外,因為 Pub/Sub 沒有基於任何資料型別實現,所以它也不具備「資料持久化」的能力。

也就是說,Pub/Sub 的相關操作,不會寫入到 RDB 和 AOF 中,當 Redis 宕機重啟,Pub/Sub 的資料也會全部丟失。

最後,我們來看 Pub/Sub 在處理「訊息積壓」時,為什麼也會丟資料?

當消費者的速度,跟不上生產者時,就會導致資料積壓的情況發生。

如果採用 List 當作佇列,訊息積壓時,會導致這個連結串列很長,最直接的影響就是,Redis 記憶體會持續增長,直到消費者把所有資料都從連結串列中取出。

但 Pub/Sub 的處理方式卻不一樣,當訊息積壓時,有可能會導致 消費失敗和訊息丟失!

這是怎麼回事?

還是回到 Pub/Sub 的實現細節上來說。

每個消費者訂閱一個佇列時,Redis 都會在 Server 上給這個消費者在分配一個「緩衝區」,這個緩衝區其實就是一塊記憶體。

當生產者釋出訊息時,Redis 先把訊息寫到對應消費者的緩衝區中。

之後,消費者不斷地從緩衝區讀取訊息,處理訊息。

但是,問題就出在這個緩衝區上。

因為這個緩衝區其實是有「上限」的(可配置),如果消費者拉取訊息很慢,就會造成生產者釋出到緩衝區的訊息開始積壓,緩衝區記憶體持續增長。

如果超過了緩衝區配置的上限,此時,Redis 就會「強制」把這個消費者踢下線。

這時消費者就會消費失敗,也會丟失資料。

如果你有看過 Redis 的配置檔案,可以看到這個緩衝區的預設配置:client-output-buffer-limit pubsub 32mb 8mb 60。

它的引數含義如下:

  • 32mb:緩衝區一旦超過 32MB,Redis 直接強制把消費者踢下線

  • 8mb + 60:緩衝區超過 8MB,並且持續 60 秒,Redis 也會把消費者踢下線

Pub/Sub 的這一點特點,是與 List 作佇列差異比較大的。

從這裡你應該可以看出, List 其實是屬於「拉」模型,而 Pub/Sub 其實屬於「推」模型。

List 中的資料可以一直積壓在記憶體中,消費者什麼時候來「拉」都可以。

但 Pub/Sub 是把訊息先「推」到消費者在 Redis Server 上的緩衝區中,然後等消費者再來取。

當生產、消費速度不匹配時,就會導致緩衝區的記憶體開始膨脹,Redis 為了控制緩衝區的上限,所以就有了上面講到的,強制把消費者踢下線的機制。

好了,現在我們總結一下 Pub/Sub 的優缺點:

  • 支援釋出 / 訂閱,支援多組生產者、消費者處理訊息

  • 消費者下線,資料會丟失

  • 不支援資料持久化,Redis 宕機,資料也會丟失

  • 訊息堆積,緩衝區溢位,消費者會被強制踢下線,資料也會丟失

有沒有發現,除了第一個是優點之外,剩下的都是缺點。

所以,很多人看到 Pub/Sub 的特點後,覺得這個功能很「雞肋」。

也正是以上原因,Pub/Sub 在實際的應用場景中用得並不多。

目前只有哨兵叢集和 Redis 例項通訊時,採用了 Pub/Sub 的方案,因為哨兵正好符合即時通訊的業務場景。

我們再來看一下,Pub/Sub 有沒有解決,訊息處理時異常宕機,無法再次消費的問題呢?

其實也不行,Pub/Sub 從緩衝區取走資料之後,資料就從 Redis 緩衝區刪除了,消費者發生異常,自然也無法再次重新消費。

好,現在我們重新梳理一下,我們在使用訊息佇列時的需求。

當我們在使用一個訊息佇列時,希望它的功能如下:

  • 支援阻塞等待拉取訊息

  • 支援釋出 / 訂閱模式

  • 消費失敗,可重新消費,訊息不丟失

  • 例項宕機,訊息不丟失,資料可持久化

  • 訊息可堆積

Redis 除了 List 和 Pub/Sub 之外,還有符合這些要求的資料型別嗎?

其實,Redis 的作者也看到了以上這些問題,也一直在朝著這些方向努力著。

Redis 作者在開發 Redis 期間,還另外開發了一個開源專案 disque。

這個專案的定位,就是一個基於記憶體的分散式訊息佇列中介軟體。

但由於種種原因,這個專案一直不溫不火。

終於,在 Redis 5.0 版本,作者把 disque 功能移植到了 Redis 中,並給它定義了一個新的資料型別: Stream

下面我們就來看看,它能符合上面提到的這些要求嗎?

三、趨於成熟的佇列:Stream

我們來看 Stream 是如何解決上面這些問題的。

我們依舊從簡單到複雜,依次來看 Stream 在做訊息佇列時,是如何處理的?

首先,Stream 通過 XADD 和 XREAD 完成最簡單的生產、消費模型:

  • XADD:釋出訊息

  • XREAD:讀取訊息

生產者釋出 2 條訊息:

// *表示讓Redis自動生成訊息ID
127.0.0.1:6379> XADD queue * name zhangsan
"1618469123380-0"
127.0.0.1:6379> XADD queue * name lisi
"1618469127777-0"

使用 XADD 命令釋出訊息,其中的「*」表示讓 Redis 自動生成唯一的訊息 ID。

這個訊息 ID 的格式是「時間戳-自增序號」。

消費者拉取訊息:

// 從開頭讀取5條訊息,0-0表示從開頭讀取
127.0.0.1:6379> XREAD COUNT 5 STREAMS queue 0-0
1) 1) "queue"
2) 1) 1) "1618469123380-0"
2) 1) "name"
2) "zhangsan"
2) 1) "1618469127777-0"
2) 1) "name"
2) "lisi"

如果想繼續拉取訊息,需要傳入上一條訊息的 ID:

127.0.0.1:6379> XREAD COUNT 5 STREAMS queue 1618469127777-0
(nil)

沒有訊息,Redis 會返回 NULL。

以上就是 Stream 最簡單的生產、消費。

這裡不再重點介紹 Stream 命令的各種引數,我在例子中演示時,凡是大寫的單詞都是「固定」引數,凡是小寫的單詞,都是可以自己定義的,例如佇列名、訊息長度等等,下面的例子規則也是一樣,為了方便你理解,這裡有必要提醒一下。

下面我們來看,針對前面提到的訊息佇列要求,Stream 都是如何解決的?

1、Stream 是否支援「阻塞式」拉取訊息?

可以的,在讀取訊息時,只需要增加 BLOCK 引數即可。

// BLOCK 0 表示阻塞等待,不設定超時時間
127.0.0.1:6379> XREAD COUNT 5 BLOCK 0 STREAMS queue 1618469127777-0

這時,消費者就會阻塞等待,直到生產者釋出新的訊息才會返回。

2、Stream 是否支援釋出 / 訂閱模式?

也沒問題,Stream 通過以下命令完成釋出訂閱:

  • XGROUP:建立消費者組

  • XREADGROUP:在指定消費組下,開啟消費者拉取訊息

下面我們來看具體如何做?

首先,生產者依舊釋出 2 條訊息:

127.0.0.1:6379> XADD queue * name zhangsan
"1618470740565-0"
127.0.0.1:6379> XADD queue * name lisi
"1618470743793-0"

之後,我們想要開啟 2 組消費者處理同一批資料,就需要建立 2 個消費者組:

// 建立消費者組1,0-0表示從頭拉取訊息
127.0.0.1:6379> XGROUP CREATE queue group1 0-0
OK
// 建立消費者組2,0-0表示從頭拉取訊息
127.0.0.1:6379> XGROUP CREATE queue group2 0-0
OK

消費者組建立好之後,我們可以給每個「消費者組」下面掛一個「消費者」,讓它們分別處理同一批資料。

第一個消費組開始消費:

// group1的consumer開始消費,>表示拉取最新資料
127.0.0.1:6379> XREADGROUP GROUP group1 consumer COUNT 5 STREAMS queue >
1) 1) "queue"
2) 1) 1) "1618470740565-0"
2) 1) "name"
2) "zhangsan"
2) 1) "1618470743793-0"
2) 1) "name"
2) "lisi"

同樣地,第二個消費組開始消費:

// group2的consumer開始消費,>表示拉取最新資料
127.0.0.1:6379> XREADGROUP GROUP group2 consumer COUNT 5 STREAMS queue >
1) 1) "queue"
2) 1) 1) "1618470740565-0"
2) 1) "name"
2) "zhangsan"
2) 1) "1618470743793-0"
2) 1) "name"
2) "lisi"

我們可以看到,這 2 組消費者,都可以獲取同一批資料進行處理了。

這樣一來,就達到了多組消費者「訂閱」消費的目的。

3、訊息處理時異常,Stream 能否保證訊息不丟失,重新消費?

除了上面拉取訊息時用到了訊息 ID,這裡為了保證重新消費,也要用到這個訊息 ID。

當一組消費者處理完訊息後,需要執行 XACK 命令告知 Redis,這時 Redis 就會把這條訊息標記為「處理完成」。

// group1下的 1618472043089-0 訊息已處理完成
127.0.0.1:6379> XACK queue group1 1618472043089-0

如果消費者異常宕機,肯定不會發送 XACK,那麼 Redis 就會依舊保留這條訊息。

待這組消費者重新上線後,Redis 就會把之前沒有處理成功的資料,重新發給這個消費者。這樣一來,即使消費者異常,也不會丟失資料了。

// 消費者重新上線,0-0表示重新拉取未ACK的訊息
127.0.0.1:6379> XREADGROUP GROUP group1 consumer1 COUNT 5 STREAMS queue 0-0
// 之前沒消費成功的資料,依舊可以重新消費
1) 1) "queue"
2) 1) 1) "1618472043089-0"
2) 1) "name"
2) "zhangsan"
2) 1) "1618472045158-0"
2) 1) "name"
2) "lisi"

4、Stream 資料會寫入到 RDB 和 AOF 做持久化嗎?

Stream 是新增加的資料型別,它與其它資料型別一樣,每個寫操作,也都會寫入到 RDB 和 AOF 中。

我們只需要配置好持久化策略,這樣的話,就算 Redis 宕機重啟,Stream 中的資料也可以從 RDB 或 AOF 中恢復回來。

5、訊息堆積時,Stream 是怎麼處理的?

其實,當訊息佇列發生訊息堆積時,一般只有 2 個解決方案:

  • 生產者限流:避免消費者處理不及時,導致持續積壓

  • 丟棄訊息:中介軟體丟棄舊訊息,只保留固定長度的新訊息

而 Redis 在實現 Stream 時,採用了第 2 個方案。

在釋出訊息時,你可以指定佇列的最大長度,防止佇列積壓導致記憶體爆炸。

// 佇列長度最大10000
127.0.0.1:6379> XADD queue MAXLEN 10000 * name zhangsan
"1618473015018-0"

當佇列長度超過上限後,舊訊息會被刪除,只保留固定長度的新訊息。

這麼來看,Stream 在訊息積壓時,如果指定了最大長度,還是有可能丟失訊息的。

除了以上介紹到的命令,Stream 還支援檢視訊息長度(XLEN)、檢視消費者狀態(XINFO)等命令,使用也比較簡單,你可以查詢官方文件瞭解一下,這裡就不過多介紹了。

好了,通過以上介紹,我們可以看到,Redis 的 Stream 幾乎覆蓋到了訊息佇列的各種場景,是不是覺得很完美?

既然它的功能這麼強大,這是不是意味著,Redis 真的可以作為專業的訊息佇列中介軟體來使用呢?

但是還「差一點」,就算 Redis 能做到以上這些,也只是「趨近於」專業的訊息佇列。

原因在於 Redis 本身的一些問題,如果把其定位成訊息佇列,還是有些欠缺的。

到這裡,就不得不把 Redis 與專業的佇列中介軟體做對比了。

下面我們就來看一下,Redis 在作佇列時,到底還有哪些欠缺?

四、與專業的訊息佇列對比

其實,一個專業的訊息佇列,必須要做到兩大塊:

  • 訊息不丟

  • 訊息可堆積

前面我們討論的重點,很大篇幅圍繞的是第一點展開的。

這裡我們換個角度,從一個訊息佇列的「使用模型」來分析一下,怎麼做,才能保證資料不丟?

使用一個訊息佇列,其實就分為三大塊: 生產者、佇列中介軟體、消費者。

訊息是否會發生丟失,其重點也就在於以下 3 個環節:

  • 生產者會不會丟訊息?

  • 消費者會不會丟訊息?

  • 佇列中介軟體會不會丟訊息?

1、生產者會不會丟訊息?

當生產者在釋出訊息時,可能發生以下異常情況:

  • 訊息沒發出去:網路故障或其它問題導致釋出失敗,中介軟體直接返回失敗

  • 不確定是否釋出成功:網路問題導致釋出超時,可能資料已傳送成功,但讀取響應結果超時了

如果是情況 1,訊息根本沒發出去,那麼重新發一次就好了。

如果是情況 2,生產者沒辦法知道訊息到底有沒有發成功?所以,為了避免訊息丟失,它也只能繼續重試,直到釋出成功為止。

生產者一般會設定一個最大重試次數,超過上限依舊失敗,需要記錄日誌報警處理。

也就是說,生產者為了避免訊息丟失,只能採用失敗重試的方式來處理。

但發現沒有?這也意味著訊息可能會重複傳送。

是的,在使用訊息佇列時,要保證訊息不丟,寧可重發,也不能丟棄。

那消費者這邊,就需要多做一些邏輯了。

對於敏感業務,當消費者收到重複資料資料時,要設計冪等邏輯,保證業務的正確性。

從這個角度來看,生產者會不會丟訊息,取決於生產者對於異常情況的處理是否合理。

所以,無論是 Redis 還是專業的佇列中介軟體,生產者在這一點上都是可以保證訊息不丟的。

2、消費者會不會丟訊息?

這種情況就是我們前面提到的,消費者拿到訊息後,還沒處理完成,就異常宕機了,那消費者還能否重新消費失敗的訊息?

要解決這個問題,消費者在處理完訊息後,必須「告知」佇列中介軟體,佇列中介軟體才會把標記已處理,否則仍舊把這些資料發給消費者。

這種方案需要消費者和中介軟體互相配合,才能保證消費者這一側的訊息不丟。

無論是 Redis 的 Stream,還是專業的佇列中介軟體,例如 RabbitMQ、Kafka,其實都是這麼做的。

所以,從這個角度來看,Redis 也是合格的。

3、佇列中介軟體會不會丟訊息?

前面 2 個問題都比較好處理,只要客戶端和服務端配合好,就能保證生產端、消費端都不丟訊息。

但是,如果佇列中介軟體本身就不可靠呢?

畢竟生產者和消費這都依賴它,如果它不可靠,那麼生產者和消費者無論怎麼做,都無法保證資料不丟。

在這個方面,Redis 其實沒有達到要求。

Redis 在以下 2 個場景下,都會導致資料丟失。

  • AOF 持久化配置為每秒寫盤,但這個寫盤過程是非同步的,Redis 宕機時會存在資料丟失的可能

  • 主從複製也是非同步的,主從切換時,也存在丟失資料的可能(從庫還未同步完成主庫發來的資料,就被提成主庫)

基於以上原因我們可以看到, Redis 本身的無法保證嚴格的資料完整性。

所以,如果把 Redis 當做訊息佇列,在這方面是有可能導致資料丟失的。

再來看那些專業的訊息佇列中介軟體是如何解決這個問題的?

像 RabbitMQ 或 Kafka 這類專業的佇列中介軟體,在使用時,一般是部署一個叢集,生產者在釋出訊息時,佇列中介軟體通常會寫「多個節點」,以此保證訊息的完整性。這樣一來,即便其中一個節點掛了,也能保證叢集的資料不丟失。

也正因為如此,RabbitMQ、Kafka在設計時也更復雜。畢竟,它們是專門針對佇列場景設計的。

但 Redis 的定位則不同,它的定位更多是當作快取來用,它們兩者在這個方面肯定是存在差異的。

最後,我們來看訊息積壓怎麼辦?

4、訊息積壓怎麼辦?

因為 Redis 的資料都儲存在記憶體中,這就意味著一旦發生訊息積壓,則會導致 Redis 的記憶體持續增長,如果超過機器記憶體上限,就會面臨被 OOM 的風險。

所以,Redis 的 Stream 提供了可以指定佇列最大長度的功能,就是為了避免這種情況發生。

但 Kafka、RabbitMQ 這類訊息佇列就不一樣了,它們的資料都會儲存在磁碟上,磁碟的成本要比記憶體小得多,當訊息積壓時,無非就是多佔用一些磁碟空間,相比於記憶體,在面對積壓時也會更加「坦然」。

綜上,我們可以看到,把 Redis 當作佇列來使用時,始終面臨的 2 個問題:

  • Redis 本身可能會丟資料

  • 面對訊息積壓,Redis 記憶體資源緊張

到這裡,Redis 是否可以用作佇列,我想這個答案你應該會比較清晰了。

如果你的業務場景足夠簡單,對於資料丟失不敏感,而且訊息積壓概率比較小的情況下,把 Redis 當作佇列是完全可以的。

而且,Redis 相比於 Kafka、RabbitMQ,部署和運維也更加輕量。

如果你的業務場景對於資料丟失非常敏感,而且寫入量非常大,訊息積壓時會佔用很多的機器資源,那麼我建議你使用專業的訊息佇列中介軟體。

五、總結

好了,總結一下。這篇文章我們從「Redis 能否用作佇列」這個角度出發,介紹了 List、Pub/Sub、Stream 在做佇列的使用方式,以及它們各自的優劣。

之後又把 Redis 和專業的訊息佇列中介軟體做對比,發現 Redis 的不足之處。

最後,我們得出 Redis 做佇列的合適場景。

這裡我也列了一個表格,總結了它們各自的優缺點。

後記

最後,我想和你再聊一聊關於 「技術方案選型」 的問題。

你應該也看到了,這篇文章雖然始於 Redis,但並不止於 Redis。

我們在分析 Redis 細節時,一直在提出問題,然後尋找更好的解決方案,在文章最後,又聊到一個專業的訊息佇列應該怎麼做。

其實,我們在討論技術選型時,就是一個關於如何取捨的問題。

而這裡我想傳達給你的資訊是, 在面對技術選型時,不要不經過思考就覺得哪個方案好,哪個方案不好

你需要根據具體場景具體分析,這裡我把這個分析過程分為 2 個層面:

  • 業務功能角度

  • 技術資源角度

這篇文章所講到的內容,都是以業務功能角度出發做決策的。

但這裡的第二點,從技術資源角度出發,其實也很重要。

技術資源的角度是說, 你所處的公司環境、技術資源能否匹配這些技術方案。

這個怎麼解釋呢?

簡單來講,就是你所在的公司、團隊,是否有匹配的資源能 hold 住這些技術方案。

我們都知道 Kafka、RabbitMQ 是非常專業的訊息中介軟體,但它們的部署和運維,相比於 Redis 來說,也會更復雜一些。

如果你在一個大公司,公司本身就有優秀的運維團隊,那麼使用這些中介軟體肯定沒問題,因為有足夠優秀的人能 hold 住這些中介軟體,公司也會投入人力和時間在這個方向上。

但如果你是在一個初創公司,業務正處在快速發展期,暫時沒有能 hold 住這些中介軟體的團隊和人,如果貿然使用這些元件,當發生故障時,排查問題也會變得很困難,甚至會阻礙業務的發展。

而這種情形下,如果公司的技術人員對於 Redis 都很熟,綜合評估來看,Redis 也基本可以滿足業務 90% 的需求,那當下選擇 Redis 未必不是一個好的決策。

所以, 做技術選型不只是技術問題,還與人、團隊、管理、組織結構有關。

也正是因為這些原因,當你在和別人討論技術選型問題時,你會發現每個公司的做法都不相同。

畢竟每個公司所處的環境和文化不一樣,做出的決策當然就會各有差異。

如果你不瞭解這其中的邏輯,那在做技術選型時,只會趨於表面現象,無法深入到問題根源。

而一旦你理解了這個邏輯,那麼你在看待這個問題時,不僅對於技術會有更加深刻認識,對技術資源和人的把握,也會更加清晰。

希望你以後在做技術選型時,能夠把這些因素也考慮在內,這對你的技術成長之路也是非常有幫助的。

作者丨Magic Kaito

來源丨公眾號:水滴與銀彈(ID:waterdrop_bullet)

dbaplus社群歡迎廣大技術人員投稿,投稿郵箱: [email protected]