Redis中怎么實現發布訂閱模式

這期內容當中小編將會給大家帶來有關Redis中怎么實現發布訂閱模式，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

發布訂閱(pub/sub)是一種消息通信模式：發送者(pub)在某一頻道發送消息，訂閱者(sub)接收消息。發布訂閱模式類似與微博關注，比如說博主mango被張三、李四、王五關注，那么mango發一篇微博的時候張李王三人都會從關注里看到這條微博。

那么發布訂閱和生產消費有何異同之處呢？生產消費主要是生成一個消息只能被一個客戶端消費，而發布訂閱可以理解為發布一條消息，在該頻道中的所有客戶端都會收到，所以有時候我們這個發布訂閱類似廣播。

注意pubsub是一個數據結構。

前面提到客戶端能接受到消息首先要訂閱頻道，那么redis中的訂閱命令subscribe channel [channel ...] 這里可以訂閱多個頻道。訂閱后我們需要發布消息到這個頻道中publish channel message。

####訂閱test頻道> subscribe testReading messages... (press Ctrl-C to quit)1) "subscribe"2) "test"3) (integer) 1

####發布信息> publish test 'hello'(integer) 1

不是可以廣播嘛，那么我們再起一個客戶端

當然redis還提供退訂unsubscribe 跟subscribe 的使用方式一樣。

PUBSUB是一個查看訂閱與發布系統狀態的內省命令，它由數個不同格式的子命令組成。

PUBSUB CHANNELS [pattern] 列出當前的活躍頻道。活躍頻道指的是那些至少有一個訂閱者的頻道， 訂閱模式的客戶端不計算在內。

pattern 參數是可選的：

• 如果不給出 pattern 參數，那么列出訂閱與發布系統中的所有活躍頻道。

• 如果給出 pattern 參數，那么只列出和給定模式 pattern 相匹配的那些活躍頻道。

> pubsub channels1) "test"

PUBSUB NUMSUB [channel-1 ... channel-N] 列出當前的活躍頻道和返回連接數

> pubsub numsub test1) "test"        #頻道2) (integer) 2   #連接數> pubsub numsub test11) "test1"2) (integer) 0

PUBSUB NUMPAT 返回訂閱模式的數量。

注意，這個命令返回的不是訂閱模式的客戶端的數量，而是客戶端訂閱的所有模式的數量總和，可以理解為模式匹配，例如訂閱一個test*，客戶端能接收test、test1、test2等等這樣的，看下面例子。

####客戶端> psubscribe test*Reading messages... (press Ctrl-C to quit)1) "psubscribe"2) "test*"3) (integer) 1

> pubsub numpat(integer) 1

模式匹配訂閱

介紹完發布訂閱的一般模式，此時我們小伙伴就問，長得跟mango一樣的我能不能訂閱呢？當然redis是支持這種模糊訂閱的，其命令為psubscribe，跟subscribe使用方式一致。

> psubscribe test*Reading messages... (press Ctrl-C to quit)1) "psubscribe"2) "test*"3) (integer) 1

我們直到redis是key-value鍵值對的字典，PubSub前面講過是一個數據結構，那么它是如何存儲在內存中的呢？看老夫畫圖來解答。

我們從圖中可以看到每個頻道放入字典數組中，對應頻道的訂閱者則放入鏈表中，當我們發送一個publish命令時，首先字典數組遍歷找到對應的頻道，然后找到對應的訂閱鏈，依次發送消息。

所以我們可以看出每次發送消息時我們的都需要遍歷這個字典，也就是說它的執行時間效率為O(n)，但是我們redis的宗旨是快，減少執行O(n)的命令，這違背了我們當初的初衷

PubSub的發布者傳遞過來一個消息，Redis會直接找到相應的訂閱者傳遞過去。如果一個訂閱者都沒有，那么消息會被直接丟棄。如果開始有三個訂閱者，第三個訂閱者突然掛掉了，發布者會繼續發送消息，另外兩個訂閱者可以持續收到消息，但是當掛掉的訂閱者重新連上的時候，在斷連期間發布者發送的消息，對于這個發布者來說就是徹底丟失了。
如果Redis停機重啟，PubSub的消息是不會持久化的，畢竟Redis開機就相當于一個訂閱者都沒有，所有的消息會被直接丟棄。正是因為PubSub有這些缺點，在消息隊列的領域它幾乎找不到合適的應用場景。
所以Redis的作者單獨開啟了一個項目Disque專門用來做多播消息隊列，不過該項目目前沒有成熟，直處于Beta版本。

1.難以保證消息隊列的ACK，消息發送出去后沒有一個回饋過程，消息無法做持久化

2.如果保證消息持久化，那么必定損失性能，首先我們需要把消息存入磁盤，然后從磁盤中讀取數據到內存去操作，這個過程是非常耗時的

3.PubSub執行效率低，執行效率是O(n)，違背了redis設計初衷

4.難以實現復雜的消息模式

上述就是小編為大家分享的Redis中怎么實現發布訂閱模式了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。