Redis 怎麼做訊息佇列？

1樓：網易數帆

PUB/SUB 實現輕量的訊息佇列機制也算是種 Redis典型應場景吧。 Redis作為個 Key/Value 儲存具，它提供的很多特性可以來實現些級應功能。如 PUBLISH 和 SUBSCRIBE 這兩個命令，可以來快速解決訊息佇列應場景的問題。

簡單的講：

SUBSCRIBE 於監聽個頻道（channel）

PUBLISH 則允許戶推送條訊息（可以是任何 Redis 持的資料結構）到某個頻道

以這兩個命令為基礎，可以很便的構建個訊息佇列應。不過也只適合在業務需求較為簡單的場合替代專業訊息佇列。敏捷的完成開發需求並減少部署複雜度這個沒問題，但是期從合理性的度出發還是要選擇更可靠專業的訊息佇列。

利益相關：易輕中介軟體，基於 Kubernetes Operator 構建，提供資料庫、快取、訊息等專業中介軟體服務。

2樓：王明明

從題主描述來看，題主對訊息佇列的場景還不是很熟悉，在資料量可控的場景下，這套方案有一定的可行性，可以嘗試實現，同時摸索資料一致性，消費者確認機制，訊息冪等性等特點，從而對比其它型別的訊息型元件不同，比如RabitMQ Kafka,為自己設定乙個學習路徑和目標。

以Redis來談訊息佇列

圖南日晟-網際網路技術服務

3樓：大橋上的夜晚

可先將物件序列化成JSON字串，再通過lpush和brpop該JSON串，實現訊息佇列的功能。

另外，熱點資料適合存在redis中，且redis中也能使用事務機制；其他資料就入mysql庫好了。

4樓：等待戈多的秋天

按題主的想法，實際上只是想實現乙個非同步寫資料庫操作，使用佇列來實現快取功能。眾所周知，mysql的寫入相對而言是較為低速。作為乙個簡單架構來說，這個思路是對的。

按題主的思路，是使用redis的lpush和lpop，有3個不足：

1.如果寫入過快，而讀出太慢，資料會堆積在redis中，而佇列實際上即使在redis cluster中，也會在單機上，擴充套件性差

2.一旦出隊，則資料會銷毀，不利於下游擴充套件。打個比方，如果還有另外乙個應用方，需要這些資料，則只能從mysql中獲取了。

3.消費方定時輪詢讀取資料，不夠優雅

所以，如果題主能接受這些不足，則使用redis做佇列是可以的

5樓：eechen

RPOPLPUSH - Redis

模式:可靠的佇列(reliable queue)

Redis的列表(list)經常被用作佇列(queue),用於在不同程式之間有序地交換訊息(message).乙個客戶端通過LPUSH命令將訊息放入佇列中,而另乙個客戶端通過RPOP或者BRPOP命令取出佇列中等待時間最長的訊息.不幸的是,上面的佇列方法是不可靠的.

因為在這個過程中,乙個客戶端可能在取出乙個訊息之後崩潰,而未處理完的訊息也就因此丟失.

上述做法需要注意的問題:

RPOPLPUSH重新入隊,即把備份列表右側元素(表尾)重新入隊,可能會出現訊息被重複消費的情況.

因此消費操作要實現冪等性,即保證重複消費結果一致.

舉例說明:

資料列表(source): c,b,a

2個客戶端先後RPOPLPUSH消費並備份了2個元素:a和b

客戶端1: RPOPLPUSH source backup (返回a並備份到backup)

客戶端2: RPOPLPUSH source backup (返回b並備份到backup)

備份列表(backup): b,a

客戶端1: LREM backup -1 a (移除備份列表backup中,從表尾到表頭,第乙個a,其中-1表示從表尾開始)

客戶端2: LREM backup -1 b (移除備份列表backup中,從表尾到表頭,第乙個b,其中-1表示從表尾開始)

最後,Redis AOF持久化有幾個配置:

效能與安全,自行權衡.

6樓：

訊息佇列不僅僅做個非同步的資料通道就夠了，需要處理訊息持久化，consumer的擴充套件性，訊息處理狀態確認與重放。如果啥都不講究的話，和你在記憶體中維護乙個陣列來快取訊息沒什麼兩樣，僅僅用空間換取了時間上的效能提公升。成熟的訊息佇列市面上方案越來越多，非要用redis的話，5.

0了解一下。

7樓：

可以用redis的list，生產lpush，消費出隊brpop阻塞，但如果出隊後消費端crash沒處理就丟資料，要安全可以用rpoplush source 目標，這樣這個list鍊錶尾部沒了而且原子返回給消費端，但會備份放進另乙個list，處理完刪。然而一般有kafka之類的為什麼要用redis做mq，redis會變成兼顧快取和訊息佇列，而且量大有風險。

8樓：王集鵠

上個老東家就是靠 Redis 佇列，撐起了上百萬的日活。

一邊 lpush() 另一邊 rpop()。

佇列的好處就是兩邊都可以做分布式，方便擴容。

當然也依賴運維做 Redis 的持久化和分布式配置、異常監控。

據說他們現在在轉 Kafka。

所以日活百萬以下，放心用吧。日後公升級為 Kafka 改造成本也不高。

9樓：fleuria

redis 做訊息佇列不合適，像 kafka 這種訊息佇列的主要場景是跨業務同步訊息，有一定的保序、at-least-once 之類的 guarantee 要求。

不過 redis 做 beanstalkd 這樣的任務佇列是 production ready 而且 battle tested 的，期望通過任務佇列做到在業務內快速擴非同步任務 worker，加上 buried 失敗任務登記允許重試，一定的容量能夠緩衝非同步 worker 故障出現的任務積壓。

這時需要注意的是，業務上避免過度復用乙個 redis。既用它做快取、做計算，還拿它做任務佇列，這樣不好。

10樓：大寬寬

redis當然可以封裝成佇列。但如果這樣講，檔案也可以做佇列（kafka就是這麼幹的）；資料庫也可以做佇列；管道也可以做佇列；ZeroMQ也可以做佇列……

我感覺題主的需求描述的比較模糊。

這個佇列到底是不是生產用；如果是，要不要保證一致性。（比如使用者秒殺下單）。如果是的話，光用redis是遠遠不夠的，你必須花大力氣做一致性補償和非同步冪等的工作，保證能實現exactly once語義。

如果這樣的話，就不如用乙個正經的MQ來做更實際。RabbitMQ，nsq，kafka等都可以。

如果是生產用，但是可以容忍丟東西（比如log收集），那麼也有現成的方案，fluentd，logstash……

實際上redis並不適合任何有保障資料永續性的場景。它適合做cache，不重要的儲存，或者是可以反覆重來的批處理計算任務的臨時儲存等。

當然，如果是自己玩，那麼可以隨意寫。但記得和已有的佇列系統的設計和實現做比較，了解乙個真正的佇列系統為什麼那麼複雜。相信會有不少收穫。

2023年3月19日更新

有知友表示不理解「真正的佇列「的含義，所以在這篇文章中闡述了一下觀點：你對Redis的使用靠譜嗎？

11樓：GoldRose

redis比較簡單作為訊息佇列的，list，列表，不停寫入，另外別的執行緒去取，或者全取，然後入庫，就看redis集群自身的穩定性。

12樓：find goo

redis做訊息佇列，一旦有業務爆發，記憶體不夠直接掛掉，對伺服器記憶體要求多。建議用ssdb，和redis相容，解決Redis容量有限問題。

13樓：非專業諮詢

選乙個基於redis的MQ吧，開源又好用的不少。

像@李波的回答一樣，寫進來的時候直接寫到redis讀也交給redis。

至於資料同步到mysql計畫個時間和方案再批量同步吧。

至於redis的可靠性就是其他問題了…

14樓：

Reference [2.3]

什麼類的資料？

要求不是很高的話可以用logstash

目前官方沒有mysql的output plugins輸入源 redis支援lpush和lpop和、pub/sub模式，改改配置檔案就行了，不用redis，用nsq、 kafka之類也有對應的外掛程式

輸出外掛程式看官方文件，支援mongodb和elasticsearch

15樓：孫聖翔

是的LPUSH RPOP就可以了。圖省事的話，還可以用封裝好的 python庫 HotQueue — HotQueue 0.2.7 documentation

16樓：

之前嘗試過用redis作pub/sub 但是由於資料有可靠性需求，所以最終使用了beanstalkd作為redis的替代品，除了更加多樣的控制訊息的生命週期以外，還可以在不可靠的環境下，可以保證丟失訊息的backup找回

17樓：李會軍

redis本身就支援pub/sub模式，可以作為訊息佇列處理，參見 Command reference

按題主的場景，需要配置redis的持久化儲存，否則可能會出現資料沒有儲存到mysql中的情形。

18樓：davidnkcao

如果系統量不大，redis的list push,pop足夠了，如果量大盡量用成熟一些的MQ，不過會重一些，具體要看場景。

19樓：keozhang

僅僅是兩台伺服器，那麼redis的Pub/Sub或者是List都能滿足需求，而且實現非常簡單。

pub/sub的壞處就是sub端收不到訂閱前發布的訊息。

Redis 怎麼做訊息佇列？

redis使用訊息佇列的場合？

Redis集群方案應該怎麼做？

怎麼做才能脫單，怎麼做啊？

其他用戶還看了：