消息隊列(Message Queue)，字面意思就是存放消息的隊列。最簡單的消息隊列模型包括3個角色：

消息隊列：存儲消息。

生產者：發送消息到消息隊列，在秒殺任務中負責判斷秒殺時間和庫存，校驗消費者權限是否是一人一單，發送優惠券id和用戶id到消息隊列中。

消費者：從消息隊列獲取消息并處理消息，接受到訂單消息之后，完成下單。

Redis提供了三種不同的方式來實現消息隊列：

list結構：基于List結構模擬消息隊列。

PubSub：基本的點對點消息模型。

Stream：比較完善的消息隊列模型。

基于List結構模擬消息隊列

消息隊列(Message Queue)，字面意思就是存放消息的隊列。而Redis的list數據結構是一個雙向鏈表，很容易模擬出隊列效果。

隊列是入口和出口不在一邊，因此我們可以利用：LPUSH 結合 RPOP、或者 RPUSH 結合 LPOP來實現。

不過要注意的是，當隊列中沒有消息時RPOP或LPOP操作會返回null，并不像JVM的阻塞隊列那樣會阻塞并等待消息。因此這里應該使用BRPOP或者BLOPO來實現阻塞效果。

List的消息隊列可利用Redis存儲，不受限于JVM內存上限，是基于基于Redis的持久化機制，數據安全性有保證，同時也可以滿足消息隊列的有序性。但只支持但消費者，無法避免消息丟失是它最大的問題。

基于PubSub的消息隊列

PubSub(發布訂閱)是Redis2.0版本引入的消息傳遞模型。顧名思義，消費者可以訂閱一個或多個channel，生產者向對應channel發送消息后，所有訂閱者都能收到相關消息。對應channel發送消息后，所有訂閱者都能收到相關消息。

SUBSCRIBE channel [channel] ：訂閱一個或多個頻道。

PUBLISH channel msg ：向一個頻道發送消息。

PSUBSCRIBE pattern[pattern] ：訂閱與pattern格式匹配的所有頻道。

基于PubSub的消息隊列采用發布訂閱模型，支持多生產、多消費，但也有不支持數據持久化、無法避免消息丟失，消息堆積有上限的缺點，超出時數據會丟失。

例如：

基于Stream的消息隊列-XREAD

Stream讀取消息的方式之一：XREAD

例如：

創建消費者組：

XGROUP CREATE  key groupName ID [MKSTREAM]

key：隊列名稱

groupName：消費者組名稱

ID：起始ID標示，$代表隊列中最后一個消息，0則代表隊列中第一個消息

MKSTREAM：隊列不存在時自動創建隊列。

其它常見命令：

# 刪除指定的消費者組
XGROUP DESTORY key groupName

# 給指定的消費者組添加消費者
XGROUP CREATECONSUMER key groupname consumername

# 刪除消費者組中的指定消費者
XGROUP DELCONSUMER key groupname consumername

從消費者組讀取消息：

XREADGROUP GROUP group consumer [COUNT count] [BLOCK milliseconds] [NOACK] STREAMS key [key ...] ID [ID ...]

group：消費組名稱

consumer：消費者名稱，如果消費者不存在，會自動創建一個消費者

count：本次查詢的最大數量

BLOCK milliseconds：當沒有消息時最長等待時間

NOACK：無需手動ACK，獲取到消息后自動確認

STREAMS key：指定隊列名稱

ID：獲取消息的起始ID：">"：從下一個未消費的消息開始

其它：根據指定id從pending-list中獲取已消費但未確認的消息，例如0，是從pending-list中的第一個消息開始。

消費者監聽消息的基本思路：

STREAM類型消息隊列的XREADGROUP命令特點：消息可回溯，一個消息可以只能被一個消費者讀取。可以阻塞讀取.沒有消息漏讀的風險，有消息確認機制，保證消息至少被消費一次。