mq是一個消息隊列,其主要目的是為了解決傳統的消息傳輸上管理困難,效率不高的問題。mq有三大優點:解耦,異步,削峰。
解耦: 如果是傳統的消息通訊方式,無論是哪一方都要去維護一份供外部通訊的這個一個接口,而且各方處理消息的能力有限,效率上明顯跟不上,并且這樣子二者之間的耦合度非常高,對于拓展管理方面極不友好,而是要了mq就不一樣,發送方只需要將消息發送給mq就可以了,別的不用考慮,接口什么的由mq去維護,接收方也只需要去mq里消費消息就可以了,就需要其他開銷,一切由mq中間件來做,達到了解耦操作.
異步: 使用mq,還可以達到異步效果,極大地提升了消息傳輸的效率.發送方在發送消息后不需要關心消費方是否能消費完成,還可以繼續發送其他消息.
削峰:如果是傳統的消息通訊,一下子有大量的消息發送給接收方,這樣對于接收方的處理壓力是很大的,而我們剛好可以利用mq達到一個緩沖操作,一旦流量超出了接收方處理范圍,不用擔心,只需要慢慢消費即可,像經典的雙十一,就很容易會使用到mq這么一個優點.
mq缺點:因為增加了中間件,系統復雜度肯定大大提高,增加了很多維護的成本,比如我們要保證消息不丟失(一致性)和消息冪等性問題,還要保證mq的高可用等。
1)異步處理 - 相比于傳統的串行、并行方式，提高了系統吞吐量。
2)應用解耦 - 系統間通過消息通信，不用關心其他系統的處理。
3)流量削鋒 - 可以通過消息隊列長度控制請求量；可以緩解短時間內的高并發請求。
4)日志處理 - 解決大量日志傳輸。
5)消息通訊 - 消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。
1)系統可用性降低:本來系統運行好好的，現在你非要加入個消息隊列進去，那消息隊列掛了，你的系統不是呵呵了。因此，系統可用性會降低；
2)系統復雜度提高:加入了消息隊列，要多考慮很多方面的問題，比如：一致性問題、如何保證消息不被重復消費、如何保證消息可靠性傳輸等。因此，需要考慮的東西更多，復雜性增大。
3)一致性問題:A系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三個系統那里，BD兩個系統寫庫成功了，結果C系統寫庫失敗了，咋整？你這數據就不一致了。
所以消息隊列實際是一種非常復雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉。
解耦：以電商應用為例，應用中有訂單系統、庫存系統、物流系統、支付系統。用戶創建訂單后，如果耦合調用庫存系統、物流系統、支付系統，任何一個子系統出了故障,都會造成下單操作異常。使用mq后，訂單系統和其余系統完成解耦，不必擔心其他系統出現故障，當轉變成基于消息隊列的方式后，系統間調用的問題會減少很多,比如物流系統因為發生故障,需要幾分鐘來修復。在這幾分鐘的時間里，物流系統要處理的內存被緩存在消息隊列中，用戶的下單操作可以正常完成。當物流系統恢復后，繼續處理訂單信息即可，中單用戶感受不到物流系統的故障,提升系統的可用性。
異步：有些服務間的調用并不是同步的，而是異步執行，例如，A調用B，B需要花費很長時間執行，此時A需要知道B什么時間可以執行完成，在未使用MQ時，一般會有兩種方法實現，1.A不斷地輪詢查看B是否完成。2、就是A提供一個調用接口，當B執行完成之后，調用A的回調接口，以此實現。
當然MQ的出現很好的解決這個問題，A調用B后，只需要監聽B處理完成消息，當B處理完后，會發送一條消息給MQ，MQ會將此消息轉發給A服務。這樣就省去了A的輪詢或者B對A的回調。A也能夠即使得到異步處理消息。
削峰：比如說，如果訂單系統最多能處理一萬次訂單，這個處理能力應付正常時段的下單時是沒有問題的，正常時段我們下單一秒后就能返回結果。但是在高峰期，如果有兩萬次下單操作系統是處理不了的，只能限制訂單超過一萬后不允許用戶下單。使用MQ做緩沖，我們可以取消這個限制，把一秒內下的訂單分散成一段時間來處理，這時有些用戶可能在下單十幾秒后才能收到下單成功，雖然這樣會影響一定的體驗，但是要比不能下單好的多。
AMQP協議 AMQP即Advanced Message Queuing Protocol,一個提供統一消息服務的應用層標準高級消息隊列協議,是應用層協議的一個開放標準,為面向消息的中間件設計。基于此協議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產品，不同開發語言等條件的限制。
優點：可靠、通用
MQTT協議 MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發的一個即時通訊協議，有可能成為物聯網的重要組成部分。該協議支持所有平臺，幾乎可以把所有聯網物品和外部連接起來，被用來當做傳感器和致動器（比如通過Twitter讓房屋聯網）的通信協議。
優點：格式簡潔、占用帶寬小、移動端通信、PUSH、嵌入式系統
STOMP協議 STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協議，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協議。STOMP提供一個可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進行交互。
優點：命令模式（非topic/queue模式）
XMPP協議 XMPP（可擴展消息處理現場協議，Extensible Messaging and Presence Protocol）是基于可擴展標記語言（XML）的協議，多用于即時消息（IM）以及在線現場探測。適用于服務器之間的準即時操作。核心是基于XML流傳輸，這個協議可能最終允許因特網用戶向因特網上的其他任何人發送即時消息，即使其操作系統和瀏覽器不同。
優點：通用公開、兼容性強、可擴展、安全性高，但XML編碼格式占用帶寬大
其他基于TCP/IP自定義的協議：有些特殊框架（如：redis、kafka、zeroMq等）根據自身需要未嚴格遵循MQ規范，而是基于TCP\IP自行封裝了一套協議，通過網絡socket接口進行傳輸，實現了MQ的功能。
1)點對點通訊：點對點方式是最為傳統和常見的通訊方式，它支持一對一、一對多、多對多、多對一等多種配置方式，支持樹狀、網狀等多種拓撲結構。
2)多點廣播：MQ適用于不同類型的應用。其中重要的，也是正在發展中的是"多點廣播"應用，即能夠將消息發送到多個目標站點(Destination List)。可以使用一條MQ指令將單一消息發送到多個目標站點，并確保為每一站點可靠地提供信息。MQ不僅提供了多點廣播的功能，而且還擁有智能消息分發功能，在將一條消息發送到同一系統上的多個用戶時，MQ將消息的一個復制版本和該系統上接收者的名單發送到目標MQ系統。目標MQ系統在本地復制這些消息，并將它們發送到名單上的隊列，從而盡可能減少網絡的傳輸量。
3)發布/訂閱(Publish/Subscribe)模式：發布/訂閱功能使消息的分發可以突破目的隊列地理指向的限制，使消息按照特定的主題甚至內容進行分發，用戶或應用程序可以根據主題或內容接收到所需要的消息。發布/訂閱功能使得發送者和接收者之間的耦合關系變得更為松散，發送者不必關心接收者的目的地址，而接收者也不必關心消息的發送地址，而只是根據消息的主題進行消息的收發。在MQ家族產品中，MQ Event Broker是專門用于使用發布/訂閱技術進行數據通訊的產品，它支持基于隊列和直接基于TCP/IP兩種方式的發布和訂閱。
4)集群(Cluster)：為了簡化點對點通訊模式中的系統配置，MQ提供 Cluster 的解決方案。集群類似于一個 域(Domain) ，集群內部的隊列管理器之間通訊時，不需要兩兩之間建立消息通道，而是采用 Cluster 通道與其它成員通訊，從而大大簡化了系統配置。此外，集群中的隊列管理器之間能夠自動進行負載均衡，當某一隊列管理器出現故障時，其它隊列管理器可以接管它的工作，從而大大提高系統的高可靠性;
在消息生產時，MQ內部針對每條生產者發送的消息生成一個唯一id，作為去重和冪等的依據（消息投遞失敗并重傳），避免重復的消息進入隊列。
在消息消費時，要求消息體中也要有一全局唯一id作為去重和冪等的依據，避免同一條消息被重復消費。
一般這個時候，只能臨時緊急擴容了，具體操作步驟和思路如下：
1)先修復 consumer 的問題，確保其恢復消費速度，然后將現有 consumer 都停掉；
2)新建一個 topic，partition 是原來的 10 倍，臨時建立好原先 10 倍的 queue 數量；
3)然后寫一個臨時的分發數據的 consumer 程序，這個程序部署上去消費積壓的數據，消費之后不做耗時的處理，直接均勻輪詢寫入臨時建立好的 10 倍數量的queue；
4)接著臨時用 10 倍的機器來部署 consumer，每一批 consumer 消費一個臨時 queue 的數據。這種做法相當于是臨時將 queue 資源和 consumer 資源擴大10倍，以正常的 10 倍速度來消費數據；
5)等快速消費完積壓數據之后，得恢復原先部署的架構，重新用原先的 consumer 機器來消費消息。
綜上，各種對比之后，有如下建議：
一般的業務系統要引入MQ，最早大家都用ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
后來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的Java工程師去深入研究和掌控它，對公司而言，幾乎處于不可控的狀態，但是確實人家是開源的，比較穩定的支持，活躍度也高；
不過現在確實越來越多的公司會去用RocketMQ，確實很不錯，畢竟是阿里出品，但社區可能有突然黃掉的風險（目前 RocketMQ已捐給Apache，但GitHub上的活躍度其實不算高）對自己公司技術實力有絕對自信的，推薦用RocketMQ，否則回去老老實實用RabbitMQ 吧，人家有活躍的開源社區，絕對不會黃。
所以中小型公司，技術實力較為一般，技術挑戰不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用 RocketMQ是很好的選擇。如果是大數據領域的實時計算、日志采集等場景，用Kafka是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規范。
這個首先你可以說下你們公司選用的是什么消息中間件，比如用的是RabbitMQ，然后可以初步給一些你對不同MQ中間件技術的選型分析。舉個例子：比如說ActiveMQ是老牌的消息中間件，國內很多公司過去運用的還是非常廣泛的，功能很強大。但是問題在于沒法確認ActiveMQ可以支撐互聯網公司的高并發、高負載以及高吞吐的復雜場景，在國內互聯網公司落地較少。而且使用較多的是一些傳統企業，用ActiveMQ做異步調用和系統解耦。
然后你可以說說RabbitMQ，他的好處在于可以支撐高并發、高吞吐、性能很高，同時有非常完善便捷的后臺管理界面可以使用。另外，他還支持集群化、高可用部署架構、消息高可靠支持，功能較為完善。而且經過調研，國內各大互聯網公司落地大規模RabbitMQ集群支撐自身業務的case較多，國內各種中小型互聯網公司使用RabbitMQ的實踐也比較多。除此之外，RabbitMQ的開源社區很活躍，較高頻率的迭代版本，來修復發現的bug以及進行各種優化，因此綜合考慮過后，公司采取了RabbitMQ。但是RabbitMQ也有一點缺陷，就是他自身是基于erlang語言開發的，所以導致較為難以分析里面的源碼，也較難進行深層次的源碼定制和改造，畢竟需要較為扎實的erlang語言功底才可以。
然后可以聊聊RocketMQ，是阿里開源的，經過阿里的生產環境的超高并發、高吞吐的考驗，性能卓越，同時還支持分布式事務等特殊場景。而且RocketMQ是基于Java語言開發的，適合深入閱讀源碼，有需要可以站在源碼層面解決線上生產問題，包括源碼的二次開發和改造。
另外就是Kafka。Kafka提供的消息中間件的功能明顯較少一些，相對上述幾款MQ中間件要少很多。但是Kafka的優勢在于專為超高吞吐量的實時日志采集、實時數據同步、實時數據計算等場景來設計。因此Kafka在大數據領域中配合實時計算技術（比如Spark Streaming、Storm、Flink）使用的較多。但是在傳統的MQ中間件使用場景中較少采用。
官方微信
官方抖音
京公網安備 11030102010736號