1.mq使用場景

• 非同步通訊
  有些業務不想也不需要立即處理訊息。訊息佇列提供了非同步處理機制，允許使用者把訊息放入佇列，但並不立即處理它。想在佇列中放入多少訊息就放多少，然後在需要的時候再去處理他。

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

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

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

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

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

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

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

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

2.MQ原理

2.1mq模型

1. Pub/Sub釋出訂閱（廣播）：使用topic作為通訊載體
   

2. PTP點對點:使用queue作為通訊載體
   

2.2 mq的組成

• Broker：訊息伺服器，作為server提供訊息核心服務

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

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

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

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

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

2.3 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的功能。

2.4 MQ選型

• RabbitMQ
  使用Erlang編寫的一個開源的訊息佇列，本身支援很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。同時實現了Broker架構，核心思想是生產者不會將訊息直接傳送給佇列，訊息在傳送給客戶端時先在中心佇列排隊。對路由(Routing)，負載均衡(Load balance)、資料持久化都有很好的支援。多用於進行企業級的ESB整合。

• ZeroMQ
  又稱ØMQ、0MQ、ZMQ，號稱最快的訊息佇列系統，專門為高吞吐量、低延遲的場景開發，在金融界的應用中經常使用，偏重於實時資料通訊場景。ZMQ能夠實現RabbitMQ不擅長的高階/複雜的佇列，但是開發人員需要自己組合多種技術框架，開發成本高。因此ZeroMQ具有一個獨特的非中介軟體的模式，更像一個socket library，你不需要安裝和執行一個訊息伺服器或中介軟體，因為你的應用程式本身就是使用ZeroMQ API完成邏輯服務的角色。但是ZeroMQ僅提供非永續性的佇列，如果down機，資料將會丟失。如：Twitter的Storm中使用ZeroMQ作為資料流的傳輸。 ZeroMQ套接字是與傳輸層無關的：ZeroMQ套接字對所有傳輸層協議定義了統一的API介面。預設支援 程序內(inproc) ，程序間(IPC) ，多播 ，TCP協議，在不同的協議之間切換隻要簡單的改變連線字串的字首。可以在任何時候以最小的代價從程序間的本地通訊切換到分散式下的TCP通訊。ZeroMQ在背後處理連線建立，斷開和重連邏輯。
  特性：

  • 無鎖的佇列模型
    對於跨執行緒間的互動（使用者端和session）之間的資料交換通道pipe，採用無鎖的佇列演算法CAS；在pipe的兩端註冊有非同步事件，在讀或者寫訊息到pipe的時，會自動觸發讀寫事件。

  • 批量處理的演算法
    對於批量的訊息，進行了適應性的優化，可以批量的接收和傳送訊息。

  • 多核下的執行緒繫結，無須CPU切換
    區別於傳統的多執行緒併發模式，訊號量或者臨界區， zeroMQ充分利用多核的優勢，每個核繫結執行一個工作者執行緒，避免多執行緒之間的CPU切換開銷。

• ActiveMQ
  Apache下的一個子專案。使用Java完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現，少量程式碼就可以高效地實現高階應用場景。可插拔的傳輸協議支援，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支援常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。

• Redis
  使用C語言開發的一個Key-Value的NoSQL資料庫，開發維護很活躍，雖然它是一個Key-Value資料庫儲存系統，但它本身支援MQ功能，所以完全可以當做一個輕量級的佇列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試資料分為128Bytes、512Bytes、1K和10K四個不同大小的資料。實驗表明：入隊時，當資料比較小時Redis的效能要高於RabbitMQ，而如果資料大小超過了10K，Redis則慢的無法忍受；出隊時，無論資料大小，Redis都表現出非常好的效能，而RabbitMQ的出隊效能則遠低於Redis。

• Kafka
  Apache下的一個子專案，使用scala實現的一個高效能分散式Publish/Subscribe訊息佇列系統，具有以下特性： 快速持久化：通過磁碟順序讀寫與零拷貝機制，可以在O(1)的系統開銷下進行訊息持久化；
  高吞吐：在一臺普通的伺服器上既可以達到10W/s的吞吐速率；
  高堆積：支援topic下消費者較長時間離線，訊息堆積量大；
  完全的分散式系統：Broker、Producer、Consumer都原生自動支援分散式，依賴zookeeper自動實現複雜均衡；
  支援Hadoop資料並行載入：對於像Hadoop的一樣的日誌資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。

• 推薦一個交流學習群：478030634 裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

• 
  

2.4MQ對比

2.4.1使用場景建議