消息隊列知識點總結

本文中将會介紹有關于消息隊列(後文中統稱MQ)的概念、特點以及使用場景等相關知識點。希望這些知識點能夠幫助大家更清晰、更準确的利用好MQ這一大利器。如果MQ使用得當，則可以增加工程的可擴充性和資料處理效率；若使用不得當，則反而會加劇工程的結構複雜度以及資料一緻性等問題。

筆者也會将自己的了解在文中進行闡述，這也算是在和大家交流心得的一個過程。若文中有錯誤的了解和概念，請大家及時糾正；吸納大家的建議，對于我來說也是很重要的學習過程之一。

1.适用場景

在以下三類場景中，通常會選擇使用MQ來實作:

1. 資料的異步處理

   即能夠協助我們将原本通過

   同步操作實作的邏輯改造為通過異步操作實作的流程

   。憑借着異步并發的優勢，異步操作可以更有效的利用現有的計算資源。

   同時，也可用于

   一份資料會被多方使用的場景

   ，例如訂閱模型。

2. 系統應用解耦

   即能夠用來協助我們拆分複雜的工程，實作

   大工程的功能解耦

   需求。即用來解決服務與服務之間的緊耦合問題。

3. 業務流量削峰

   即能夠用來防止短時間内的高流量沖垮後端伺服器以及資料庫，

   即可用作緩沖層來使用

   。

   适用于那些想防止因短時間内有大量請求而導緻服務無法正常工作的場景，即使用MQ來緩存資料。

Tips:

筆者認為可以從上述的适用場景中分析出一些MQ的特性。而這些特性，是可以用來作為判斷MQ是否适用于指定場景的判斷依據。筆者認為MQ的特性有以下幾點:

1. 消息延遲性

   MQ适合那些對于消息處理不追求實時性的場景,

   即可以接受消息延遲處理的場景

   。

1. 業務邏輯異步化

   使用MQ為業務邏輯做異步化之前，要先仔細考量

   相關邏輯是否能夠更改為異步方式運作

   。

   往往一些過于關系緊密的邏輯，是不适合改造成異步方式運作的。因為針對于異步處理的復原是不容易實作的。

   其次，當邏輯改造為異步并發操作後，

   會不會給資料帶來不一緻性等類似問題

   ，也是需要仔細考量的一點。

1. 資料處理順序

   MQ隻适用于那些

   對于資料處理沒有順序要求

   的業務。

2.架構抽象

對于一個消息隊列而言,可以

拆解為四部分：消息、生産者叢集、消息隊列叢集、消費者叢集

。消息是從生産者流向消息隊列叢集，最終再從消息隊列叢集流向消費者，即生産消費模型。

了解消息隊列的架構能夠幫助我們更好的認識其優缺點，以便更正确的使用MQ。後續篇章會基于該抽象來分别對架構中的每一部分進行介紹。

2.1 消息

消息其本質是一條資料

，這類資料被消息隊列封裝後也被稱為一條消息。該條消息隻能發送到其消息隊列叢集内部的一個分區隊列中。是以隻需按照一定的政策從多個隊列中選擇一個隊列即可。

Tips:

筆者認為，消息作為消息隊列模型中的資料載體，是貫穿整個消息隊列工作流程的。消息隊列的工作流程也可以看為是消息的生命周期轉換過程，即經曆了"消息誕生-消息流轉-消息處理"這一生命周期。

消息的資料結構也會影響到整個工作流中的部分細節。例如可以通過消息中某些字段的值來對消息進行精準路由等。

是以，對于消息的資料結構設計也是使用好MQ的一個重要因素。

2.2 生産者叢集

生産者叢集的主要功能為生産資料，即産出消息

。通常也稱為資料的輸入提供方。

對于生産者的實作方式，主要有以下兩種:

1. 用戶端

   在大多數場景中，生産者是作為用戶端的方式存在。

2. 服務端

   在支援事務消息的消息隊列中，生産者會被設計為服務端，實作事務消息這一特性。

Tips: 因為消息隊列叢集需要通過調用生産者的接口來擷取本地事務的執行情況，以用來判斷後續應選擇什麼樣的消息處理機制應。

生産者叢集中往往會有多個生産者同時工作，以提高資料的産出速度。消息隊列叢集内部也會有多個分區隊列，是以在

多個生産者在發送資料時通常會存在負載均衡的一些政策

。常見的有按 key hash、輪詢、随機等方式。

2.3 消息隊列叢集

消息隊列叢集的主要功能為存儲消息、過濾消息和分發消息。

2.3.1 存儲消息

顧名思義，消息隊列是可以用來

儲存消息資料

的，但這裡的儲存是

暫存

的含義。即消息不應長期堆積在消息隊列中，不應使用消息隊列作為消息資料持久化的手段。

同時，一個消息隊列吞吐量的高低、性能優劣都和它的存儲模型脫不開關系。

2.3.2 過濾消息

過濾消息隻指消息隊列可以通過一定的規則或者政策進行消息的過濾，

該項能力通常也被稱為消息路由

。

消息路由一般會影響消息資料在消息隊列叢集中的分布情況。例如可以通過利用這點，将重要消息路由到可靠性較高的叢集節點上；或将按照地理位置将消息路由到鄰接的叢集節點上，使得消費者能夠以最小的網絡延遲消費到資料。

2.3.3 分發消息

分發消息是指消息隊列通常需要

将消息分發給處理同一邏輯的多個消費者處理或者處理不同邏輯的不同消費者處理

。

分發消息可以說和消費者模型相挂鈎

，因為不同的消費者模型有着不同的資料擷取方式。此外絕大部分的消息隊列也都支援對消息進行分類，分類的标簽稱為topic（主題），一個topic中存放的是同一類消息。

2.4 消費者叢集

消費者叢集的主要功能為處理消息資料。消費者也可以看做消息隊列中資料的輸出方。

在章節2.3.3中提到過，消息隊列分發消息的方式是和消費者模型有密切關系的。這裡的模型通常是指消費者的資料方式和消費者模型，本章節中會通過這兩方面來介紹消費者叢集。

2.4.1 消息擷取方式

消費者通常有兩種方式從消息隊列中擷取資料：推送（push）資料、拉取（pull）資料。這裡提供一些這兩種方式各自的優缺點：

1. 消息實時性強

   因為消息隊列拿到消息後就會馬上推送給相應的消費者。

2. 消費者資源利用不充分

   這種方式下，消息流轉的速率是由消息隊列控制的。此時，若所有的消費者都有這相同的消息處理速度，則沒有任何資源浪費。但實際情況中，消費者之間往往會因為計算資源等其他因素而導緻每一個消費者的消息處理速度不用。又因為消息發送速率是相同的，則此時就有可能會發生有些消費者消費的快進而出現等待消息的情況。

3. 消耗存儲資源

   由于2中所描述的問題，會導緻消息隊列需要儲存因消費者消費速度慢而産生的堆積消息資料。同時如果消費失敗，則消息隊列還需要儲存這些失敗消息資料以用于後續的重試。是以會消耗消息隊列的一部分存儲資源。

1. 消息實時性弱

   消費者需要定期詢問消息隊列是否有消息可以進行消費，是一個被動操作。

2. 消費者資源利用充分

   在此方式下，消息的處理速度是由消費者控制的。是以消費者可以根據自身的處理能力，選擇合适的消費速度來進行消息處理。消費快的消費者就會多消費消息，而消費慢的消費者會少消費消息。

3. 消耗網絡資源

   如1中所描述，消費者需要和消息隊列之間建立長連接配接，不間斷的詢問消息隊列是否有新消息可以進行消費。即會消耗消息隊列的網絡資源。

2.4.2 消費者模型