[[394229]]

大家好，我是狼王，一個(gè)愛打球的程序員

隨著互聯(lián)網(wǎng)的發(fā)展，技術(shù)也在快速的迭代中，由于大流量，高并發(fā)的出現(xiàn)，很多問題也隨之而來了，為了解決這些問題，一些高端的人才研究出了各種解決這些問題的東西，消息隊(duì)列就是其中一種。那么今天，我們就來聊聊消息隊(duì)列吧!

什么是消息隊(duì)列?

消息隊(duì)列不知道大家看到這個(gè)詞的時(shí)候，會(huì)不會(huì)覺得它是一個(gè)比較高端的技術(shù)，反正我是覺得它好像是挺牛逼的。

消息隊(duì)列，一般我們會(huì)簡稱它為MQ(Message Queue)，嗯，就是很直白的簡寫。

我們先不管消息(Message)這個(gè)詞，來看看隊(duì)列(Queue)。這一看，隊(duì)列大家應(yīng)該都熟悉吧。

隊(duì)列是一種先進(jìn)先出的數(shù)據(jù)結(jié)構(gòu)。

在Java里邊，已經(jīng)實(shí)現(xiàn)了不少的隊(duì)列了。

那為什么還需要消息隊(duì)列(MQ)這種中間件呢???

其實(shí)這個(gè)問題，跟之前我學(xué)Redis的時(shí)候很像。Redis是一個(gè)以key-value形式存儲(chǔ)的內(nèi)存數(shù)據(jù)庫，明明我們可以使用類似HashMap這種實(shí)現(xiàn)類就可以達(dá)到類似的效果了，那還為什么要Redis?

到這里，大家可以先猜猜為什么要用消息隊(duì)列(MQ)這種中間件

消息隊(duì)列可以簡單理解為：把要傳輸?shù)臄?shù)據(jù)放在隊(duì)列中。

科普:

• 把數(shù)據(jù)放到消息隊(duì)列叫做生產(chǎn)者
• 從消息隊(duì)列里邊取數(shù)據(jù)叫做消費(fèi)者

市面上的消息隊(duì)列產(chǎn)品有很多，比如老牌的 ActiveMQ、RabbitMQ ，目前比較火的有Kafka ，和阿里巴巴捐贈(zèng)給 Apache 的 RocketMQ ，連 redis 這樣的 NoSQL 數(shù)據(jù)庫也支持 MQ 功能。總之這塊知名的產(chǎn)品就有十幾種。

為什么要用消息隊(duì)列，也就是在問:用了消息隊(duì)列有什么好處。

解耦

以常見的訂單系統(tǒng)為例

用戶點(diǎn)擊【下單】按鈕之后的業(yè)務(wù)邏輯可能包括:扣減庫存、生成相應(yīng)單據(jù)、發(fā)貨、發(fā)短信通知等。

在業(yè)務(wù)發(fā)展初期這些邏輯可能放在一起同步執(zhí)行，隨著業(yè)務(wù)的發(fā)展訂單量增長，需要提升系統(tǒng)服務(wù)的性能。

這時(shí)可以將一些不需要立即生效的操作拆分出來異步執(zhí)行，比如發(fā)貨、發(fā)短信通知等。

這種場景下就可以用 MQ ，在下單的主流程(比如扣減庫存、生成相應(yīng)單據(jù))完成之后發(fā)送一條消息到 MQ 讓主流程快速完結(jié)，而由另外的單獨(dú)線程拉取MQ的消息(或者由 MQ 推送消息)，當(dāng)發(fā)現(xiàn) MQ 中有發(fā)貨或發(fā)短信之類的消息時(shí)，執(zhí)行相應(yīng)的業(yè)務(wù)邏輯。

簡單的說就是原來a服務(wù)需要調(diào)用b服務(wù)的接口或者方法來進(jìn)行數(shù)據(jù)的傳遞，這個(gè)時(shí)候使用消息隊(duì)列的話，a服務(wù)只需將數(shù)據(jù)發(fā)送到消息隊(duì)列中，b服務(wù)從消息隊(duì)列中取出相應(yīng)的數(shù)據(jù)即可，就實(shí)現(xiàn)了解耦

異步

異步其實(shí)就是a服務(wù)將數(shù)據(jù)發(fā)送到消息隊(duì)列之后就可以進(jìn)行返回或者執(zhí)行其他過程，不需要等待b服務(wù)處理數(shù)據(jù)，從而來提高一些使用異步的業(yè)務(wù)場景的效率問題

削峰/限流

我們再來一個(gè)場景，比如現(xiàn)在我們每個(gè)月要搞一次大促，大促期間的并發(fā)可能會(huì)很高的，比如每秒5000個(gè)請(qǐng)求。假設(shè)我們現(xiàn)在有兩臺(tái)機(jī)器處理請(qǐng)求，并且每臺(tái)機(jī)器只能每次處理2000個(gè)請(qǐng)求。

那多出來的1000個(gè)請(qǐng)求，可能就把我們整個(gè)系統(tǒng)給搞崩了,所以,有一種辦法，我們可以寫到消息隊(duì)列中:

服務(wù)器A和服務(wù)器B根據(jù)自己的能夠處理的請(qǐng)求數(shù)去消息隊(duì)列中拿數(shù)據(jù)，這樣即便有每秒有1w個(gè)請(qǐng)求，那只是把請(qǐng)求放在消息隊(duì)列中，去拿消息隊(duì)列的消息由系統(tǒng)自己去控制，這樣就不會(huì)把整個(gè)系統(tǒng)給搞崩。

使用消息隊(duì)列有什么問題?

經(jīng)過我們上面的場景，我們已經(jīng)可以發(fā)現(xiàn)，消息隊(duì)列能做的事其實(shí)還是蠻多的。

說到這里，我們先回到文章的開頭，"明明JDK已經(jīng)有不少的隊(duì)列實(shí)現(xiàn)了，我們還需要消息隊(duì)列中間件呢?"

其實(shí)很簡單，JDK實(shí)現(xiàn)的隊(duì)列種類雖然有很多種，但是都是簡單的內(nèi)存隊(duì)列。為什么我說JDK是簡單的內(nèi)存隊(duì)列呢?

下面我們來看看要實(shí)現(xiàn)消息隊(duì)列(中間件)可能要考慮什么問題。

高可用

無論是我們使用消息隊(duì)列來做解耦、異步還是削峰，消息隊(duì)列肯定不能是單機(jī)的。試著想一下，如果是單機(jī)的消息隊(duì)列，萬一這臺(tái)機(jī)器掛了，那我們整個(gè)系統(tǒng)幾乎就是不可用了,就出現(xiàn)了單點(diǎn)故障。

所以，當(dāng)我們項(xiàng)目中使用消息隊(duì)列，都是得集群/分布式的。要做集群/分布式就必然希望該消息隊(duì)列能夠提供現(xiàn)成的支持，而不是自己寫代碼手動(dòng)去實(shí)現(xiàn)。

數(shù)據(jù)丟失問題

我們將數(shù)據(jù)寫到消息隊(duì)列上，服務(wù)器A和服務(wù)器B還沒來得及消費(fèi)消息隊(duì)列的數(shù)據(jù)，就掛掉了。如果沒有做任何的措施，我們的數(shù)據(jù)就丟了。

學(xué)過Redis的都知道，Redis可以將數(shù)據(jù)持久化磁盤上，萬一Redis掛了，還能從磁盤將數(shù)據(jù)恢復(fù)過來。同樣地，消息隊(duì)列中的數(shù)據(jù)也需要存在別的地方，這樣才盡可能減少數(shù)據(jù)的丟失。

• 那存在哪呢?
• 磁盤?
• 數(shù)據(jù)庫?
• 同步存儲(chǔ)還是異步存儲(chǔ)?

不同的MQ針對(duì)消息丟失的處理和解決方案都有所不同，但是肯定都是從生產(chǎn)者和消費(fèi)者兩端進(jìn)行分析的。

生產(chǎn)者端丟失消息

生產(chǎn)者要確保消息發(fā)送到了MQ，就會(huì)有回調(diào)確認(rèn)機(jī)制的處理和事務(wù)的方式

消息隊(duì)列丟失消息

在消息隊(duì)列中假如因?yàn)镸Q掛了導(dǎo)致消息丟了，那么就可以將消息持久化，或者使用生產(chǎn)者端重發(fā)消息的方式

消費(fèi)者端丟消息

一般消費(fèi)者丟了消息的原因就是從MQ中取到了消息，但是可能消費(fèi)失敗了需要重新消費(fèi)，但是MQ中已經(jīng)沒有該條消息了，這樣的話可以通過消費(fèi)者端手動(dòng)確認(rèn)的機(jī)制，或者讓生產(chǎn)者端重發(fā)消息的方式

消費(fèi)者怎么得到消息隊(duì)列的數(shù)據(jù)?

消費(fèi)者怎么從消息隊(duì)列里邊得到數(shù)據(jù)?一般有兩種辦法:

生產(chǎn)者將數(shù)據(jù)放到消息隊(duì)列中，消息隊(duì)列有數(shù)據(jù)了，主動(dòng)叫消費(fèi)者去拿(俗稱push)

消費(fèi)者不斷去輪訓(xùn)消息隊(duì)列，看看有沒有新的數(shù)據(jù)，如果有就消費(fèi)(俗稱pull)

其他問題

除了這些，我們在使用的時(shí)候還得考慮各種的問題:

消息重復(fù)消費(fèi)了怎么辦啊?我想保證消息是絕對(duì)有順序的怎么做?……..

雖然消息隊(duì)列給我們帶來了那么多的好處，但同時(shí)我們發(fā)現(xiàn)引入消息隊(duì)列也會(huì)提高系統(tǒng)的復(fù)雜性。市面上現(xiàn)在已經(jīng)有不少消息隊(duì)列輪子了，每種消息隊(duì)列都有自己的特點(diǎn)，選取哪種MQ還得好好斟酌。

這次我們先來講講RabbitMQ

RabbitMQ

RabbitMQ 是一個(gè)由 Erlang 語言開發(fā)的 AMQP 的開源實(shí)現(xiàn)。

AMQP : Advanced Message Queue，高級(jí)消息隊(duì)列協(xié)議。它是應(yīng)用層協(xié)議的一個(gè)開放標(biāo)準(zhǔn)，為面向消息的中間件設(shè)計(jì)，基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受產(chǎn)品、開發(fā)語言等條件的限制。

RabbitMQ 最初起源于金融系統(tǒng)，用于在分布式系統(tǒng)中存儲(chǔ)轉(zhuǎn)發(fā)消息，在易用性、擴(kuò)展性、高可用性等方面表現(xiàn)不俗。具體特點(diǎn)包括:

• 可靠性(Reliability) RabbitMQ 使用一些機(jī)制來保證可靠性，如持久化、傳輸確認(rèn)、發(fā)布確認(rèn)。
• 靈活的路由(Flexible Routing) 在消息進(jìn)入隊(duì)列之前，通過 Exchange 來路由消息的。對(duì)于典型的路由功能，RabbitMQ 已經(jīng)提供了一些內(nèi)置的 Exchange 來實(shí)現(xiàn)。針對(duì)更復(fù)雜的路由功能，可以將多個(gè) Exchange 綁定在一起，也通過插件機(jī)制實(shí)現(xiàn)自己的 Exchange 。
• 消息集群(Clustering) 多個(gè) RabbitMQ 服務(wù)器可以組成一個(gè)集群，形成一個(gè)邏輯 Broker 。
• 高可用(Highly Available Queues) 隊(duì)列可以在集群中的機(jī)器上進(jìn)行鏡像，使得在部分節(jié)點(diǎn)出問題的情況下隊(duì)列仍然可用。
• 多種協(xié)議(Multi-protocol) RabbitMQ 支持多種消息隊(duì)列協(xié)議，比如 STOMP、MQTT 等等。
• 多語言客戶端(Many Clients) RabbitMQ 幾乎支持所有常用語言，比如 Java、.NET、Ruby 等等。
• 管理界面(Management UI) RabbitMQ 提供了一個(gè)易用的用戶界面，使得用戶可以監(jiān)控和管理消息 Broker 的許多方面。
• 跟蹤機(jī)制(Tracing) 如果消息異常，RabbitMQ 提供了消息跟蹤機(jī)制，使用者可以找出發(fā)生了什么。
• 插件機(jī)制(Plugin System) RabbitMQ 提供了許多插件，來從多方面進(jìn)行擴(kuò)展，也可以編寫自己的插件。

RabbitMQ 中的概念模型

消息模型

所有 MQ 產(chǎn)品從模型抽象上來說都是一樣的過程:消費(fèi)者(consumer)訂閱某個(gè)隊(duì)列。生產(chǎn)者(producer)創(chuàng)建消息，然后發(fā)布到隊(duì)列(queue)中，最后將消息發(fā)送到監(jiān)聽的消費(fèi)者。

RabbitMQ 基本概念

上面只是最簡單抽象的描述，具體到 RabbitMQ 則有更詳細(xì)的概念需要解釋。上面介紹過 RabbitMQ 是 AMQP 協(xié)議的一個(gè)開源實(shí)現(xiàn)，所以其內(nèi)部實(shí)際上也是 AMQP 中的基本概念:

1. Message 消息，消息是不具名的，它由消息頭和消息體組成。消息體是不透明的，而消息頭則由一系列的可選屬性組成，這些屬性包括routing-key(路由鍵)、priority(相對(duì)于其他消息的優(yōu)先權(quán))、delivery-mode(指出該消息可能需要持久性存儲(chǔ))等。
2. Publisher 消息的生產(chǎn)者，也是一個(gè)向交換器發(fā)布消息的客戶端應(yīng)用程序。
3. Exchange 交換器，用來接收生產(chǎn)者發(fā)送的消息并將這些消息路由給服務(wù)器中的隊(duì)列。
4. Binding 綁定，用于消息隊(duì)列和交換器之間的關(guān)聯(lián)。一個(gè)綁定就是基于路由鍵將交換器和消息隊(duì)列連接起來的路由規(guī)則，所以可以將交換器理解成一個(gè)由綁定構(gòu)成的路由表。
5. Queue 消息隊(duì)列，用來保存消息直到發(fā)送給消費(fèi)者。它是消息的容器，也是消息的終點(diǎn)。一個(gè)消息可投入一個(gè)或多個(gè)隊(duì)列。消息一直在隊(duì)列里面，等待消費(fèi)者連接到這個(gè)隊(duì)列將其取走。
6. Connection 網(wǎng)絡(luò)連接，比如一個(gè)TCP連接。
7. Channel 信道，多路復(fù)用連接中的一條獨(dú)立的雙向數(shù)據(jù)流通道。信道是建立在真實(shí)的TCP連接內(nèi)的虛擬連接，AMQP 命令都是通過信道發(fā)出去的，不管是發(fā)布消息、訂閱隊(duì)列還是接收消息，這些動(dòng)作都是通過信道完成。因?yàn)閷?duì)于操作系統(tǒng)來說建立和銷毀 TCP 都是非常昂貴的開銷，所以引入了信道的概念，以復(fù)用一條 TCP 連接。
8. Consumer 消息的消費(fèi)者，表示一個(gè)從消息隊(duì)列中取得消息的客戶端應(yīng)用程序。
9. Virtual Host 虛擬主機(jī)，表示一批交換器、消息隊(duì)列和相關(guān)對(duì)象。虛擬主機(jī)是共享相同的身份認(rèn)證和加密環(huán)境的獨(dú)立服務(wù)器域。每個(gè)vhost 本質(zhì)上就是一個(gè) mini 版的 RabbitMQ 服務(wù)器，擁有自己的隊(duì)列、交換器、綁定和權(quán)限機(jī)制。vhost 是 AMQP 概念的基礎(chǔ)，必須在連接時(shí)指定，RabbitMQ 默認(rèn)的 vhost 是 / 。
10. Broker 表示消息隊(duì)列服務(wù)器實(shí)體。

本文主要講解了什么是消息隊(duì)列，消息隊(duì)列可以為我們帶來什么好處，以及一個(gè)消息隊(duì)列可能會(huì)涉及到哪些問題,后來會(huì)更加深入的去探討哦!希望給大家?guī)硪欢ǖ膸椭?/p>

好了。今天就說到這了，我還會(huì)不斷分享自己的所學(xué)所想，希望我們一起走在成功的道路上!