消息隊列作為互聯(lián)網(wǎng)互聯(lián)網(wǎng)項目的一個可選中間件，被很多的項目、產(chǎn)品采用。就算你沒用過，肯定也多少了解一些，因為它是現(xiàn)代面試八股文必考科目之一。

消息隊列這個很形象，就是把消息推到一個隊列中，然后再到這個隊列里讀，是不是就這么簡單。

圖片

聽說消息隊列最有用的功能是異步和解耦，而什么消峰填谷、分布式事務(wù)都是錦上添花而已。

常用的消息隊列

RocketMQ

RocketMQ 是阿里巴巴開發(fā)，現(xiàn)在已經(jīng)是 Apache 軟件基金會的頂級項目。RocketMQ 是用 Java 開發(fā)，很多使用 Java 技術(shù)棧的公司都用 RocketMQ 作為消息隊列。我們就主要使用 RocketMQ 作為消息隊列服務(wù)。

RabbitMQ

RabbitMQ 是一個開源的消息代理軟件，它采用了高級消息隊列協(xié)議（AMQP），用于在分布式系統(tǒng)中實現(xiàn)異步通信和消息傳遞，采用 Erlang 語言開發(fā)。最開始學(xué)習(xí)消息隊列就是用的 RabbitMQ。

Apache Kafka

pache Kafka 是一個分布式流處理平臺，最初由 LinkedIn 開發(fā)，并于2011年開源，之后成為 Apache 軟件基金會的頂級項目。Kafka 旨在處理實時數(shù)據(jù)流，具有高吞吐量、低延遲和高可靠性的特點，廣泛應(yīng)用于日志收集、流處理、數(shù)據(jù)集成等場景。

ActiveMQ

Apache ActiveMQ 是一個開源的消息代理和集成模式服務(wù)器，由 Apache 軟件基金會開發(fā)。ActiveMQ 在形式上和 RabbitMQ 比較像，ActiveMQ 也是用 Java 開發(fā)的。

除此之外，其實 Redis 也可以做消息隊列。

消息隊列的應(yīng)用場景

消息隊列最厲害的地方并不是采用的技術(shù)有多厲害，而是它的應(yīng)用場景，只要把它加到某些應(yīng)用場景中，有很多問題都可以迎刃而解。所以說，它厲害在思想上。

異步處理和解耦

說到異步就離不開解耦，說到解耦又脫離不了異步。

什么是異步呢？假設(shè)有個系統(tǒng)需要處理一個長流程，最常見的例子就是下單場景，用戶下單購買商品，后臺服務(wù)要在這個下單行為發(fā)生后做一系列的事情，要減庫存、加到用戶已購買列表中、發(fā)通知、跟蹤訂單進度等。

這一系列的動作如果全都同步來做，那響應(yīng)時間會比較久，而且一旦其中某個環(huán)節(jié)失敗，將會更加麻煩。

所以針對類似的場景，就有了異步處理的思路，在同步響應(yīng)中只把最重要的動作完成，剩下的都可以異步處理，比如購買行為，收錢和減庫存是最重要的，這兩個成功了就算是購買成功了，剩下的通知、跟蹤進度都可以稍后進行，也就是異步處理。

說到此，解耦也就出現(xiàn)了，收錢和減庫存可以是一個線程來做，或者一個單獨的服務(wù)來做，發(fā)通知又可以是另一個線程或者另一個服務(wù)來做，這樣一來，兩個動作、兩個功能就解耦了，發(fā)通知的服務(wù)掛了不會影響真正的購買行為，而等到發(fā)通知服務(wù)啟動后，可以再處理歷史數(shù)據(jù)也沒問題。

這個場景下，用到消息隊列再合適不過。而且聽說，這個場景才是消息隊列有價值的地方，也是消息隊列思想的靈魂所在。

流量削峰

流量削峰是在高并發(fā)情況下，通過消息隊列將大量請求排隊處理，避免系統(tǒng)在短時間內(nèi)被大量請求壓垮。

假設(shè)一個系統(tǒng)本來日常只支持1萬并發(fā)，但是某個時候突然有大量的用戶進來，流量超過了系統(tǒng)所能承受的最大值，如果不加以控制，那等待系統(tǒng)的只有崩潰。

這種情況下，系統(tǒng)可以將處理不了的請求暫時放到消息隊列中，然后在系統(tǒng)所能支持的并發(fā)下依次處理隊列中的請求。這樣一來，系統(tǒng)既不會崩潰，也能將請求都一一處理掉。

當(dāng)然了，如果沒有消息隊列，本身系統(tǒng)也可以采取其他的處理措施，比如直接將請求丟棄，或者返回一個固定值。比如某些搶購場景，本來就有數(shù)量限制，只有最先進來的請求才能搶到，后面不管再進來多少都搶不到，那后面多余的請求就沒必要處理。

日志處理

很多公司都有專門的日志查看平臺，例如 Kibana，公司內(nèi)所有項目都會歸集到統(tǒng)一的地方，通過界面點點按鈕就能看到不同項目的日志了。

這背后的原理就是將用戶行為日志發(fā)送到消息隊列，再由專門的日志處理服務(wù)進行分析和處理。自從 Kafka 一出來，再用消息隊列傳輸日志就好像被它壟斷了。沒辦法，誰讓人家在這方面有特長呢。

分布式事務(wù)

分布式事務(wù)通俗來說就是要么都成功，要么都不成功。

還是拿訂單系統(tǒng)為例，在訂單創(chuàng)建后，通過消息隊列通知庫存系統(tǒng)進行庫存扣減，以保證數(shù)據(jù)的一致性。

下圖是 RocketMQ 中關(guān)于分布式事務(wù)的流程圖，我們之前的項目中一直用這種方式做分布式事務(wù)處理。

圖片

這是有些消息隊列本身支持的特性，只有本地事務(wù)完全成功執(zhí)行后，才會最終投遞消息，否則消費者是看不到這個消息的。

延時任務(wù)

比如我們在 12306買票，預(yù)訂后鎖票，有30分鐘時間用來付款，這30分鐘內(nèi)，其他人是沒辦法看到這張票的。如果30分鐘內(nèi)未付款，那這張票就不屬于你了。

這種場景就是延時任務(wù)的經(jīng)典場景，每一個預(yù)訂都會有自己的一個任務(wù)，這種任務(wù)和系統(tǒng)定時在某時某刻的定時任務(wù)是完全不一樣的。

就是因為每一個預(yù)訂都有一個任務(wù)，總不能來一個任務(wù)就給系統(tǒng)加一個定時任務(wù)吧，這不現(xiàn)實。所以這種場景下，用延時隊列就最合適了，有些消息隊列是支持的。

在消息生產(chǎn)者投遞消息時，給消息一個延遲時間，只有到了規(guī)定的延遲時間后，這個消息才能被消費者消費掉。

最后

消息隊列最厲害的地方在于它的思想，而不在于它使用的具體技術(shù)。

消息隊列的應(yīng)用場景眾多，但是這么多應(yīng)用場景中我覺得異步和解耦才是最重要的能力，你覺得呢？