訊息佇列，Message Queue，常用於解決並發系統中的資源一致性問題，提升峰值的處理能力，同時保證訊息的順序性、可恢復性、必送達性，對應用進行解耦，或實現非同步通訊等。 （建議學習：Redis影片教學）
市面上的MQ應用有很多（例如：Kafka，RabbitMQ，Disque），同時也可以基於Redis 來實現，比較典型的方案有：
基於List的LPUSH BRPOP 的實作
PUB/SUB，訂閱/發布模式
基於Sorted-Set的實作
基於Stream類型的實作
在訊息佇列使用中，有生產者producter和消費者consumer。生產者負責產生訊息，消費者負責使用處理訊息。
生產，指的是將訊息放入訊息佇列。
消費，指的是讀取並處理訊息。通常一個訊息再被消費後，就應該從訊息佇列中刪除。
基於List的LPUSH BRPOP 的實作
典型的指令為：##
LPUSH，将消息队列 BRPOP，从队列中取出消息，阻塞模式
此模式有許多優點：
實作簡單#Reids支援持久化訊息，表示訊息不會遺失，可以重複檢視（注意不是消費，只看不用，LRANGE類別的指示）。 可以保證順序，保證使用LPUSH指令，可以保證訊息的順序性使用RPUSH，可以將訊息放在佇列的開頭，達到優先訊息的目的，可以實現簡易的訊息優先隊列。同時也有些缺點：
做消費確認ACK比較麻煩，就是無法保證消費者在讀取之後，未處理後的宕機問題。導致訊息意外遺失。通常需要自行維護一個Pending列表，保證訊息的處理確認。 不能做廣播模式，例如典型的Pub/Discribe模式。 不能重複消費，一旦消費就會被刪除不支援分組消費，需要自己在業務邏輯層解決PUB/SUB，訂閱/發布模式
SUBSCRIBE，用于订阅信道 PUBLISH，向信道发送消息 UNSUBSCRIBE，取消订阅
典型的優點是：
典型的廣播模式，一個訊息可以發佈到多個消費者多頻道訂閱，消費者可以同時訂閱多個頻道，從而接收多類訊息訊息即時發送，訊息不用等待消費者讀取，消費者會自動接收到頻道發布的訊息也有些缺點：
訊息一旦發布，不能接收。換句話說是發佈時若客戶端不在線，則訊息遺失，不能尋回不能保證每個消費者接收的時間是一致的若消費者客戶端出現訊息積壓，到一定程度，會被強制斷開，導致訊息意外遺失。通常發生在訊息的生產遠大於消費速度時可見，Pub/Sub 模式不適合做訊息存儲，訊息積壓類的業務，而是擅長處理廣播，即時通訊，即時回饋的業務。基於SortedSet有序集合的實作
ZADD KEY score member，压入集合 ZRANGEBYSCORE，依据score获取成员
#基於Stream 類型的實作##這個Stream類型redis就是為了實現訊息隊列的。支援自動產生訊息ID，分組消費，ACK，訊息轉移，佇列監控等核心訊息佇列功能
更多Redis相關技術文章，請造訪
Redis入門教學以上是如何基於redis實作訊息佇列的詳細內容。更多資訊請關注PHP中文網其他相關文章！
