經常使用MQ及其原理

mq爲了解決什麼問題？
一、異步通訊
   有些業務不想也不須要當即處理消息。消息隊列提供了異步處理機制，容許用戶把一個消息放入隊列，但並不當即處理它。想向隊列中放入多少消息就放多少，而後在須要的時候再去處理它們。

 

二、解耦
   下降工程間的強依賴程度，針對異構系統進行適配。在項目啓動之初來預測未來項目會碰到什麼需求，是極其困難的。經過消息系統在處理過程當中間插入了一個隱含的、基於數據的接口層，兩邊的處理過程都要實現這一接口，當應用發生變化時，能夠獨立的擴展或修改兩邊的處理過程，只要確保它們遵照一樣的接口約束

 

3冗餘
   有些狀況下，處理數據的過程會失敗。除非數據被持久化，不然將形成丟失。消息隊列把數據進行持久化直到它們已經被徹底處理，經過這一方式規避了數據丟失風險。許多消息隊列所採用的"插入-獲取-刪除"範式中，在把一個消息從隊列中刪除以前，須要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。

四、擴展性
 

   由於消息隊列解耦了你的處理過程，因此增大消息入隊和處理的頻率是很容易的，只要另外增長處理過程便可。不須要改變代碼、不須要調節參數。便於分佈式擴容

 

五、過載保護
   在訪問量劇增的狀況下，應用仍然須要繼續發揮做用，可是這樣的突發流量沒法提取預知；若是覺得了能處理這類瞬間峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列可以使關鍵組件頂住突發的訪問壓力，而不會由於突發的超負荷的請求而徹底崩潰

 

六、可恢復性
   系統的一部分組件失效時，不會影響到整個系統。消息隊列下降了進程間的耦合度，因此即便一個處理消息的進程掛掉，加入隊列中的消息仍然能夠在系統恢復後被處理。

 

七、順序保證
   在大多使用場景下，數據處理的順序都很重要。大部分消息隊列原本就是排序的，而且能保證數據會按照特定的順序來處理。

 

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

 

9數據流處理
分佈式系統產生的海量數據流，如：業務日誌、監控數據、用戶行爲等，針對這些數據流進行實時或批量採集彙總，而後進行大數據分析是當前互聯網的必備技術，經過消息隊列完成此類數據收集是最好的選擇

Mq原理
一、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)通道與其它成員通信，從而大大簡化了系統配置。此外，羣集中的隊列管理器之間可以自動進行負載均衡，當某一隊列管理器出現故障時，其它隊列管理器能夠接管它的工做，從而大大提升系統的高可靠性

 

二、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