RabbitMQ消息隊列

一、消息隊列

消息隊列就是一種<code>先進先出</code>的資料機構

當在分布式系統中的時候，不同的機器需要做資料互動，是以涉及到不同機器之間的資料互動，這樣的話就需要借助專業的消息隊列，常見的消息隊列有 RabbitMQ 、Kafka...他們都是開源且支援語言較多。

消息隊列解決的問題：

應用解耦

流量消峰：

如果訂單系統一秒最多能處理一萬次訂單，這個處理能力在平時綽綽有餘，正常時段我們下單一秒後就能傳回結果。但是在高峰期，如果有兩萬次下單作業系統是處理不了的，隻能限制訂單超過一萬後不允許使用者下單。

但是使用消息隊列，就可以取消這個限制，把這一秒内的訂單放入隊列中分散成一段時間來處理，這樣使用者就可能在下單幾十秒後才能收到下單成功的操作，但是比不能下單要好。

消息分發：

當A發送一次消息，B對消息感興趣，就隻需監聽消息，C感興趣，C也去監聽消息，而A完全不需要改動。

異步消息（Celery 就是對消息隊列的分裝）

RabbitMQ 和 Kafka

RabbitMQ ：吞吐量小，有消息确認（對消息可靠性有要求，就用它）

Kafka：吞吐量高，注重高吞吐量，不注重消息的可靠性，資料量特别大

二、按裝RabbitMQ

1、原生安裝：

2、docker拉取

三、基本使用

生産者：

消費者：

四、确認機制

消息确認機制其實就是消費者中 auto_ack 的設定

生産者不變

五、持久化

隊列持久化：就是在聲明隊列的時候，指定持久化<code>durable=True</code>，隊列必須是新的才可以

消息持久化：就是在釋出消息的時候添加

六、閑置消費

當正常情況下如果有多個消費者，那麼就會按照順序第一個消息給 第一個消費者，第二個消息給第二個消費者

但是當第一個消息的消費者處理資訊很耗時，一直沒有結束，那麼就可以讓第二個消費者優先擷取閑置消息。

七、釋出訂閱

釋出訂閱就是：我可以有多個訂閱者來訂閱你的消息，這樣釋出者隻需要釋出一條， 我的所有隻要訂閱你的人都可以消費你的消息

模型：當我的訂閱者起來了之後，就會建立一個隊列，多個訂閱者就會建立多個隊列，當釋出者生産了消息之後，會傳給 exchange ，然後 exchange 會把消息複制分别分發到訂閱者建立的隊列中，這樣就實作了隻要監聽你，那就能收到你發的消息。

釋出者：

訂閱者：啟動多次，都綁定到了同一個 exchange，是以就會都收到同一個 exchange 分發的消息

需要設定 exchange_type 的類型為 direct

并且在釋出消息的時候設定多個關鍵字：routing_key

在訂閱者中也需要設定 exchange_type 的類型 direct

并且當訂閱者綁定 exchange 的時候也需要設定 routing_key，

這樣的話在釋出者釋出消息後，exchange 會根據釋出者和訂閱者設定的 routing_key 進行比對，當訂閱者的 routing_key 比對上了釋出者的 routing_key 的話，那麼訂閱者就可以接收到釋出者釋出的消息，反之收不到消息。

消費者1：

消費者2：

在訂閱者綁定比對的時候可以進行模糊比對釋出者的 routing_key ，比對上了就能接收到釋出者釋出的消息

訂閱者：

八、python中的RPC架構

RPC ：遠端過程調用

例如：兩個服務調用，服務1通過網絡調用服務2的方法。

自帶的：資料包大，速度慢

服務端：

用戶端：

第三方的：底層使用 ZeroMQ 和 MessagePack ，速度快，響應時間短，并發高。

學習之旅