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

消息隊列已經逐漸成為企業IT系統内部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一緻性等一系列功能，成為異步RPC的主要手段之一。

當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿裡巴巴自主開發的Notify、MetaQ、RocketMQ等。

本文主要探讨主流的消息隊列MQ比較，特征，以及典型使用場景。

目前主流的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.如果下遊有很多系統關心你的系統發出的通知的時候，果斷地使用消息隊列吧。

以上是消息隊列的講解，

以下是架構進階資料，需要學習免費課程的狂戳

。