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

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

圖片

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

常用的消息隊(duì)列

RocketMQ

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

RabbitMQ

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

Apache Kafka

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

ActiveMQ

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

除此之外，其實(shí) Redis 也可以做消息隊(duì)列。

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

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

異步處理和解耦

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

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

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

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

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

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

流量削峰

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

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

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

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

日志處理

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

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

分布式事務(wù)

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

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

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

圖片

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

延時(shí)任務(wù)

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

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

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

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

最后

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

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