主流的消息隊列MQ比較，詳解MQ的4類應用場景

目前主流的MQ產品

1.ZeroMQ

號稱最快的消息隊列系統，尤爲針對大吞吐量的需求場景。

擴展性好，開發比較靈活，採用C語言實現，實際上只是一個socket庫的從新封裝，若是作爲消息隊列使用，須要開發大量的代碼。ZeroMQ僅提供非持久性的隊列，也就是說若是down機，數據將會丟失。其中，Twitter的Storm中使用ZeroMQ做爲數據流的傳輸。

2.RabbitMQ

結合erlang語言自己的併發優點，支持不少的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的很是重量級，更適合於企業級的開發。

性能較好，可是不利於作二次開發和維護。

3.ActiveMQ

歷史悠久的開源項目，是Apache下的一個子項目。已經在不少產品中獲得應用，實現了JMS1.1規範，能夠和spring-jms輕鬆融合，實現了多種協議，不夠輕巧（源代碼比RocketMQ多），支持持久化到數據庫，對隊列數較多的狀況支持很差。

4.Redis

作爲一個基於內存的K-V數據庫，其提供了消息訂閱的服務，能夠看成MQ來使用，目前應用案例較少，且不方便擴展。對於RabbitMQ和Redis的入隊和出隊操做，各執行100萬次，每10萬次記錄一次執行時間。

測試數據分爲 128Bytes、512Bytes、1K和10K四個不一樣大小的數據。

實驗代表：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如 果數據大小超過了10K，Redis則慢的沒法忍受；出隊時，不管數據大小，Redis都表現出很是好的性能，而RabbitMQ的出隊性能則遠低於 Redis。

5.Kafka/Jafka

Kafka是Apache下的一個子項目，是一個高性能跨語言分佈式發佈/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。

具備如下特性：

• 快速持久化，能夠在O(1)的系統開銷下進行消息持久化；
• 高吞吐，在一臺普通的服務器上既能夠達到10W/s的吞吐速率；徹底的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現負載均衡；
• 支持Hadoop數據並行加載，對於像Hadoop的同樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。
• Kafka經過Hadoop的並行加載機制統一了在線和離線的消息處理。Apache Kafka相對於ActiveMQ是一個很是輕量級的消息系統，除了性能很是好以外，仍是一個工做良好的分佈式系統。

什麼時候須要消息隊列

當你須要使用消息隊列時，首先須要考慮它的必要性。

可使用mq的場景有不少，最經常使用的幾種:

• 作業務解耦
• 最終一致性
• 廣播
• 錯峯流控等

反之，若是須要強一致性，關注業務邏輯的處理結果，則RPC顯得更爲合適。

消息隊列使用場景

1.解耦

解耦是消息隊列要解決的最本質問題。所謂解耦，簡單點講就是一個事務，只關心核心的流程。而須要依賴其餘系統但不那麼重要的事情，有通知便可，無需等待結果。換句話說，基於消息的模型，關心的是「通知」，而非「處理」。

舉一個例子，關於訂單系統，訂單最終支付成功以後可能須要給用戶發送短信積分什麼的，但其實這已經不是咱們系統的核心流程了。

若是外部系統速度偏慢（好比短信網關速度很差），那麼主流程的時間會加長不少，用戶確定不但願點擊支付過好幾分鐘纔看到結果。那麼咱們只須要通知短信系統「咱們支付成功了」，不必定非要等待它當即處理完成。

2.最終一致性

最終一致性指的是兩個系統的狀態保持一致，要麼都成功，要麼都失敗。

固然有個時間限制，理論上越快越好，但實際上在各類異常的狀況下，可能會有必定延遲達到最終一致狀態，但最後兩個系統的狀態是同樣的。

業界有一些爲「最終一致性」而生的消息隊列，如：

• Notify（阿里）
• QMQ（去哪兒）等

其設計初衷，就是爲了交易系統中的高可靠通知。

以一個銀行的轉帳過程來理解最終一致性，轉帳的需求很簡單，若是A系統扣錢成功，則B系統加錢必定成功。反之則一塊兒回滾，像什麼都沒發生同樣。

然而，這個過程當中存在不少可能的意外：

• A扣錢成功，調用B加錢接口失敗。
• A扣錢成功，調用B加錢接口雖然成功，但獲取最終結果時網絡異常引發超時。
• A扣錢成功，B加錢失敗，A想回滾扣的錢，但A機器down機。

可見，想把這件看似簡單的事真正作成，真的不那麼容易。

全部跨VM的一致性問題，從技術的角度講通用的解決方案是：

• 強一致性，分佈式事務，但落地太難且成本過高，後文會具體提到。
• 最終一致性，主要是用「記錄」和「補償」的方式。在作全部的不肯定的事情以前，先把事情記錄下來，而後去作不肯定的事情，結果多是：成功、失敗或是不肯定，「不肯定」（例如超時等）能夠等價爲失敗。成功就能夠把記錄的東西清理掉了，對於失敗和不肯定，能夠依靠定時任務等方式把全部失敗的事情從新搞一遍，直到成功爲止。
• 回到剛纔的例子，系統在A扣錢成功的狀況下，把要給B「通知」這件事記錄在庫裏（爲了保證最高的可靠性能夠把通知B系統加錢和扣錢成功這兩件事維護在一個本地事務裏），通知成功則刪除這條記錄，通知失敗或不肯定則依靠定時任務補償性地通知咱們，直到咱們把狀態更新成正確的爲止。
• 整個這個模型依然能夠基於RPC來作，但能夠抽象成一個統一的模型，基於消息隊列來作一個「企業總線」。
• 具體來講，本地事務維護業務變化和通知消息，一塊兒落地（失敗則一塊兒回滾），而後RPC到達broker，在broker成功落地後，RPC返回成功，本地消息能夠刪除。不然本地消息一直靠定時任務輪詢不斷重發，這樣就保證了消息可靠落地broker。
• broker往consumer發送消息的過程相似，一直髮送消息，直到consumer發送消費成功確認。
• 咱們先不理會重複消息的問題，經過兩次消息落地加補償，下游是必定能夠收到消息的。而後依賴狀態機版本號等方式作判重，更新本身的業務，就實現了最終一致性。

最終一致性不是消息隊列的必備特性，但確實能夠依靠消息隊列來作最終一致性的事情。

另外，全部不保證100%不丟消息的消息隊列，理論上沒法實現最終一致性。好吧，應該說理論上的100%，排除系統嚴重故障和bug。

像Kafka一類的設計，在設計層面上就有丟消息的可能（好比定時刷盤，若是掉電就會丟消息）。哪怕只丟千分之一的消息，業務也必須用其餘的手段來保證結果正確。

2.廣播

消息隊列的基本功能之一是進行廣播。

若是沒有消息隊列，每當一個新的業務方接入，咱們都要聯調一次新接口。有了消息隊列，咱們只須要關心消息是否送達了隊列，至於誰但願訂閱，是下游的事情，無疑極大地減小了開發和聯調的工做量。

好比本文開始提到的產品中心發佈產品變動的消息，以及景點庫不少去重更新的消息，可能「關心」方有不少個，但產品中心和景點庫只須要發佈變動消息便可，誰關心誰接入。

3.錯峯與流控

試想上下游對於事情的處理能力是不一樣的。

好比，Web前端每秒承受上千萬的請求，並非什麼神奇的事情，只須要加多一點機器，再搭建一些LVS負載均衡設備和Nginx等便可。

但數據庫的處理能力卻十分有限，即便使用SSD加分庫分表，單機的處理能力仍然在萬級。因爲成本的考慮，咱們不能奢求數據庫的機器數量追上前端。

這種問題一樣存在於系統和系統之間，如短信系統可能因爲短板效應，速度卡在網關上（每秒幾百次請求），跟前端的併發量不是一個數量級。

但用戶晚上個半分鐘左右收到短信，通常是不會有太大問題的。若是沒有消息隊列，兩個系統之間經過協商、滑動窗口等複雜的方案也不是說不能實現。

但系統複雜性指數級增加，勢必在上游或者下游作存儲，而且要處理定時、擁塞等一系列問題。並且每當有處理能力有差距的時候，都須要單獨開發一套邏輯來維護這套邏輯。因此，利用中間系統轉儲兩個系統的通訊內容，並在下游系統有能力處理這些消息的時候，再處理這些消息，是一套相對較通用的方式。

消息隊列使用總結

1.消息隊列不是萬能的，對於須要強事務保證並且延遲敏感的，RPC是優於消息隊列的。

2.對於一些無關痛癢，或者對於別人很是重要可是對於本身不是那麼關心的事情，能夠利用消息隊列去作。

3.支持最終一致性的消息隊列，可以用來處理延遲不那麼敏感的「分佈式事務」場景，並且相對於笨重的分佈式事務，多是更優的處理方式。

4.當上下游系統處理能力存在差距的時候，利用消息隊列作一個通用的「漏斗」，在下游有能力處理的時候，再進行分發。

5.若是下游有不少系統關心你的系統發出的通知的時候，果斷地使用消息隊列吧。

本文由博客一文多發平臺 OpenWrite 發佈！