訊息佇列應用場景介紹

一、什麼是佇列

佇列（Queue）是一種常見的資料結構，其最大的特點就是先進先出（First In First Out），作為最基礎的資料結構，佇列應用很廣泛。比如火車站排隊買票等等。可以用下圖表示佇列：

其中a1、a2、an表示佇列中的資料。資料從隊尾入佇列，然後從隊頭出佇列。

二、什麼是訊息佇列

訊息佇列（Message Queue）是一種使用佇列（Queue）作為底層儲存資料結構，可以用於解決不同程序與應用程式之間通訊的分散式訊息容器，也可以稱為訊息中介軟體。

目前比較常用的訊息佇列有ActiveMQ、RabbitMQ、Kafka、RocketMQ、Redis等。

訊息佇列和佇列有什麼區別呢？

唯一的區別在於入佇列的時候稱為生產者，出佇列的時候稱為消費者。

三、訊息佇列應用場景

訊息佇列應用場景非常廣泛，下面我們列舉比較常見的幾個場景

1、分散式場景

1.1、非同步處理

一般我們寫的程式都是按照順序執行的（即同步的方式）。比如電商系統中訂單的例子，其執行順序如下：

使用者提交訂單。訂單完成以後增加積分。發生積分變動的簡訊通知。

可以用下面的流程圖表示：

如果按照上面的順序執行，假如每個服務都需要花費一秒，那麼使用者端就要花費3秒的時間。對於使用者來說，3秒的時間顯然是不能忍受的，那麼我們該如何解決呢？我們可以使用非同步的方式來解決這個問題，看下面一張流程圖：

按照這種方式，積分服務和簡訊服務使用執行緒非同步的方式進行操作，那麼使用者端只需要花費1秒的時間就可以完成了。但是，這種非同步的方式會帶來另外的問題：並行量降低。因為積分服務和簡訊服務都需要在訂單服務裡面開啟執行緒，開啟的執行緒多了，會導致使用者端存取訂單服務的並行量降低，可能導致使用者端提交訂單的實際時間會超過1秒鐘。那麼如何解決非同步帶來的問題呢？那就是使用訊息佇列，看下面的流程圖：

在上面的流程中，我們增加了一個訊息佇列的角色，首先由使用者端提交訂單，然後把訂單寫入到訊息佇列，積分服務和簡訊服務同時去消費訊息佇列裡面的訊息，這種方式不需要訂單服務在額外的開啟非同步執行緒，使用者端可以實現真正的耗時1秒。

1.2、應用解耦

我們還是以電商系統為例進行講解，先看下面的流程圖：

上圖的業務邏輯：使用者端發起一個建立訂單的請求，建立訂單的時候，我們要先獲取庫存，然後在去扣減庫存，這樣訂單系統和庫存系統就形成了非常緊密的依賴關係。假如這時候庫存系統發生了宕機，由於訂單系統依賴於庫存系統，這時候訂單系統將不能使用。那麼如何解決呢？

看下面使用訊息佇列的流程圖：

在上面的流程中，我們加入了訊息佇列。首先使用者端發起建立訂單的請求，訂單的訊息寫入到訊息佇列裡面，然後庫存系統去訊息佇列裡面訂閱訊息，最後非同步的去更新庫存系統。如果庫存系統發生了宕機，由於訂單系統不直接依賴於庫存系統，所以訂單系統可以正常的響應使用者端的請求。這樣就實現了應用解耦。

1.3、流量削峰

對於高並行的系統來說，在存取高峰時，突發的流量就像洪水般湧向應用系統，尤其是一些高並行寫操作，隨時會導致資料庫伺服器癱瘓，無法繼續提供服務。

而引入訊息佇列則可以減少突發流量對應用系統的衝擊。消費佇列就像“水庫”一樣，攔截上游的洪水，削減進入下游河道的洪峰流量，從而達到減免洪水災害的目的。

在這方面最常見的例子就是秒殺系統，一般秒殺活動瞬間流量很高，如果流量全部湧向秒殺系統，會壓垮秒殺系統，通過引入訊息佇列，可以有效緩衝突發流量，達到“削峰”的作用。

我們使用秒殺的場景來描述流量削峰，先看下面一張流程圖：

在上面的流程中，我們把秒殺服務稱為上游服務，訂單服務、庫存服務、餘額服務統稱為下游服務。使用者端發起秒殺的請求，秒殺服務收到使用者端傳送的請求以後，建立訂單，修改庫存，扣減餘額，這是秒殺的基本業務場景。

假如下游服務只能同時處理1000個並行請求，上游服務可以處理10000個並行請求，而使用者端發起了10000個請求，超出了下游服務可以處理的並行量，所以會導致下游服務發生宕機。這時就可以加入訊息佇列來解決宕機的問題。看下面加入訊息佇列的流程圖：

我們在上面的流程圖中加入了訊息佇列，描述服務接收到使用者端傳送的10000個請求以後，把所有的請求都寫入到訊息佇列中，然後下游服務去訂閱訊息佇列裡面的秒殺請求，然後在去執行自己的業務邏輯操作。

我們舉個簡單的例子，上游服務還是能處理10000個並行請求，下游服務還是隻能處理1000個並行請求，那麼這時候我們在訊息佇列裡面會允許存1000個並行請求。上游的秒殺服務接收到10000個並行請求，而訊息佇列裡面只能存1000個請求，多餘的請求就不會存入到訊息佇列裡面，直接返回給使用者端提示“系統繁忙，請稍後！”。這就是所謂的流量削峰場景。這是由下游服務可以處理的並行量決定的。由於下游服務只能處理1000個並行請求，所以訊息佇列裡面只能存1000個秒殺，多餘的秒殺請求全部返回使用者端提示。這樣就保證了下游服務的正常響應，不會導致下游服務發生宕機，提高了系統的可用性。

2、紀錄檔場景

優化紀錄檔傳輸

為了程式的健壯性，我們一般會在程式中新增各種記錄紀錄檔的功能，比如錯誤紀錄檔、操作紀錄檔等等，看下面一張流程圖：

上面的流程圖是同步記錄紀錄檔的流程。使用同步記錄紀錄檔的流程，會使得整個流程花費的時間增多，而且也會容易造成業務系統宕機（如果資料庫損壞了，向資料庫記錄紀錄檔的操作將會產生錯誤）。我們可以使用訊息佇列的方式優化紀錄檔的傳輸。看下面的流程圖：

加入了訊息佇列以後，可以縮短系統花費的時間，而且也可以達到應用系統解耦的功能。

3、及時通訊場景

聊天室

訊息佇列最主要功能是收發訊息，其內部有高效的通訊機制，因此非常適合用於訊息通訊。

我們可以基於訊息佇列開發對等的聊天系統，也可以開發廣播系統，用於將訊息廣播給大量接收者。

到此這篇關於訊息佇列應用場景的文章就介紹到這了。希望對大家的學習有所幫助，也希望大家多多支援it145.com。