一 訊息佇列

2022-09-02 21:42:19 字數 2686 閱讀 3184

訊息佇列(message queue,簡稱為mq)是一種應用間的通訊方式,訊息傳送後可以立即返回,由訊息系統來確保訊息的可靠傳遞。訊息發布者只管把訊息發布到 mq 中而不用管誰來取,訊息使用者只管從 mq 中取訊息而不管是誰發布的。這樣發布者和使用者都不用知道對方的存在。

訊息佇列中介軟體是分布式系統中重要的元件,主要解決應用耦合、非同步訊息、流量削鋒等問題。實現高效能、高可用、可伸縮和最終一致性架構。是大型分布式系統不可缺少的中介軟體。

目前在生產環境,使用較多的訊息佇列有activemq、rabbitmq、kafka、rocketmq等。

訊息佇列在實際應用中常用的使用場景分為

場景說明:使用者註冊後,需要傳送註冊郵件和傳送註冊資訊,傳統的做法有兩種:

序列方式

將註冊資訊寫入資料庫成功後,傳送註冊郵件,然後傳送註冊簡訊,而所有任務執行完成後,返回資訊給客戶端

並行方式

將註冊資訊寫入資料庫成功後,同時進行傳送註冊郵件和傳送註冊簡訊的操作。而所有任務執行完成後,返回資訊給客戶端。同序列方式相比,並行方式可以提高執行效率,減少執行時間

上面的比較可以發現,假設三個操作均需要50ms的執行時間,排除網路因素,則最終執行完成,序列方式需要150ms,而並行方式需要100ms。

由上可以看出,傳統序列和並行的方式會受到系統效能的侷限,那麼如何解決這個問題?

由此可以引入訊息佇列,將不是必須的業務邏輯,非同步進行處理,由此改造出來的流程為

根據上述的流程,使用者的響應時間基本相當於將使用者資料寫入資料庫的時間,傳送註冊郵件、傳送註冊簡訊的訊息在寫入訊息佇列後,即可返回執行結果,寫入訊息佇列的時間很快,幾乎可以忽略。

場景說明:使用者下單後,訂單系統需要通知庫存系統。

傳統的做法為:訂單系統呼叫庫存系統的介面。如下圖所示:

這種傳統方式的缺點是:

解決缺點,需要引入訊息佇列,引入訊息佇列後的架構如下圖所示:

假如在下單時庫存系統不能正常使用。也不影響正常下單,因為下單後,訂單系統寫入訊息佇列就不再關心其後續操作了。由此實現了訂單系統與庫存系統的應用解耦。

應用場景:秒殺活動,一般會因為流量過大,導致流量暴增,應用掛掉。為解決這個問題,一般需要在應用前端加入訊息佇列。

可以控制參與活動的人數;

可以緩解短時間內高流量對應用的巨大壓力;

流量削鋒處理方式系統圖如下:

伺服器在接收到使用者請求後,首先寫入訊息佇列。這時如果訊息佇列中訊息數量超過最大數量,則直接拒絕使用者請求或返回跳轉到錯誤頁面;

秒殺業務根據秒殺規則讀取訊息佇列中的請求資訊,進行後續處理。

日誌處理是指將訊息佇列用在日誌處理中,比如kafka的應用,解決大量日誌傳輸的問題。架構簡化如下:

kafka:接收使用者日誌的訊息佇列。

logstash:做日誌解析,統一成json輸出給elasticsearch。

elasticsearch:實時日誌分析服務的核心技術,乙個schemaless,實時的資料儲存服務,通過index組織資料,兼具強大的搜尋和統計功能。

kibana:基於elasticsearch的資料視覺化元件,超強的資料視覺化能力是眾多公司選擇elk stack的重要原因。

訊息通訊是指,訊息佇列一般都內建了高效的通訊機制,因此也可以用在純的訊息通訊。比如實現點對點訊息佇列、聊天室等。

點對點通訊

在點對點通訊架構設計中,客戶端a和客戶端b共用乙個訊息佇列,即可實現訊息通訊功能。

聊天室通訊

客戶端a、客戶端b、直至客戶端n訂閱同一訊息佇列,進行訊息的發布與接收,即可實現聊天通訊方案架構設計。

訊息佇列採用高可用、可持久化的訊息中介軟體。比如active mq,rabbit mq,rocket mq。

參考:

大型**架構系列:分布式訊息佇列(一)

訊息佇列(一)

訊息佇列與pipe類似,但是存在兩個區別 message boundaries are preserved,so that readers and writes communicate in units of messages,rather than via an undelimited byte ...

訊息佇列(一)

在不使用訊息佇列伺服器的時候,使用者的請求資料直接寫入資料庫,在高併發的情況下資料庫壓力劇增,使得響應速度變慢。但是在使用訊息佇列之後,使用者的請求資料傳送給訊息佇列之後立即返回,再由訊息佇列的消費者程序從訊息佇列中獲取資料,非同步寫入資料庫。由於訊息佇列伺服器處理速度快於資料庫 訊息佇列也比資料庫...

訊息佇列 訊息佇列

輪詢排程 一次性分發所有訊息,保證訊息平均分配,不管消費者是否能正常消費 訊息應答 保證消費端能確實消費,不丟失 公平 乙個乙個分發所有訊息,在保證分發到的執行緒確認回覆後,才分發下個訊息給下個空閒的消費者,訊息持久化 保證佇列中的訊息不丟失,包括3要素 交換器 訊息佇列 訊息都必須宣告持久化 發布...