消息隊列入門(一)

消息隊列（英語：Message queue）是一種進程間通訊或同一進程的不一樣線程間的通訊方式，軟件的貯列用來處理一系列的輸入，一般是來自用戶。消息隊列提供了異步的通訊協議，每個貯列中的紀錄包含詳細說明的數據，包含發生的時間，輸入設備的種類，以及特定的輸入參數，也就是說：消息的發送者和接收者不須要同時與消息隊列互交。消息會保存在隊列中，直到接收者取回它。

組成

Broker：消息服務器，做爲server提供消息核心服務
Producer:消息生產者，業務的發起方，負責生產消息傳輸給broker，
Consumer：消息消費者，業務的處理方，負責從broker獲取消息並進行業務邏輯處理
Topic:主題，發佈訂閱模式下的消息統一聚集地，不一樣生產者向topic發送消息，由MQ服務器分發到不一樣的訂閱者，實現消息的廣播
Queue：隊列，PTP模式下，特定生產者向特定queue發送消息，消費者訂閱特定的queue完成指定消息的接收
Message：消息體，根據不一樣通訊協議定義的固定格式進行編碼的數據包，來封裝業務數據，實現消息的傳輸

使用場景

異步通訊

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

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

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

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

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

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

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

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

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

框架比較

MQ	語言	支持協議	持久化策略	消息確認機制
RabbitMQ	Erlang	AMQP STOMP (STOMP 1.0, STOMP 1.1 and STOMP 1.2)MQTTHTTP(有三種方式)	本地磁盤文件	有消息確認機制
ActiveMQ	Java	AMQPMQTTOpenWireSTOMP	AMQ(磁盤文件)、KahaDB(本地數據庫)、JDBC、LevelDB(本地數據庫)	AUTO_ACKNOWLEDGE = 1 自動確認CLIENT_ACKNOWLEDGE = 2 客戶端手動確認 DUPS_OK_ACKNOWLEDGE = 3 自動批量確認SESSION_TRANSACTED = 0 事務提交併確認自定義的ACK_MODE:INDIVIDUAL_ACKNOWLEDGE = 4 單條消息確認
ZeroMQ	C/C++	zmq_ipc(本地進程間通訊)基於Socket的通訊協議：TCP、INROC 、IPC 、PGM	不支持持久化	無，相似NIO的非阻塞事件
Redis	C	自定義redis協議	支持磁盤持久化	無
Kafka	scala	自定義	磁盤持久化	有消息確認機制