消息隊列的相關知識

時間 2019-11-11

標籤消息隊列相關知識简体版

原文原文鏈接

消息隊列中間件是分佈式系統中重要的組件，主要解決應用解耦，異步消息，流量削鋒等問題，實現高性能，高可用，可伸縮和最終一致性架構。目前使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。消息中間件到底該如何使用，什麼時候使用這是一個問題，胡亂地使用消息中間件增長了系統的複雜度，若是用很差消息中間件還不如不用。
php

0.消息隊列通信模式

1)點對點通信：點對點方式是最爲傳統和常見的通信方式，它支持一對1、一對多、多對多、多對一等多種配置方式，支持樹狀、網狀等多種拓撲結構。

2)多點廣播：MQ適用於不一樣類型的應用。其中重要的，也是正在發展中的是"多點廣播"應用，即可以將消息發送到多個目標站點(DestinationList)。可使用一條MQ指令將單一消息發送到多個目標站點，並確保爲每一站點可靠地提供信息。MQ不只提供了多點廣播的功能，並且還擁有智能消息分發功能，在將一條消息發送到同一系統上的多個用戶時，MQ將消息的一個複製版本和該系統上接收者的名單發送到目標MQ系統。目標MQ系統在本地複製這些消息，並將它們發送到名單上的隊列，從而儘量減小網絡的傳輸量。

3)發佈/訂閱(Publish/Subscribe)模式：發佈/訂閱功能使消息的分發能夠突破目的隊列地理指向的限制，使消息按照特定的主題甚至內容進行分發，用戶或應用程序能夠根據主題或內容接收到所須要的消息。發佈/訂閱功能使得發送者和接收者之間的耦合關係變得更爲鬆散，發送者沒必要關心接收者的目的地址，而接收者也沒必要關心消息的發送地址，而只是根據消息的主題進行消息的收發。在MQ家族產品中，MQEventBroker是專門用於使用發佈/訂閱技術進行數據通信的產品，它支持基於隊列和直接基於TCP/IP兩種方式的發佈和訂閱。

4)羣集(Cluster)：爲了簡化點對點通信模式中的系統配置，MQ提供Cluster(羣集)的解決方案。羣集相似於一個域(Domain)，羣集內部的隊列管理器之間通信時，不須要兩兩之間創建消息通道，而是採用羣集(Cluster)通道與其它成員通信，從而大大簡化了系統配置。此外，羣集中的隊列管理器之間可以自動進行負載均衡，當某一隊列管理器出現故障時，其它隊列管理器能夠接管它的工做，從而大大提升系統的高可靠性。
html

1.使用消息隊列的理由

過去幾年中，咱們一直在使用、構建和宣傳消息隊列，咱們認爲它們是很使人敬畏的，這也不是什麼祕密。咱們相信對任何架構或應用來講，消息隊列都是一個相當重要的組件，下面是十個理由:前端

1. 1解耦

在項目啓動之初來預測未來項目會碰到什麼需求，是極其困難的。消息隊列在處理過程當中間插入了一個隱含的、基於數據的接口層，兩邊的處理過程都要實現這一接口。這容許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵照一樣的接口約束。java

1.2 冗餘

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

1.3 擴展性

由於消息隊列解耦了你的處理過程，因此增大消息入隊和處理的頻率是很容易的；只要另外增長處理過程便可。不須要改變代碼、不須要調節參數。擴展就像調大電力按鈕同樣簡單。python

1.4 靈活性 & 峯值處理能力

當你的應用上了Hacker News的首頁，你將發現訪問流量攀升到一個不一樣尋常的水平。在訪問量劇增的狀況下，你的應用仍然須要繼續發揮做用，可是這樣的突發流量並不常見；若是爲以能處理這類峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列可以使關鍵組件頂住增加的訪問壓力，而不是由於超出負荷的請求而徹底崩潰。請查看咱們關於峯值處理能力的博客文章瞭解更多此方面的信息。mysql

1.5可恢復性

當體系的一部分組件失效，不會影響到整個系統。消息隊列下降了進程間的耦合度，因此即便一個處理消息的進程掛掉，加入隊列中的消息仍然能夠在系統恢復後被處理。而這種容許重試或者延後處理請求的能力一般是造就一個略感不便的用戶和一個沮喪透頂的用戶之間的區別。linux

1.6送達保證

消息隊列提供的冗餘機制保證了消息能被實際的處理，只要一個進程讀取了該隊列便可。在此基礎上，IronMQ提供了一個"只送達一次"保證。不管有多少進程在從隊列中領取數據，每個消息只能被處理一次。這之因此成爲可能，是由於獲取一個消息只是"預約"了這個消息，暫時把它移出了隊列。除非客戶端明確的表示已經處理完了這個消息，不然這個消息會被放回隊列中去，在一段可配置的時間以後可再次被處理。redis

1.7排序保證

在許多狀況下，數據處理的順序都很重要。消息隊列原本就是排序的，而且能保證數據會按照特定的順序來處理。IronMO保證消息漿糊經過FIFO（先進先出）的順序來處理，所以消息在隊列中的位置就是從隊列中檢索他們的位置。算法

1.8緩衝

在任何重要的系統中，都會有須要不一樣的處理時間的元素。例如,加載一張圖片比應用過濾器花費更少的時間。消息隊列經過一個緩衝層來幫助任務最高效率的執行--寫入隊列的處理會盡量的快速，而不受從隊列讀的預備處理的約束。該緩衝有助於控制和優化數據流通過系統的速度。

1.9 理解數據流

在一個分佈式系統裏，要獲得一個關於用戶操做會用多長時間及其緣由的整體印象，是個巨大的挑戰。消息系列經過消息被處理的頻率，來方便的輔助肯定那些表現不佳的處理過程或領域，這些地方的數據流都不夠優化。

1.10 異步通訊

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

2.消息隊列應用場景

如下介紹消息隊列在實際應用中經常使用的使用場景。異步處理，應用解耦，流量削鋒和消息通信四個場景。

2.1異步處理

場景說明：用戶註冊後，須要發註冊郵件和註冊短信。傳統的作法有兩種 1.串行的方式；2.並行方式
a、串行方式：將註冊信息寫入數據庫成功後，發送註冊郵件，再發送註冊短信。以上三個任務所有完成後，返回給客戶端。

b、並行方式：將註冊信息寫入數據庫成功後，發送註冊郵件的同時，發送註冊短信。以上三個任務完成後，返回給客戶端。與串行的差異是，並行的方式能夠提升處理的時間

假設三個業務節點每一個使用50毫秒鐘，不考慮網絡等其餘開銷，則串行方式的時間是150毫秒，並行的時間多是100毫秒。
由於CPU在單位時間內處理的請求數是必定的，假設CPU1秒內吞吐量是100次。則串行方式1秒內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）
小結：如以上案例描述，傳統的方式系統的性能（併發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？

引入消息隊列，將不是必須的業務邏輯，異步處理。改造後的架構以下：

按照以上約定，用戶的響應時間至關因而註冊信息寫入數據庫的時間，也就是50毫秒。註冊郵件，發送短信寫入消息隊列後，直接返回，所以寫入消息隊列的速度很快，基本能夠忽略，所以用戶的響應時間多是50毫秒。所以架構改變後，系統的吞吐量提升到每秒20 QPS。比串行提升了3倍，比並行提升了兩倍。

2.2應用解耦

場景說明：用戶下單後，訂單系統須要通知庫存系統。傳統的作法是，訂單系統調用庫存系統的接口。以下圖：

傳統模式的缺點：假如庫存系統沒法訪問，則訂單減庫存將失敗，從而致使訂單失敗，訂單系統與庫存系統耦合

如何解決以上問題呢？引入應用消息隊列後的方案，以下圖：

訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功
庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操做
假如：在下單時庫存系統不能正常使用。也不影響正常下單，由於下單後，訂單系統寫入消息隊列就再也不關心其餘的後續操做了。實現訂單系統與庫存系統的應用解耦

2.3流量削鋒

流量削鋒也是消息隊列中的經常使用場景，通常在秒殺或團搶活動中使用普遍。
應用場景：秒殺活動，通常會由於流量過大，致使流量暴增，應用掛掉。爲解決這個問題，通常須要在應用前端加入消息隊列。
a、能夠控制活動的人數
b、能夠緩解短期內高流量壓垮應用

用戶的請求，服務器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面。
秒殺業務根據消息隊列中的請求信息，再作後續處理

2.4日誌處理

日誌處理是指將消息隊列用在日誌處理中，好比Kafka的應用，解決大量日誌傳輸的問題。架構簡化以下

日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列
Kafka消息隊列，負責日誌數據的接收，存儲和轉發
日誌處理應用：訂閱並消費kafka隊列中的日誌數據

2.5消息通信

消息通信是指，消息隊列通常都內置了高效的通訊機制，所以也能夠用在純的消息通信。好比實現點對點消息隊列，或者聊天室等
點對點通信：

客戶端A和客戶端B使用同一隊列，進行消息通信。

聊天室通信：

客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發佈和接收。實現相似聊天室效果。

以上實際是消息隊列的兩種消息模式，點對點或發佈訂閱模式。模型爲示意圖，供參考。

3.消息中間件示例

3.1電商系統

消息隊列採用高可用，可持久化的消息中間件。好比Active MQ，Rabbit MQ，Rocket Mq。
（1）應用將主幹邏輯處理完成後，寫入消息隊列。消息發送是否成功能夠開啓消息的確認模式。（消息隊列返回消息接收成功狀態後，應用再返回，這樣保障消息的完整性）
（2）擴展流程（發短信，配送處理）訂閱隊列消息。採用推或拉的方式獲取消息並處理。
（3）消息將應用解耦的同時，帶來了數據一致性問題，能夠採用最終一致性方式解決。好比主數據寫入數據庫，擴展應用根據消息隊列，並結合數據庫方式實現基於消息隊列的後續處理。

3.2日誌收集系統

分爲Zookeeper註冊中心，日誌收集客戶端，Kafka集羣和Storm集羣（OtherApp）四部分組成。
Zookeeper註冊中心，提出負載均衡和地址查找服務
日誌收集客戶端，用於採集應用系統的日誌，並將數據推送到kafka隊列
Kafka集羣：接收，路由，存儲，轉發等消息處理
Storm集羣：與OtherApp處於同一級別，採用拉的方式消費隊列中的數據

如下是新浪kafka日誌處理應用案例：轉自（http://cloud.51cto.com/art/201507/484338.htm）

(1)Kafka：接收用戶日誌的消息隊列

(2)Logstash：作日誌解析，統一成JSON輸出給Elasticsearch

(3)Elasticsearch：實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，經過index組織數據，兼具強大的搜索和統計功能

(4)Kibana：基於Elasticsearch的數據可視化組件，超強的數據可視化能力是衆多公司選擇ELK stack的重要緣由

4.JMS消息服務

講消息隊列就不得不提JMS 。JMS（Java Message Service，Java消息服務）API是一個消息服務的標準/規範，容許應用程序組件基於JavaEE平臺建立、發送、接收和讀取消息。它使分佈式通訊耦合度更低，消息服務更加可靠以及異步性。
在EJB架構中，有消息bean能夠無縫的與JM消息服務集成。在J2EE架構模式中，有消息服務者模式，用於實現消息與應用直接的解耦。

4.1消息模型

在JMS標準中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。

4.1.1 P2P模式

P2P模式包含三個角色：消息隊列（Queue），發送者(Sender)，接收者(Receiver)。每一個消息都被髮送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留着消息，直到他們被消費或超時。

P2P的特色
每一個消息只有一個消費者（Consumer）(即一旦被消費，消息就再也不在消息隊列中)
發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息以後，無論接收者有沒有正在運行，它不會影響到消息被髮送到隊列
接收者在成功接收消息以後需向隊列應答成功
若是但願發送的每一個消息都會被成功處理的話，那麼須要P2P模式。

4.1.2 Pub/Sub模式

包含三個角色主題（Topic），發佈者（Publisher），訂閱者（Subscriber）多個發佈者將消息發送到Topic，系統將這些消息傳遞給多個訂閱者。

Pub/Sub的特色
每一個消息能夠有多個消費者
發佈者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須建立一個訂閱者以後，才能消費發佈者的消息
爲了消費消息，訂閱者必須保持運行的狀態
爲了緩和這樣嚴格的時間相關性，JMS容許訂閱者建立一個可持久化的訂閱。這樣，即便訂閱者沒有被激活（運行），它也能接收到發佈者的消息。
若是但願發送的消息能夠不被作任何處理、或者只被一個消息者處理、或者能夠被多個消費者處理的話，那麼能夠採用Pub/Sub模型。

4.2消息消費

在JMS中，消息的產生和消費都是異步的。對於消費來講，JMS的消息者能夠經過兩種方式來消費消息。
（1）同步
訂閱者或接收者經過receive方法來接收消息，receive方法在接收到消息以前（或超時以前）將一直阻塞；

（2）異步
訂閱者或接收者能夠註冊爲一個消息監聽器。當消息到達以後，系統自動調用監聽器的onMessage方法。

JNDI：Java命名和目錄接口,是一種標準的Java命名系統接口。能夠在網絡上查找和訪問服務。經過指定一個資源名稱，該名稱對應於數據庫或命名服務中的一個記錄，同時返回資源鏈接創建所必須的信息。
JNDI在JMS中起到查找和訪問發送目標或消息來源的做用。

5.經常使用消息隊列

通常商用的容器，好比WebLogic，JBoss，都支持JMS標準，開發上很方便。但免費的好比Tomcat，Jetty等則須要使用第三方的消息中間件。本部份內容介紹經常使用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特色。

5.1 ActiveMQ

ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。ActiveMQ 是一個徹底支持JMS1.1和J2EE 1.4規範的 JMS Provider實現，儘管JMS規範出臺已是好久的事情了，可是JMS在當今的J2EE應用中間仍然扮演着特殊的地位。

ActiveMQ特性以下：

多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
徹底支持JMS1.1和J2EE 1.4規範（持久化，XA消息，事務)
對Spring的支持，ActiveMQ能夠很容易內嵌到使用Spring的系統裏面去，並且也支持Spring2.0的特性
經過了常見J2EE服務器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中經過JCA 1.5 resource adaptors的配置，可讓ActiveMQ能夠自動的部署到任何兼容J2EE 1.4 商業服務器上
支持多種傳送協議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
支持經過JDBC和journal提供高速的消息持久化
從設計上保證了高性能的集羣，客戶端-服務器，點對點
支持Ajax
支持與Axis的整合
能夠很容易得調用內嵌JMS provider，進行測試

5.2 RabbitMQ

RabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標準實現。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用於在分佈式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。結構圖以下：

幾個重要概念：

Broker：簡單來講就是消息隊列服務器實體。
Exchange：消息交換機，它指定消息按什麼規則，路由到哪一個隊列。
Queue：消息隊列載體，每一個消息都會被投入到一個或多個隊列。
Binding：綁定，它的做用就是把exchange和queue按照路由規則綁定起來。
Routing Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。
vhost：虛擬主機，一個broker裏能夠開設多個vhost，用做不一樣用戶的權限分離。
producer：消息生產者，就是投遞消息的程序。
consumer：消息消費者，就是接受消息的程序。
channel：消息通道，在客戶端的每一個鏈接裏，可創建多個channel，每一個channel表明一個會話任務。

消息隊列的使用過程，以下：

客戶端鏈接到消息隊列服務器，打開一個channel。
客戶端聲明一個exchange，並設置相關屬性。
客戶端聲明一個queue，並設置相關屬性。
客戶端使用routing key，在exchange和queue之間創建好綁定關係。
客戶端投遞消息到exchange。

exchange接收到消息後，就根據消息的key和已經設置的binding，進行消息路由，將消息投遞到一個或多個隊列裏。

5.3 ZeroMQ

號稱史上最快的消息隊列，它實際相似於Socket的一系列接口，他跟Socket的區別是：普通的socket是端到端的（1:1的關係），而ZMQ倒是能夠N：M 的關係，人們對BSD套接字的瞭解較多的是點對點的鏈接，點對點鏈接須要顯式地創建鏈接、銷燬鏈接、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網絡編程更爲簡單。ZMQ用於node與node間的通訊，node能夠是主機或者是進程。

引用官方的說法：「ZMQ(如下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架同樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是「成爲標準網絡協議棧的一部分，以後進入Linux內核」。如今還未看到它們的成功。可是，它無疑是極具前景的、而且是人們更加須要的「傳統」BSD套接字之上的一層封裝。ZMQ讓編寫高性能網絡應用程序極爲簡單和有趣。」

特色是：

高性能，非持久化
跨平臺：支持Linux、Windows、OS X等
多語言支持； C、C++、Java、.NET、python等30多種開發語言
可單獨部署或集成到應用中使用
可做爲Socket通訊庫使用

與RabbitMQ相比，ZMQ並不像是一個傳統意義上的消息隊列服務器，事實上，它也根本不是一個服務器，更像一個底層的網絡通信庫，在Socket API之上作了一層封裝，將網絡通信、進程通信和線程通信抽象爲統一的API接口。支持「Request-Reply 「，」Publisher-Subscriber「，」Parallel Pipeline」三種基本模型和擴展模型。

ZeroMQ高性能設計要點：

一、無鎖的隊列模型

對於跨線程間的交互（用戶端和session）之間的數據交換通道pipe，採用無鎖的隊列算法CAS；在pipe兩端註冊有異步事件，在讀或者寫消息到pipe的時，會自動觸發讀寫事件。

二、批量處理的算法

對於傳統的消息處理，每一個消息在發送和接收的時候，都須要系統的調用，這樣對於大量的消息，系統的開銷比較大，zeroMQ對於批量的消息，進行了適應性的優化，能夠批量的接收和發送消息。

三、多核下的線程綁定，無須CPU切換

區別於傳統的多線程併發模式，信號量或者臨界區， zeroMQ充分利用多核的優點，每一個核綁定運行一個工做者線程，避免多線程之間的CPU切換開銷。

5.4 Kafka

Kafka是一種高吞吐量的分佈式發佈訂閱消息系統，它能夠處理消費者規模的網站中的全部動做流數據。這種動做（網頁瀏覽，搜索和其餘用戶的行動）是在現代網絡上的許多社會功能的一個關鍵因素。這些數據一般是因爲吞吐量的要求而經過處理日誌和日誌聚合來解決。對於像Hadoop的同樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是經過hadoop的並行加載機制來統一線上和離線的消息處理，也是爲了經過集羣機來提供實時的消費。

Kafka是一種高吞吐量的分佈式發佈訂閱消息系統，有以下特性：

經過O(1)的磁盤數據結構提供消息的持久化，這種結構對於即便數以TB的消息存儲也可以保持長時間的穩定性能。（文件追加的方式寫入數據，過時的數據按期刪除）
高吞吐量：即便是很是普通的硬件Kafka也能夠支持每秒數百萬的消息
支持經過Kafka服務器和消費機集羣來分區消息
支持Hadoop並行數據加載

Kafka相關概念

Broker：Kafka集羣包含一個或多個服務器，這種服務器被稱爲broker[5]
Topic：每條發佈到Kafka集羣的消息都有一個類別，這個類別被稱爲Topic。（物理上不一樣Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic便可生產或消費數據而沒必要關心數據存於何處）
Partition：Parition是物理上的概念，每一個Topic包含一個或多個Partition.
Producer：負責發佈消息到Kafka broker
Consumer：消息消費者，向Kafka broker讀取消息的客戶端。
Consumer Group：每一個Consumer屬於一個特定的Consumer Group（可爲每一個Consumer指定group name，若不指定group name則屬於默認的group）。

通常應用在大數據日誌處理或對實時性（少許延遲），可靠性（少許丟數據）要求稍低的場景使用。

6.使用消息隊列須要考慮的問題

6.1你也許並不須要消息隊列

消息隊列是一個能讓你得到容錯性，分佈式，解耦等架構能力的系統。紙上談兵的話，它看起來還不錯。

或許消息列隊在你的應用中有很多適用的場景。你能夠看下這篇關於消息隊列優勢的文章，看看到底有哪些合適的場景。但可不要由於說"能解耦那太好了」就輕易使用它。咱們來看一個例子——你但願你的郵件發送和訂單處理互相解耦。

所以你發送一個消息到消息隊列裏，而後郵件處理系統取出這個消息併發送郵件。那你在一個獨立的單classpath的應用中怎麼實現呢？讓你的訂單處理服務依賴於一個郵件服務，而後調用sendEmail()方法，而不是sendToMQ()方法。若是你使用了消息隊列，你須要定義一個兩個系統都能識別的消息格式；若是你不使用消息隊列，那麼你得定義一個方法簽名。它們有什麼本質的區別嗎？其實沒有。

不過你可能還有別的消費者想要對某個指定的消息進行額外的處理？這的確是可能發生的，而並不僅是針對咱們這裏說到的這個項目而已。儘管確有可能，但相比添加另外一個方法調用而言，它可能並不值當。耦合？是的。不過這個耦合並無什麼不方便的。

那我應該如何處理峯值流量？你能夠經過消息隊列將請求放到一個持久化隊列中，而後再一併處理它們。這是一個很是有用的特性，不過它也受限於幾個因素——你的請求是在UI後臺處理，仍是須要即時響應？serlvet容器的線程池某種程度上能夠看成是一個隊列，用戶最終會拿到響應，可是得須要等待（若是線程的超時時間太短的話，請求可能會丟失）。

你可使用一個內存隊列來存儲那些較重的請求（得在UI後臺進行處理）。不過注意了，你的隊列並非默認高可用的。好比說，若是一個消息隊列節點掛掉了，你的消息就丟失了。所以，不去使用應用節點內的內存隊列，而是去使用一個消息隊列，這可能並無什麼優點。

消息隊列使得咱們能夠進行異步處理——這的確是個有用的特性。你不但願在用戶等待的時候作一些很重的操做。不過你也可使用一個內存隊列，或者簡單地啓動一個新的線程（好比spring的@Async註解）。這樣又有另外一個問題——若是消息丟失的話是否有問題？若是你應用處理請求的節點掛了，你能夠進行恢復嗎？你會發現這事會常常發生，若是不保證全部消息都處理到的話，很難保證功能的正確性。所以，僅將較重的調用進行異步處理是比較可取的。

把消息放到隊列以便讓另外一個組件來進行處理，對於這個場景，若是消息丟失是沒法接受的，這也有一個很簡單的解決方案——數據庫。你能夠把一條processed=false的數據存儲到數據庫中。而後再運行一個調度做業，將全部未處理的記錄挑選出來，異步地進行處理。當處理完成的時候，將標記設爲true。我常常用這個方法，包括在一些大型的線上系統中，它也工做得挺好的。

這樣你還能不斷地對你的應用節點進行擴展，只要它們的內存中沒有任何的持久化狀態的話。無論你是否使用了消息隊列均可以（臨時的內存處理隊列並不屬於持久化狀態）。

爲何我要給常常用到的消息隊列提供一些備選方案？由於若是你因爲不恰當的緣由選擇了它，那麼消息隊列可能會成爲一個負擔。它們並不是如想像中那樣容易使用。首先，它有一個學習曲線。通常來講，你集成的組件切分得越多，就越容易出現問題。其次，還有一個設置及配置的成本。好比說，當消息隊列須要在一個集羣中運行的話，好比說多個數據中心，那麼這就變得複雜了。

高可用性並非上來就有的——默認它是不會打開的。還有就是你的應用節點如何鏈接到消息隊列？經過一個刷新的鏈接池，或者使用短生命週期的DNS記錄，仍是經過一個負載均衡器？你的隊列可能還有許多配置項，大小是多少，行爲是怎樣的（消費者需不須要確認接受，要不要通知處理失敗，多個消費者可以取到同一個消息嗎，消息有沒有TTL，等等）同時還有網絡及消息傳遞的開銷，尤爲是如今你們都喜歡用XML或者JSON來傳輸消息。若是你過分地使用了消息隊列，那麼它會增長你係統的延時。

最後一點，但並非最次要的——若是出現問題的話，使用消息隊列會讓問題跟蹤變得異常困難。你無法在IDE中看到所謂的調用層次，由於一旦你發送消息到隊列裏了，你就得本身去查找它在哪裏處理的了。這可不是聽起來那麼簡單的。你看到了吧，它會給你增長許多的複雜性，以及許多須要注意的東西。

一般而言，在某些上下文中，消息隊列仍是很是有用的。當它們的確適合的話，我也會在項目中使用它們——比方說，咱們不想丟失消息，但又但願能快速地進行處理。我也見過它在一些不太常見的場景中使用的狀況，好比說只有一個應用節點來進行消費，無論是哪一個節點投遞過來的消息。你還能夠看下stackoverflow上的這個問題。還有一些使用場景就是，或許你的確須要進行多語言間的通訊，又或者你的數據流已通過於複雜了，不使用新的消息消費者而是增長新方法調用的話代價會很大。

我想說的是那句老掉牙的真理「殺雞焉用牛刀」。若是你不是很肯定已經沒有別的更容易管理和維護的方法，必定要使用消息隊列的話，最好不要使用它。不要由於」萬一它有用呢「而去用它——只有你確實以爲須要的話再去使用。由於頗有可能，就像這裏說到的這個項目同樣，消息隊列實際上是沒有必要的。