mq為了解決什麼問題？
1、非同步通訊
   有些業務不想也不需要立即處理訊息。訊息佇列提供了非同步處理機制，允許使用者把一個訊息放入佇列，但並不立即處理它。想向佇列中放入多少訊息就放多少，然後在需要的時候再去處理它們。

2、解耦
   降低工程間的強依賴程度，針對異構系統進行適配。在專案啟動之初來預測將來專案會碰到什麼需求，是極其困難的。通過訊息系統在處理過程中間插入了一個隱含的、基於資料的介面層，兩邊的處理過程都要實現這一介面，當應用發生變化時，可以獨立的擴充套件或修改兩邊的處理過程，只要確保它們遵守同樣的介面約束

3冗餘
   有些情況下，處理資料的過程會失敗。除非資料被持久化，否則將造成丟失。訊息佇列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丟失風險。許多訊息佇列所採用的"插入-獲取-刪除"正規化中，在把一個訊息從佇列中刪除之前，需要你的處理系統明確的指出該訊息已經被處理完畢，從而確保你的資料被安全的儲存直到你使用完畢。

4、擴充套件性

因為訊息佇列解耦了你的處理過程，所以增大訊息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變程式碼、不需要調節引數。便於分散式擴容

5、過載保護
   在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量無法提取預知；如果以為了能處理這類瞬間峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用訊息佇列能夠使關鍵元件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰

6、可恢復性
   系統的一部分元件失效時，不會影響到整個系統。訊息佇列降低了程序間的耦合度，所以即使一個處理訊息的程序掛掉，加入佇列中的訊息仍然可以在系統恢復後被處理。

7、順序保證
   在大多使用場景下，資料處理的順序都很重要。大部分訊息佇列本來就是排序的，並且能保證資料會按照特定的順序來處理。

8、緩衝
   在任何重要的系統中，都會有需要不同的處理時間的元素。訊息佇列通過一個緩衝層來幫助任務最高效率的執行，該緩衝有助於控制和優化資料流經過系統的速度。以調節系統響應時間。

9資料流處理
分散式系統產生的海量資料流，如：業務日誌、監控資料、使用者行為等，針對這些資料流進行實時或批量採集彙總，然後進行大資料分析是當前網際網路的必備技術，通過訊息佇列完成此類資料收集是最好的選擇

Mq原理
1、MQ原型

1)MQ原型-Pub/Sub釋出訂閱
（廣播：生產者-消費之1對多）：使用topic作為通訊載體

希望傳送的訊息可以不被做任何處理、或者只被一個訊息者處理、或者可以被多個消費者處理的話，那麼可以採用Pub/Sub模型。

MQ原型-PTP點對點
:使用queue作為通訊載體

如果希望傳送的每個訊息都會被成功處理的話，那麼需要P2P模式。

MQ原型-多點廣播：
MQ適用於不同型別的應用。其中重要的，也是正在發展中的是"多點廣播"應用，即能夠將訊息傳送到多個目標站點(Destination List)。可以使用一條MQ指令將單一訊息傳送到多個目標站點，並確保為每一站點可靠地提供資訊。MQ不僅提供了多點廣播的功能，而且還擁有智慧訊息分發功能，在將一條訊息傳送到同一系統上的多個使用者時，MQ將訊息的一個複製版本和該系統上接收者的名單傳送到目標MQ系統。目標MQ系統在本地複製這些訊息，並將它們傳送到名單上的佇列，從而儘可能減少網路的傳輸量。

MQ原型-群集(Cluster)：
為了簡化點對點通訊模式中的系統配置，MQ提供Cluster(群集)的解決方案。群集類似於一個域(Domain)，群集內部的佇列管理器之間通訊時，不需要兩兩之間建立訊息通道，而是採用群集(Cluster)通道與其它成員通訊，從而大大簡化了系統配置。此外，群集中的佇列管理器之間能夠自動進行負載均衡，當某一佇列管理器出現故障時，其它佇列管理器可以接管它的工作，從而大大提高系統的高可靠性

2、MQ組成結構
   Broker：訊息伺服器，作為server提供訊息核心服務

Producer:訊息生產者，業務的發起方，負責生產訊息傳輸給broker，

Consumer：訊息消費者，業務的處理方，負責從broker獲取訊息並進行業務邏輯處理

Topic:主題，釋出訂閱模式下的訊息統一彙集地，不同生產者向topic傳送訊息，由MQ伺服器分發到不同的訂閱 者，實現訊息的廣播

Queue：佇列，PTP模式下，特定生產者向特定queue傳送訊息，消費者訂閱特定的queue完成指定訊息的接收

Message：訊息體，根據不同通訊協議定義的固定格式進行編碼的資料包，來封裝業務資料，實現訊息的傳輸

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編碼格式佔用頻寬大

RabbitMq與kafaka選型比較
https://blog.csdn.net/yifansj/article/details/79248586

架構方面：
Kafaka是正常的mq架構，包括provider broker consumer。，kafaka沒有訊息確認機制

rabbitMq 中的broker由exchange、binder queue三部分組成，其中exchange和binding組成了訊息的路由鍵；客戶端Producer通過連線channel和server進行通訊，Consumer從queue獲取訊息進行消費，rabbit有訊息確認機制

吞吐量方面：
Kafaka採用zero-copy方式，即資料儲存和獲取是本地磁碟順序批量操作，具有O（1）複雜度，資料處理效率很高

RabbitMq在吞吐量方面不如kafaka，RabbitMq支援對訊息可靠的傳遞，支援事務，不支援批量的操作。

可用性方面
Kafaka的broker採用主備模式，所以可用性很高

RabbitMq支援miror queue，主queue失效，minor queue生效

叢集負載方面
Kafaka使用zookeeper實現負載均衡，zookeeper管理叢集中的broker sonsumer，通過zookeeper的協調機制，producer會記錄topic對應的broker，對broker進行輪詢或者隨機訪問broker，實現負載均衡

RabbitMq需要單獨自定義負載均衡

一般推薦使用mq，例如RabbitMq，activeMq等，已經比較成熟和穩定了，效能也一般，一般推薦使用這些。Redies適用於在記憶體中儲存資料庫，作為訊息佇列可靠性較差，而且依賴於網路IO;kafaka設計的初衷是日誌統計分析，現在也可以配合zookeeper用於訊息

https://blog.csdn.net/h2604396739/article/details/81136527