以Rabbit MQ為例講透消息隊列

作者：陳峻 2021-05-31 08:00:00

本文向您簡單介紹了消息隊列模型Rabbit MQ的基本特點，并討論了不同類型的交換，可作為消息隊列的初學者指南。

【51CTO.com快譯】在早年的單體架構時代，由于應用程序的內(nèi)部組件存在著緊密的耦合關系，因此它們之間存在著千絲萬縷的直接關聯(lián)。例如，在一個簡單的電子商務應用中，其結帳服務需要與支付網(wǎng)關服務保持通信。這就得依靠TCP的直接連接來完成。由此，我們很容易碰到如下限制場景：

一旦結帳消息被發(fā)出后，應用需要能夠及時偵聽到，并予以答復，方可繼續(xù)執(zhí)行下一個任務。
如果庫存服務出現(xiàn)了故障，應用將進行反復嘗試，直至連接被成功建立為止。
如果同時有大量的支付請求產(chǎn)生，庫存服務將由于供不應求，而導致整個系統(tǒng)陷入癱瘓。

可以說，這些都是創(chuàng)建消息隊列和代理(message queues/brokers)的“剛需”。

什么是消息隊列

如下圖所示，消息隊列往往處于需要彼此通信的兩個服務之間：

通信服務的流程圖

如上圖所示，系統(tǒng)1通常作為生產(chǎn)者(producer)會將消息添加到隊列中，以便立即執(zhí)行下一個任務。

在準備就緒后，系統(tǒng)2作為使用者(consumer)會從隊列中獲取消息，予以處理，并在完成后立即轉(zhuǎn)向下一條消息。據(jù)此，兩個應用系統(tǒng)實現(xiàn)了邏輯上的解耦關系。

同時，消息代理也有助于提高系統(tǒng)的可擴展性。當系統(tǒng)中有大量并發(fā)的“獲取”操作時，隊列會出現(xiàn)擁堵，這就意味著我們需要提供更多的取出服務。那么在上述例子的系統(tǒng)2中，如果有多個使用者要從隊列中讀取內(nèi)容，以滿足由大量用戶的支付請求所產(chǎn)生的負載時，應用系統(tǒng)需要具一定的可擴展能力。

此外，消息隊列的另一個好處是：隊列本身可以被構建在計算機或服務器的內(nèi)部，以分擔Web應用程序的某些工作，進而提高系統(tǒng)的整體性能。

生產(chǎn)者和使用者的流程圖

不知您是否聽說過RabbitMQ?它是高級消息隊列協(xié)議(Advanced Message Queuing Protocol，AMQP)模型的實現(xiàn)。

在此類消息模型中，生產(chǎn)者會去獲取那些由服務產(chǎn)生的消息。就效率而言，與其我們直接產(chǎn)生一個消息隊列，不如產(chǎn)生消息的交換節(jié)點。而交換節(jié)點恰好可以像中轉(zhuǎn)郵局一樣，去接收所有的消息，然后根據(jù)它們的處理方式予以分發(fā)。

如上圖所示，一個交換節(jié)點可以連接多個隊列。在上面的例子中，使用者1、2、3在系統(tǒng)中扮演等待隊列連接的使用者。它們需要用到(consume)結帳服務。也就是說，在該流程中，結帳操作將發(fā)送一條消息給交換節(jié)點。而此類交換是通過各種綁定(bindings)被連接到不同的隊列上。當然，我們可以通過綁定鍵(binding key)，來引用這些綁定，以方便它們進入應用程序中使用者服務的子隊列。