RabbitMQ 使用場景、安裝、工作模式

一、使用場景

1、服務解耦

假設有這樣一個場景, 服務A產生資料, 而服務B,C,D需要這些資料, 那麼我們可以在A服務中直接呼叫B,C,D服務,把資料傳遞到下游服務即可

但是,隨著我們的應用規模不斷擴大,會有更多的服務需要A的資料,如果有幾十甚至幾百個下游服務,而且會不斷變更,再加上還要考慮下游服務出錯的情況,那麼A服務中呼叫程式碼的維護會極為困難

這是由於服務之間耦合度過於緊密

再來考慮用RabbitMQ解耦的情況

A服務只需要向訊息伺服器傳送訊息,而不用考慮誰需要這些資料;下游服務如果需要資料,自行從訊息伺服器訂閱訊息,不再需要資料時則取消訂閱即可

2、流量削峰

假設我們有一個應用,平時訪問量是每秒300請求,我們用一臺伺服器即可輕鬆應對

而在高峰期,訪問量瞬間翻了十倍,達到每秒3000次請求,那麼單臺伺服器肯定無法應對,這時我們可以考慮增加到10臺伺服器,來分散訪問壓力

但如果這種瞬時高峰的情況每天只出現一次,每次只有半小時,那麼我們10臺伺服器在多數時間都只分擔每秒幾十次請求,這樣就有點浪費資源了

這種情況,我們就可以使用RabbitMQ來進行流量削峰,高峰情況下,瞬間出現的大量請求資料,先傳送到訊息佇列伺服器,排隊等待被處理,而我們的應用,可以慢慢的從訊息佇列接收請求資料進行處理,這樣把資料處理時間拉長,以減輕瞬時壓力

這是訊息佇列伺服器非常典型的應用場景

3、非同步呼叫

考慮定外賣支付成功的情況

支付後要傳送支付成功的通知,再尋找外賣小哥來進行配送,而尋找外賣小哥的過程非常耗時,尤其是高峰期,可能要等待幾十秒甚至更長

這樣就造成整條呼叫鏈路響應非常緩慢

而如果我們引入RabbitMQ訊息佇列,訂單資料可以傳送到訊息佇列伺服器,那麼呼叫鏈路也就可以到此結束,訂單系統則可以立即得到響應,整條鏈路的響應時間只有200毫秒左右

尋找外賣小哥的應用可以以非同步的方式從訊息佇列接收訂單訊息,再執行耗時的尋找操作

二、Rabbitmq 基本概念

RabbitMQ是一種訊息中介軟體，用於處理來自客戶端的非同步訊息。服務端將要傳送的訊息放入到佇列池中。接收端可以根據RabbitMQ配置的轉發機制接收服務端發來的訊息。RabbitMQ依據指定的轉發規則進行訊息的轉發、緩衝和持久化操作，主要用在多伺服器間或單伺服器的子系統間進行通訊，是分散式系統標準的配置。

Exchange（交換機）

接受生產者傳送的訊息，並根據Binding規則將訊息路由給伺服器中的佇列。ExchangeType決定了Exchange路由訊息的行為。在RabbitMQ中，ExchangeType常用的有direct、Fanout和Topic三種。

Message Queue（資訊佇列）

訊息佇列。我們傳送給RabbitMQ的訊息最後都會到達各種queue，並且儲存在其中(如果路由找不到相應的queue則資料會丟失)，等待消費者來取。

Binding Key（繫結key佇列）

它表示的是Exchange與Message Queue是通過binding key進行聯絡的，這個關係是固定。

Routing Key（路由key佇列）

生產者在將訊息傳送給Exchange的時候，一般會指定一個routing key，來指定這個訊息的路由規則。這個routing key需要與Exchange Type及binding key聯合使用才能生，我們的生產者只需要通過指定routing key來決定訊息流向哪裡。

三、Rabbitmq六種工作模式

1、簡單模式

RabbitMQ是一個訊息中介軟體，你可以想象它是一個郵局。當你把信件放到郵箱裡時，能夠確信郵遞員會正確地遞送你的信件。RabbitMq就是一個郵箱、一個郵局和一個郵遞員。

• 傳送訊息的程式是生產者
• 佇列就代表一個郵箱。雖然訊息會流經RbbitMQ和你的應用程式，但訊息只能被儲存在佇列裡。佇列儲存空間只受伺服器記憶體和磁碟限制，它本質上是一個大的訊息緩衝區。多個生產者可以向同一個佇列傳送訊息，多個消費者也可以從同一個佇列接收訊息.
• 消費者等待從佇列接收訊息

2、工作模式

3、釋出訂閱模式

4、路由模式

5、主題模式

6、RPC模式