實現了消息隊列所需要的所有功能，包括：

同時需要注意的是Stream只是一個數據結構，他不會主動把消息推送給消費者，需要消費者主動來消費數據 。

每個Stream都有唯一的名稱，它就是Redis的key，首次使用 xadd 指令追加消息時自動創建。

常見操作命令如下表：

如果客戶端希望知道自身消費到第幾條數據了，那么就需要記錄一下當前消費的消息ID，下次再次消費的時候就從上次消費的消息ID開始讀取數據即可。

消費組中多了一個游標 last_delivered_id ，表示當前消費到了哪一條數據。同時所有的數據都是待處理消息（ PEL ），只有消費者處理完畢之后使用 ack 指令告知redis服務器，數據才會從 PEL 中移除，確認后的消息就無法再次消費。

如果接收到的消息比較多，為了避免Stream過長，可以選擇指定Stream的最大長度，一旦到達了最大長度，就會從最早的消息開始清除，保證Stream中最新的消息。

redis頻道收到發布者信息后可以只推信息給一個訂閱者嗎

Redis 的 SUBSCRIBE 命令可以讓客戶端訂閱任意數量的頻道， 每當有新信息發送到被訂閱的頻道時， 信息就會被發送給所有訂閱指定頻道的客戶端。

作為例子， 下圖展示了頻道 channel1 ， 以及訂閱這個頻道的三個客戶端 —— client2 、 client5 和 client1 之間的關系：

spring-redis 發布訂閱模式：發布一條消息收到了兩條，重復監聽

當你看到這個文章時，想必已經了解了一些關于spring-redis發布訂閱方面的知識，如果你也遇到同樣的問題

那么請考慮spring在啟動時有沒有重復的加載配置文件

具體的方式可以在 AbstractApplicationContext 的 refresh() 方法中打斷點，如果走了兩次，說明配置文件加載了兩遍

而配置文件加載兩遍的原因是因為web.xml中DispatcherServlet和ContextLoaderLinistener 共用了 某些配置文件導致的。

redis怎么做消息隊列？

基于Redis消息隊列-實現短信服務化

1.Redis實現消息隊列原理，常用的消息隊列有RabbitMQ,ActiveMQ，個人覺得這種消息隊列太大太重，本文介紹下基于Redis的輕量級消息隊列服務。 一般來說，消息隊列有兩種模式，一種是發布者訂閱模式，另外一種是生產者和消費者模式。Redis的消息隊列，也是基于這2種原理的實現。 發布者和訂閱者模式：發布者發送消息到隊列，每個訂閱者都能收到一樣的消息。 生產者和消費者模式：生產者將消息放入隊列，多個消費者共同監聽，誰先搶到資源，誰就從隊列中取走消息去處理。注意，每個消息只能最多被一個消費者接收。