MQ訊息佇列相關概念 MQ分類及如何選擇

2022-10-11 09:57:14 字數 3544 閱讀 9938

1.1.1. 什麼是mq

mq(message queue),從字面意思上看,本質是個佇列, fifo 先入先出,只不過佇列中存放的內容是message 而已,還是一種跨程序的通訊機制,用於上下游傳遞訊息。在網際網路架構中, mq 是一種非常常見的上下游「邏輯解耦+物理解耦」 的訊息通訊服務。使用了 mq 之後,訊息傳送上游只需要依賴 mq,不用依賴其他服務。

1.1.2. 為什麼要用mq

1.流量消峰

舉個例子,如果訂單系統最多能處理一萬次訂單,這個處理能力應付正常時段的下單時綽綽有餘,正常時段我們下單一秒後就能返回結果。但是在高峰期,如果有兩萬次下單作業系統是處理不了的,只能限制訂單超過一萬後不允許使用者下單。使用訊息佇列做緩衝,我們可以取消這個限制,把一秒內下的訂單分散成一段時間來處理,這時有些使用者可能在下單十幾秒後才能收到下單成功的操作,但是比不能下單的體驗要好。

2.應用解耦

以電商應用為例,應用中有訂單系統、庫存系統、物流系統、支付系統。使用者建立訂單後,如果耦合

呼叫庫存系統、物流系統、支付系統,任何乙個子系統出了故障,都會造成下單操作異常。當轉變成基於訊息佇列的方式後,系統間呼叫的問題會減少很多,比如物流系統因為發生故障,需要幾分鐘來修復。在這幾分鐘的時間裡,物流系統要處理的記憶體被快取在訊息佇列中,使用者的下單操作可以正常完成。當物流系統恢復後,繼續處理訂單資訊即可,中單使用者感受不到物流系統的故障,提公升系統的可用性。

3.非同步處理

有些服務間呼叫是非同步的,例如 a 呼叫 b, b 需要花費很長時間執行,但是 a 需要知道 b 什麼時候可以執行完,以前一般有兩種方式, a 過一段時間去呼叫 b 的查詢 api 查詢。或者 a 提供乙個 callback api,b 執行完之後呼叫 api 通知 a 服務。這兩種方式都不是很優雅,使用訊息匯流排,可以很方便解決這個問題,a 呼叫 b 服務後,只需要監聽 b 處理完成的訊息,當 b 處理完成後,會傳送一條訊息給 mq, mq 會將此訊息**給 a 服務。這樣 a 服務既不用迴圈呼叫 b 的查詢 api,也不用提供 callback api。同樣b 服務也不用做這些操作。 a 服務還能及時的得到非同步處理成功的訊息。

1.1.3. mq 的分類

1.activemq

優點:單機吞吐量萬級,時效性 ms 級,可用性高,基於主從架構實現高可用性,訊息可靠性較低的概率丟失資料。

缺點:官方社群現在對 activemq 5.x維護越來越少,高吞吐量場景較少使用

2.kafka

大資料的殺手鐗,談到大資料領域內的訊息傳輸,則繞不開 kafka,這款為大資料而生的訊息中介軟體,以其百萬級 tps的吞吐量名聲大噪,迅速成為大資料領域的寵兒,在資料採集、傳輸、儲存的過程中發揮著舉足輕重的作用。目前已經被 linkedin, uber, twitter, netflix 等大公司所採納。

優點:效能卓越,單機寫入 tps 約在百萬條/秒,最大的優點,就是吞吐量高。時效性 ms 級可用性非

常高, kafka 是分布式的,乙個資料多個副本,少數機器宕機,不會丟失資料,不會導致不可用,消費者採用 pull 方式獲取訊息, 訊息有序, 通過控制能夠保證所有訊息被消費且僅被消費一次;有優秀的第三方kafkaweb 管理介面 kafka-manager;在日誌領域比較成熟,被多家公司和多個開源專案使用;功能支援: 功能較為簡單,主要支援簡單的 mq 功能,在大資料領域的實時計算以及日誌採集被大規模使用。

缺點: kafka 單機超過 64 個佇列/分割槽, load 會發生明顯的飆高現象,佇列越多, load 越高,傳送訊息響應時間變長,使用短輪詢方式,實時性取決於輪詢間隔時間,消費失敗不支援重試;支援訊息順序,但是一台**宕機後,就會產生訊息亂序,社群更新較慢

3.rocketmq

rocketmq 出自阿里巴巴的開源產品,用 j**a 語言實現,在設計時參考了 kafka,並做出了自己的一些改進。被阿里巴巴廣泛應用在訂單,交易,充值,流計算,訊息推送,日誌流式處理, binglog 分發等場景。

優點:單機吞吐量十萬級,可用性非常高,分布式架構,訊息可以做到 0 丟失,mq 功能較為完善,還是分布式的,擴充套件性好,支援 10 億級別的訊息堆積,不會因為堆積導致效能下降,原始碼是 j**a 我們可以自己閱讀原始碼,定製自己公司的 mq。

缺點:支援的客戶端語言不多,目前是 j**a 及 c++,其中 c++不成熟;社群活躍度一般,沒有在mq核心中去實現 jms 等介面,有些系統要遷移需要修改大量**。

4.rabbitmq

2007 年發布,是乙個在amqp(高階訊息佇列協議)基礎上完成的,可復用的企業訊息系統,是當前最

主流的訊息中介軟體之一

優點:由於 erlang 語言的高併發特性,效能較好;吞吐量到萬級, mq 功能比較完備,健壯、穩定、易用、跨平台、支援多種語言。如: python、 ruby、 .net、 j**a、 jms、 c、 php、actionscript、 xmpp、 stomp等,支援 ajax 文件齊全;開源提供的管理介面非常棒,用起來很好用,社群活躍度高;更新頻率相當高。

缺點:商業版需要收費,學習成本較高。

1.1.4. mq 的選擇

1.kafka

kafka 主要特點是基於pull 的模式來處理訊息消費,追求高吞吐量,一開始的目的就是用於日誌收集和傳輸,適合產生大量資料的網際網路服務的資料收集業務。大型公司建議可以選用,如果有日誌採集功能,肯定是首選 kafka 了。

2.rocketmq

天生為金融網際網路領域而生,對於可靠性要求很高的場景,尤其是電商裡面的訂單扣款,以及業務削峰,在大量交易湧入時,後端可能無法及時處理的情況。 roketmq 在穩定性上可能更值得信賴,這些業務場景在阿里雙 11 已經經歷了多次考驗,如果你的業務有上述併發場景,建議可以選擇 rocketmq。

3.rabbitmq

結合 erlang 語言本身的併發優勢,效能好時效性微秒級社群活躍度也比較高,管理介面用起來十分方便,如果你的資料量沒有那麼大,中小型公司優先選擇功能比較完備的 rabbitmq。

訊息佇列MQ

目錄 一 簡介 二 為什麼需要訊息佇列 mq 三 介紹 訊息佇列 message queuing 在電腦科學中,是一種程序間通訊或同一程序間不同執行緒的通訊方式。廣義上講訊息佇列是解決分布式系統中,各個功能模組間的資訊傳遞通訊方式。與檔案傳輸和rpc相比,訊息佇列具有更好的平台無關性,並能夠很好地支...

MQ訊息佇列

1.解耦 系統a將userid寫到訊息佇列中,系統c和系統d從訊息佇列中拿資料。這樣有什麼好處?系統a只負責把資料寫到佇列中,誰想要或不想要這個資料 訊息 系統a一點都不關心。即便現在系統d不想要userid這個資料了,系統b又突然想要userid這個資料了,都跟系統a無關,系統a一點 都不用改。系...

MQ訊息佇列應用

很榮幸,原來一直聽說的訊息佇列終於在前段時間用到了自己的專案中。為什麼會用到訊息佇列?毫無疑問,當然是傳輸訊息。這裡訊息一般是一串字串,當然,訊息的含義很多,可以是 hello world 可以是 你吃飯了嗎?可以是一串正式的xml報文。也可以是乙個txt檔案或者xml檔案 在用active mq的...