第三章· Redis消息隊列

一.生產消費模型



1.什麼是消息隊列？

在生活中，其實有不少的例子，都相似消息隊列。

好比：工廠生產出來的麪包，交給超市，商場來出售，客戶經過超市，商場來買麪包，客戶不會針對某一個工廠去選擇，只管從超市買出來，工廠也不會管是哪個客戶買了麪包，只管生產出來以後，交給超市，商場來處理。

消息隊列（Message Queue）是一種應用間的通訊方式，消息發送後能夠當即返回，有消息系統來確保信息的可靠專遞，消息生產者只管把消息發佈到MQ中而無論誰來取，消息消費者只管從MQ中取消息而無論誰發佈的，這樣發佈者和使用者都不用知道對方的存在。

2.爲何要使用消息隊列呢？

首先，咱們能夠知道，消息隊列是一種異步的工做機制，好比說日誌收集系統，爲了不數據在傳輸過程當中丟失，還有訂單系統，下單後，會生成對應的單據，庫存的扣減，消費信息的發送，一個下單，產生這麼多的消息，都是經過一個操做的觸發，而後將其餘的消息放入消息隊列中，依次產生。再就是不少網站的，秒殺活動之類的，前多少名用戶會便宜，都是經過消息隊列來實現的。

這些例子，都是經過消息隊列，來實現，業務的解耦，最終數據的一致性，廣播，錯峯流控等等，從而完成業務的邏輯。

3.消息隊列產品

1）rabbit-MQ（最初起源於金融系統，用於分佈式系統中存儲轉發消息。OpenStack）
2）Zero-MQ（SaltStack）
3）Kafka（JAVA）
4）redis（key:value數據庫，緩存，消息隊列）

二.Redis發佈消息的兩種模式

1.任務隊列模式（queuing）

任務隊列：顧名思義，就是「傳遞消息的隊列」。與任務隊列進行交互的實體有兩類，一類是生產者（producer），另外一類則是消費者（consumer）。生產者將須要處理的任務放入任務隊列中，而消費者則不斷地從任務獨立中讀入任務信息並執行。

任務隊列的好處
1）鬆耦合。
生產者和消費者只需按照約定的任務描述格式，進行編寫代碼。
2）易於擴展。
多消費者模式下，消費者能夠分佈在多個不一樣的服務器中，由此下降單臺服務器的負載。

2.發佈-訂閱模式(publish-subscribe)

其實從Pub/Sub的機制來看，它更像是一個廣播系統，多個訂閱者（Subscriber）能夠訂閱多個頻道（Channel），多個發佈者（Publisher）能夠往多個頻道（Channel）中發佈消息。
能夠這麼簡單的理解： 1）Subscriber：收音機，能夠收到多個頻道，並以隊列方式顯示 2）Publisher：電臺，能夠往不一樣的FM頻道中發消息 3）Channel：不一樣頻率的FM頻道

3.一個發佈者多個訂閱者模型

以下圖所示，能夠做爲消息隊列或者消息管道。
主要應用：通知、公告

4.多個發佈者一個訂閱者模型

能夠將PubSub作成獨立的HTTP接口，各應用程序做爲Publisher向Channel中發送消息，Subscriber端收到消息後執行相應的業務邏輯，好比寫數據庫，顯示等等。
主要應用：排行榜、投票、計數。


5.多個發佈者多個訂閱者模型

故名思議，就是能夠向不一樣的Channel中發送消息，由不一樣的Subscriber接收。
主要應用：羣聊、聊天。

6.Redis發佈訂閱實踐

1）PUBLISH channel msg
將信息 message 發送到指定的頻道 channel

2）SUBSCRIBE channel [channel ...]
訂閱頻道，能夠同時訂閱多個頻道

3）UNSUBSCRIBE [channel ...]
取消訂閱指定的頻道, 若是不指定頻道，則會取消訂閱全部頻道

4）PSUBSCRIBE pattern [pattern ...]
訂閱一個或多個符合給定模式的頻道，每一個模式以 * 做爲匹配符，好比 it* 匹配所 有以 it 開頭的頻道( it.news 、 it.blog 、 it.tweets 等等)， news.* 匹配全部 以 news. 開頭的頻道( news.it 、 news.global.today 等等)，諸如此類

5）PUNSUBSCRIBE [pattern [pattern ...]]
退訂指定的規則, 若是沒有參數則會退訂全部規則

6）PUBSUB subcommand [argument [argument ...]]
查看訂閱與發佈系統狀態

注意：使用發佈訂閱模式實現的消息隊列，當有客戶端訂閱channel後只能收到後續發佈到該頻道的消息，以前發送的不會緩存，必須Provider和Consumer同時在線。

訂閱單個頻道

#第一個窗口
#登陸Redis
[root@db01 ~]# redis-cli -a 123
#在訂閱者的服務器上輸入訂閱zls
127.0.0.1:6379> SUBSCRIBE zls
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "zls"
3) (integer) 1

#第二個窗口
#登陸Redis
[root@db01 ~]# redis-cli -a 123
#在發佈者的服務器上輸入信息
127.0.0.1:6379> PUBLISH zls "The Nice Boy Like Me."
(integer) 1

#第一個窗口
#在訂閱者的服務器上會看到以下信息
1) "message"
2) "zls"
3) "The Nice Boy Like Me."

結果以下:

訂閱多個頻道

#第一個窗口
#登陸Redis
[root@db01 ~]# redis-cli -a 123
#在訂閱者服務器上輸入訂閱全部頻道
127.0.0.1:6379> PSUBSCRIBE *
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "*"
3) (integer) 1

#第二個窗口
#在發佈者服務器上輸入多頻道信息
127.0.0.1:6379> PUBLISH zls "The Nice Boy Like Me."
(integer) 1
127.0.0.1:6379> PUBLISH bgx "The Ugly Old Man Like Me."
(integer) 1

#第一個窗口
#在訂閱者的服務器上會看到以下信息
1) "pmessage"
2) "*"
3) "zls"
4) "The Nice Boy Like Me."


1) "pmessage"
2) "*"
3) "bgx"
4) "The Ugly Old Man Like Me."

結果以下:

7.消息隊列系統對比

客戶端在執行訂閱命令以後進入了訂閱狀態，只能接收 SUBSCRIBE 、PSUBSCRIBE、 UNSUBSCRIBE 、PUNSUBSCRIBE 四個命令。 開啓的訂閱客戶端，沒法收到該頻道以前的消息，由於 Redis 不會對發佈的消息進行持久化。 和不少專業的消息隊列系統（例如Kafka、RocketMQ、RabbitMQ）相比，Redis的發佈訂閱略顯粗糙。

例如:沒法實現消息堆積和回溯。但勝在足夠簡單，若是當前場景能夠容忍的這些缺點，也不失爲一個不錯的選擇。