01 redis發布訂閱和stream(Redis和ActiveMQ之間是怎么交互的)

Redis發布訂閱和Stream

發布訂單系統是日常開發中經常會用到的功能。簡單來說，就是發布者發布消息，訂閱者就會接受到消息并進行相應的處理，如下圖所示。

Redis為我們提供了發布/訂閱的功能模塊PubSub，可以用于消息傳遞。

其中發布者publisher、訂閱者subscriber都是redis客戶端，channel則是redis服務器。

發布者publisher向channel發送消息，訂閱該channel的subscriber就會接收到消息。

發布消息publish

訂閱test1、test2的客戶端會收到消息

按照上述這種方式，如果 訂閱者subscriber想要訂閱多個channel 則需要同時指定多個channel的名稱，redis為了解決這個問題提供 psubscribe模式匹配 這種訂閱方式，可以通過通配符的方式匹配頻道。

發布消息

之前訂閱ch*的客戶端就會收到cha頻道和買粉絲頻道的消息，這樣就一次性訂閱多個頻道

redis服務端存儲了訂閱頻道/模式的客戶端列表

相當于如果客戶端訂閱一個頻道 ，那么服務端的 pubsub_channels 就會存儲一條數據， pubsub_channels 其實是一個鏈表，key對應channel，value對應客戶端列表，根據key訂閱的頻道，就可以找到訂閱該頻道的所有客戶端。

同時如果客戶端訂閱一個模式 ， pubsub_patterns 也會新增一條數據，記錄當前客戶端訂閱的模式， pubsub_patterns 也有自己的數據結構，其中就包含了客戶端以及模式。

當發布者向某個頻道發布消息時，就會遍歷 pubsub_channels 找到訂閱該頻道的客戶端列表，依次向這些客戶端發送消息。

然后遍歷 pubsub_patterns 找到符合當前頻道的模式，同時找到模式對應的客戶端，然后向客戶端發送消息。

雖然Redis提供了發布/訂閱的功能，但是并不完善，導致基本沒有合適的場景能夠使用。

PubSub缺點：

直到Redis5.0出現之后，出現了Stream這種數據結構，才終于完善了Redis的消息機制 。

Stream實際上就是一個消息列表，只是他幾乎實現了消息隊列所需要的所有功能，包括：

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

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

常見操作命令如下表：

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

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

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

Redis Stream類型的使用

最近在看 redis 這方面的知識，發現在 redis5 中產生了一種新的數據類型 Stream ，它和 kafka 的設計有些類似，可以當作一個簡單的消息隊列來使用。

解釋：

xadd 命令 返回的是數據的id, xx-yy (xx指的是毫秒數,yy指的是在這個毫秒內的第幾條消息)

指定指定Stream的大小比模糊指定Stream的大小會稍微多少消耗一些性能。

~ 模糊指定流的大小，可以看到指定的是1，實際上已經到了3.

使用redis的事務操作，獲取到同一毫秒產生的多條數據，時間戳一樣，序列號不一樣

-: 表示最小id的值

+: 表示最大id的值

(: 表示開區間

直接寫 毫秒 不寫后面的序列號即可。

start 和 end 的值寫的一樣即可獲取單挑數據。

使用 買粉絲unt 進行限制

使用方式和 XRANGE 類似，略。

需求： 往Stream中加入3條消息，然后刪除第2條消息

注意：

需要注意的是，我們從Stream中刪除一個消息，這個消息并不是被真正的刪除了，而是被 標記為刪除 ，這個時候這個消息還是占據著內容空間的。如果所有Stream中所有的消息都被標記刪除，這個時候才會回收內存空間。但是這個Stream并不會被刪除。

查看Stream中元素的長度

注意：

如果 xlen 后方的 key 不存在則返回0，否則返回元素的個數。

上方的意思是，保留 stream-key 這個Stream中最后的2個消息。

minid 是刪除比這個id小的數據，本地測試的時候 沒有測試出來 ，略。

XREAD 只是讀取消息，讀取完之后并不會刪除消息。 使用 XREAD 讀取消息，是完全獨立與消費者組的，多個客戶端可以同時讀取消息。

買粉絲unt 限制單次讀取最后的消息，因為當前讀取可能沒有這么多。

即讀取隊列尾的下一個消息，在非阻塞模式下始終是 nil

注意：

1、創建Stream的名稱是 stream-key

2、創建2個消息，aa和bb

$ 表示從最后一個元素消費，不包括Stream中的最后一個元素，即消費最新的消息。

1636362619125-0 某個消息的具體的ID,這個 g3 消費者組中的消息都是 大于> 這個id的消息。

也可以通過 x買粉絲claim 來實現。

Redis和ActiveMQ之間是怎么交互的

為什么會需要用這兩組件交互呢？

Redis，是一個緩存組件，可以提供key/value方式存儲（一般是內存，也可以刷到磁盤上，看需求與調整配置），數據存儲結構基于hash。redis還有另外一種通訊模型，pulish/subscibe(發布/訂閱模型)。連接/操作方式提供了多種編程語言的連接客戶端或者叫驅動。

ActiveMQ，是消息中間件，存儲模型隊列（有序、優先級）等，數據可以刷到磁盤（一般都需要刷到磁盤）。同時也有pulish/subscibe(發布/訂閱模型)，主要通信模式，最新的ActiveMQ可能還提供stream（流式處理）處理模式（可能基于發布/訂閱模式，做數據處理，記不太清楚，單中間件比如spring的stream是有這種實現的）。連接/操作方式也提供了多種語言編寫的客戶端/驅動程序。

兩個組件沒有直接交互方式。需要做交互，用兩組件支持的任何語言寫橋接組件。如把redis的數據讀出放到ActiveMQ中。也可以反過來操作。

結論，選擇一種會用的編程語言寫橋接組件操作。

基于Redission使用Redis的Stream

這里,有個group名字叫testGroup31，里面有消費者6個，pending代表目前有6個數據被讀取了，但沒有ack

last_delivered-id代表這個group目前讀到哪條消息

springbootredisstream消費失敗

1、首先默認的隊列監聽是自動確認的，但是如出現異常不會自動確認，默認的失敗機制是不斷重試，這樣會影響mq性能。

2、其次可以在配置文件中指定失敗重試次數和重試間隔。

3、然后配置之后將會按照間隔時間重試三次，重試之后如消息依然沒有發送的話消息將會直接丟棄。

4、最后這樣直接丟棄消息在某些場景下并不合適，所以需要使用到死信隊列，當消息不可達時由死信處理。

大數據分析應該掌握哪些基礎知識？

Java基礎語法

· 分支結構if/switch

· 循環結構for/while/do while

· 方法聲明和調用

· 方法重載

· 數組的使用

· 命令行參數、可變參數

IDEA

· IDEA常用設置、常用快捷鍵

· 自定義模板

· 關聯Tomcat

· Web項目案例實操

面向對象編程

· 封裝、繼承、多態、構造器、包

· 異常處理機制

· 抽象類、接口、內部類

· 常有基礎API、集合List/Set/Map

· 泛型、線程的創建和啟動

· 深入集合源碼分析、常見數據結構解析

· 線程的安全、同步和通信、IO流體系

· 反射、類的加載機制、網絡編程

Java8/9/10/11新特性

· Lambda表達式、方法引用

· 構造器引用、StreamAPI

· jShell(JShell)命令

· 接口的私有方法、Optional加強

· 局部變量的類型推斷

· 更簡化的編譯運行程序等

MySQL

· DML語言、DDL語言、DCL語言

· 分組查詢、Join查詢、子查詢、Union查詢、函數

· 流程控制語句、事務的特點、事務的隔離級別等

JDBC

· 使用JDBC完成數據庫增刪改查操作

· 批處理的操作

· 數據庫連接池的原理及應用

· 常見數據庫連接池C3P0、DBCP、Druid等

Maven

· Maven環

很赞哦!（379）