Java常用消息隊列原理介紹及性能對比

消息隊列使用場景 為什么會需要消息隊列(MQ)？

解耦
在項目啟動之初來預測將來項目會碰到什么需求，是極其困難的。消息系統在處理過程中間插入了一個隱含的、基于數據的接口層，兩邊的處理過程都要實現這一接口。這允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。
冗余
有些情況下，處理數據的過程會失敗。除非數據被持久化，否則將造成丟失。消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險。許多消息隊列所采用的”插入-獲取-刪除”范式中，在把一個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。
擴展性
因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調節參數。擴展就像調大電力按鈕一樣簡單。
靈活性 & 峰值處理能力
在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量并不常見；如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵組件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。
可恢復性
系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復后被處理。
順序保證
在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數據會按照特定的順序來處理。Kafka保證一個Partition內的消息的有序性。
緩沖
在任何重要的系統中，都會有需要不同的處理時間的元素。例如，加載一張圖片比應用過濾器花費更少的時間。消息隊列通過一個緩沖層來幫助任務最高效率的執行———寫入隊列的處理會盡可能的快速。該緩沖有助于控制和優化數據流經過系統的速度。
異步通信
很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。

MQ常用的使用場景：
1. 進程間通訊和系統間的消息通知，比如在分布式系統中。
2. 解耦，比如像我們公司有許多開發團隊，每個團隊負責業務的不同模塊，各個開發團隊可以使用MQ來通信。
3. 在一些高并發場景下，使用MQ的異步特性。

消息隊列和RPC對比 系統架構

RPC系統結構：

+----------++----------+|Consumer|<=>|Provider|+----------++----------+

Consumer調用的Provider提供的服務。
Message Queue系統結構：

+--------++-------++----------+|Sender|<=>|Queue|<=>|Receiver|+--------++-------++----------+

Sender發送消息給Queue；Receiver從Queue拿到消息來處理。

功能特點

在架構上，RPC和Message Queue的差異點是，Message Queue有一個中間結點Message Queue(broker)，可以把消息存儲。

消息隊列的特點

Message Queue把請求的壓力保存一下，逐漸釋放出來，讓處理者按照自己的節奏來處理。

Message Queue引入一下新的結點，讓系統的可靠性會受Message Queue結點的影響。

Message Queue是異步單向的消息。發送消息設計成是不需要等待消息處理的完成。

所以對于有同步返回需求，用Message Queue則變得麻煩了。

RPC的特點

同步調用，對于要等待返回結果/處理結果的場景，RPC是可以非常自然直覺的使用方式。RPC也可以是異步調用。

由于等待結果，Consumer（Client）會有線程消耗。