這期內容當中小編將會給大家?guī)碛嘘Predis中怎么實現(xiàn)發(fā)布訂閱模式，文章內容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

為亳州等地區(qū)用戶提供了全套網(wǎng)頁設計制作服務，及亳州網(wǎng)站建設行業(yè)解決方案。主營業(yè)務為成都做網(wǎng)站、網(wǎng)站設計、亳州網(wǎng)站設計，以傳統(tǒng)方式定制建設網(wǎng)站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

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

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

注意pubsub是一個數(shù)據(jù)結構。

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

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

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

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

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

PUBSUB是一個查看訂閱與發(fā)布系統(tǒng)狀態(tài)的內省命令，它由數(shù)個不同格式的子命令組成。

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

pattern 參數(shù)是可選的：

• 如果不給出 pattern 參數(shù)，那么列出訂閱與發(fā)布系統(tǒng)中的所有活躍頻道。

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

> pubsub channels1) "test"

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

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

PUBSUB NUMPAT返回訂閱模式的數(shù)量。

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

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

> pubsub numpat(integer) 1

模式匹配訂閱

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

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

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

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

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

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

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

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

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

4.難以實現(xiàn)復雜的消息模式

上述就是小編為大家分享的Redis中怎么實現(xiàn)發(fā)布訂閱模式了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)頁名稱：Redis中怎么實現(xiàn)發(fā)布訂閱模式
本文URL：http://jinyejixie.com/article12/jdoodc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、企業(yè)網(wǎng)站制作、建站公司、自適應網(wǎng)站、網(wǎng)頁設計公司、營銷型網(wǎng)站建設

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)