消息隊列RabbitMQ基礎知識詳解


一: 什么是MQ?

    MQ全稱為Message Queue, 消息隊列(MQ)是一種應用程序對應用程序或者模塊對模塊的通信方法。MQ是消費-生產者模型的一個典型的代表,一端往消息隊列中不斷寫入消息,而另一端則可以讀取隊列中的消息。

    常見的消息隊列有RabbitMQ和kafka。下面詳細介紹一下RabbitMQ的適用場景和基本概念。

二: 適用場景

2.1 並發處理

(1)串行方式:將注冊信息寫入數據庫后,發送注冊郵件,再發送注冊短信,以上三個任務全部完成后才返回給客戶端。 這有一個問題是,郵件,短信並不是必須的,它只是一個通知,而這種做法讓客戶端等待沒有必要等待的東西.

消息隊列RabbitMQ基礎知識詳解

 

(2)並行方式:將注冊信息寫入數據庫后,發送郵件的同時,發送短信,以上三個任務完成后,返回給客戶端,並行的方式能提高處理的時間。

消息隊列RabbitMQ基礎知識詳解

 

    假設三個業務節點分別使用50ms,串行方式使用時間150ms,並行使用時間100ms。雖然並發已經提高了處理時間,但是,前面說過,郵件和短信對我們正常的使用網站沒有任何影響,客戶端沒有必要等着其發送完成才顯示注冊成功,因而是寫入數據庫后就返回.

(3)消息隊列

    引入消息隊列后,把發送郵件,短信不是必須的業務邏輯異步處理

消息隊列RabbitMQ基礎知識詳解

 

    由此可以看出,引入消息隊列后,用戶的響應時間就等於寫入數據庫的時間+寫入消息隊列的時間(可以忽略不計),引入消息隊列后處理后,響應時間是串行的3倍,是並行的2倍。

2.2 應用解耦

    場景:雙11是購物狂節,用戶下單后,訂單系統需要通知庫存系統,傳統的做法就是訂單系統調用庫存系統的接口.

消息隊列RabbitMQ基礎知識詳解

 

  這種做法有一個缺點:

  • 當庫存系統出現故障時,訂單就會失敗。(這樣馬雲將少賺好多好多錢^ ^)
  • 訂單系統和庫存系統高耦合.
  • 引入消息隊列
消息隊列RabbitMQ基礎知識詳解
  • 訂單系統:用戶下單后,訂單系統完成持久化處理,將消息寫入消息隊列,返回用戶訂單下單成功。
  • 庫存系統:訂閱下單的消息,獲取下單消息,進行庫操作。
  • 就算庫存系統出現故障,消息隊列也能保證消息的可靠投遞,不會導致消息丟失(馬雲這下高興了).

2.3: 流量削峰

  流量削峰一般在秒殺活動中應用廣泛

  場景:秒殺活動,一般會因為流量過大,導致應用掛掉,為了解決這個問題,一般在應用前端加入消息隊列。

作用:

1.可以控制活動人數,超過此一定閥值的訂單直接丟棄(我為什么秒殺一次都沒有成功過呢^^)

2.可以緩解短時間的高流量壓垮應用(應用程序按自己的最大處理能力獲取訂單)

消息隊列RabbitMQ基礎知識詳解

 

1.用戶的請求,服務器收到之后,首先寫入消息隊列,加入消息隊列長度超過最大值,則直接拋棄用戶請求或跳轉到錯誤頁面.

2.秒殺業務根據消息隊列中的請求信息,再做后續處理.

三: 詳解

3.1、隊列、生產者、消費者

  隊列是RabbitMQ的內部對象,用於存儲消息。生產者(下圖中的P)生產消息並投遞到隊列中,消費者(下圖中的C)可以從隊列中獲取消息並消費。

消息隊列RabbitMQ基礎知識詳解

 

  多個消費者可以訂閱同一個隊列,這時隊列中的消息會被平均分攤給多個消費者進行處理,而不是每個消費者都收到所有的消息並處理。

消息隊列RabbitMQ基礎知識詳解

 

3.2、Exchange、Binding

    剛才在3.1中,我們看到生產者將消息投遞到隊列中,實際上這在RabbitMQ中這種事情永遠都不會發生。實際的情況是,生產者將消息發送到Exchange(交換器,下圖中的X),再通過Binding將Exchange與Queue關聯起來。

消息隊列RabbitMQ基礎知識詳解

 

3.3、Exchange Type、Bingding key、routing key

  在綁定(Binding)Exchange與Queue的同時,一般會指定一個binding key。在綁定多個Queue到同一個Exchange的時候,這些Binding允許使用相同的binding key。

生產者在將消息發送給Exchange的時候,一般會指定一個routing key,來指定這個消息的路由規則,生產者就可以在發送消息給Exchange時,通過指定routing key來決定消息流向哪里。

  RabbitMQ常用的Exchange Type有三種:fanout、direct、topic。

  •   fanout:把所有發送到該Exchange的消息投遞到所有與它綁定的隊列中。
  •   direct:把消息投遞到那些binding key與routing key完全匹配的隊列中。
  •   topic:將消息路由到binding key與routing key模式匹配的隊列中。

附上一張RabbitMQ的結構圖:

消息隊列RabbitMQ基礎知識詳解

 

四: 最后來具體解析一下幾個問題:

1、可以自動創建隊列,也可以手動創建隊列,如果自動創建隊列,那么是誰負責創建隊列呢?是生產者?還是消費者?

    如果隊列不存在,當然消費者不會收到任何的消息。但是如果隊列不存在,那么生產者發送的消息就會丟失。所以,為了數據不丟失,消費者和生產者都可以創建隊列。那么如果創建一個已經存在的隊列呢?那么不會有任何的影響。需要注意的是沒有任何的影響,也就是說第二次創建如果參數和第一次不一樣,那么該操作雖然成功,但是隊列屬性並不會改變。

隊列對於負載均衡的處理是完美的。對於多個消費者來說,RabbitMQ使用輪詢的方式均衡的發送給不同的消費者。

 

2、RabbitMQ的消息確認機制

    默認情況下,如果消息已經被某個消費者正確的接收到了,那么該消息就會被從隊列中移除。當然也可以讓同一個消息發送到很多的消費者。

如果一個隊列沒有消費者,那么,如果這個隊列有數據到達,那么這個數據會被緩存,不會被丟棄。當有消費者時,這個數據會被立即發送到這個消費者,這個數據被消費者正確收到時,這個數據就被從隊列中刪除。

    那么什么是正確收到呢?通過ack。每個消息都要被acknowledged(確認,ack)。我們可以顯示的在程序中去ack,也可以自動的ack。如果有數據沒有被ack,那么:

RabbitMQ Server會把這個信息發送到下一個消費者。

如果這個app有bug,忘記了ack,那么RabbitMQServer不會再發送數據給它,因為Server認為這個消費者處理能力有限。

而且ack的機制可以起到限流的作用(Benefitto throttling):在消費者處理完成數據后發送ack,甚至在額外的延時后發送ack,將有效的均衡消費者的負載。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM