RabbitMQ 發佈訂閱

 

互聯網公司對消息隊列是深度使用者，所以須要咱們瞭解消息隊列的方方面面，良好的設計及深刻的理解，更有利於咱們對消息隊列的規劃。

當前咱們使用消息隊列中發現一些問題：

一、其實是異步無返回遠程調用，由發佈者定義隊列，消費者訂閱已定義的隊列。

二、並無體現解耦設計，並且開發人員間依然要像單體項目開發那樣針對同一個功能不斷溝通交互，提升了開發時間以及成本。

三、沒有消息版本的實現，致使發佈者服務和消費者服務必須一塊兒更新。若是沒有保持一致可能致使批量的合法消息被丟到死信隊列，甚至可能要啓動舊服務將舊版本的消息消費掉才能更新服務。而且開發人員要進入發佈流程指導各服務的發佈順序。

四、訂閱者的對象定義在「集羣」，但現實中的確存在「節點」的訂閱需求，如節點的配置更新、本地緩存的刷新等。

快速、高效的使用消息隊列，不須要過多的溝通成本，是咱們不斷的追求。所以發佈訂閱映入咱們眼簾，公司內部稱爲分佈式事件。

RabbitMQ的發佈訂閱能解決咱們的什麼問題呢？

1. 不須要發送端和接收端同時發佈。相比較普通的隊列方式，若是發送端發佈，而消費端未發佈，那麼就會有大量的消息積壓。
2. 實現一次發佈，屢次處理。

RabbitMQ發佈訂閱模式：像使用郵箱同樣，不須要發送端和接收端共同發佈。

發佈訂閱基礎概念：

Exchange在定義的時候是有類型的，以決定究竟是哪些Queue符合條件，能夠接收消息：

1. fanout：全部bind到此exchange的queue均可以接收消息
2. direct：經過routingKey和exchange決定的那個惟一的queue能夠接收消息
3. topic：全部符合routingKey(此時能夠是一個表達式)的routingKey所bind的queue能夠接收消息
4. headers：經過headers 來決定把消息發給哪些queue(這個不多用)

fanout訂閱發佈模式（廣播模式）

direct訂閱發佈模式（廣播模式）

 

topic定義發佈模式（廣播模式）

實現發佈訂閱模式下消息的發佈訂閱主要有如下幾個步驟：

1. 建立消息會話IMQSession（前提鏈接IMQConnection已經創建好了）
2. 聲明要訂閱的消息主題
3. 聲明消息主題訂閱者
4. 聲明消息發送者
5. 發送消息
6. 主題訂閱者接收消息
7. 關閉主題訂閱者
8. 關閉會話

生產者發送廣播是實時的，消費者須要提早等待生產者發生消息，這個又叫訂閱發佈，收音機模式，就像只有收音機打開了才能聽到鎖定的FM頻道，可是若是在節目開始一段時間，再打開收音機的話，以前的節目就收聽不到了。即訂閱以前的消息都是收不到的。

發佈訂閱相關的執行命令：

rabbitmqctl list_exchanges  列出全部exchange

臨時隊列：

    咱們須要每次鏈接至mq的時候使用一個新隊列，使用完了就銷燬，這裏可以使用臨時隊列：

result = channel.queue_declare()

   而後就能夠經過result.method.queue獲取臨時隊列名稱，提供給消費者使用。 另外消費者用完後須要銷燬，可添加一個exclusive選項：result = channel.queue_declare(exclusive=True)  表明該隊列是排他性隊列。

綁定：Binding

channel.queue_bind(exchange='logs',
                   queue=result.method.queue)

查看系統全部的綁定命令

rabbitmqctl list_binding

發佈訂閱相關的概念主要包括exchange、binding、routingkey、及queue。咱們只須要按照步驟，使用合適的交換器類型，便可實現發佈訂閱的一對多消息處理。