1. 程式人生 > >訊息佇列-M.Q.

訊息佇列-M.Q.

為什麼會需要訊息佇列(MQ)?

主要原因是由於在高併發環境下,由於來不及同步處理,請求往往會發生堵塞;
通過使用訊息佇列,我們可以非同步處理請求,從而緩解系統的壓力。

訊息通道(Message-Channel)模式:

訊息通道通常以佇列的形式存在,這種先進先出的資料結構無疑最為適合這種處理訊息的場景。
通常情況下,釋出者和訂閱者都會被註冊到用於傳播變更的基礎設施(即訊息通道)上。

釋出者-訂閱者(Publisher-Subscriber)模式:

一旦訊息通道需要支援多個消費者時,就可能面臨兩種模型的選擇:

拉模型與推模型。拉模型是由訊息的消費者發起的,主動權把握在消費者手中,它會根據自己的情況對生產者發起呼叫。拉模型

的另一種體現則由生產者在狀態發生變更時,通知消費者其狀態發生了改變。但得到通知的消費者卻會以回撥方式,通過呼叫傳遞過來的消費者物件獲取更多細節訊息。

推模型的主動權常常掌握在生產者手中,消費者被動地等待生產者發出的通知,這就要求生產者必須瞭解消費者的相關資訊。對於推模型而言,消費者無需瞭解生產者。在生產者通知消費者時,傳遞的往往是訊息(或事件),而非生產者自身。同時,生產者還可以根據不同的情況,註冊不同的消費者,又或者在封裝的通知邏輯中,根據不同的狀態變化,通知不同的消費者。

兩種模型各有優勢。拉模型的好處在於可以進一步解除消費者對通道的依賴,通過後臺任務去定期訪問訊息通道。壞處是需要引入一個單獨的服務程序,以Schedule形式執行。而對於推模型而言,訊息通道事實上會作為消費者觀察的主體,一旦發現訊息進入,就會通知消費者執行對訊息的處理

。無論推模型,拉模型,對於訊息物件而言,都可能採用類似Observer模式的機制,實現消費者對生產者的訂閱,因此這種機制通常又被稱為Publisher-Subscriber模式。

釋出者會主動地瞭解訊息通道,使其能夠將訊息傳送到通道中;訊息通道一旦接收到訊息,會主動地呼叫註冊在通道中的訂閱者,進而完成對訊息內容的消費。

對於訂閱者,有這兩種訊息的處理方式:
1.廣播機制;
2.搶佔機制。

訊息路由(Message-Router)模式:

通過訊息路由,我們可以配置路由規則指定訊息傳遞的路徑,以及指定具體的消費者消費對應的生產者。例如指定路由的關鍵字,並由它來繫結具體的佇列與指定的生產者(或消費者)。路由的支援提供了訊息傳遞與處理的靈活性,也有利於提高整個系統的訊息處理能力。同時,路由物件有效地封裝了尋找與匹配訊息路徑的邏輯,就好似一個調停者(Meditator),負責協調訊息、佇列與路徑定址之間關係。

Messaging模式提供了一個通訊基礎架構,使得我們可以將獨立開發的服務整合到一個完整的系統中。

Message Translator模式則完成對訊息的解析,使得不同的訊息通道能夠接收和識別不同格式的訊息。而且通過引入這樣的物件,也能夠很好地避免出現盤根錯節,彼此依賴的多個服務。

Message Bus模式可以為企業提供一個面向服務的體系架構。它可以完成對訊息的傳遞,對服務的適配與協調管理,並要求這些服務以統一的方式完成協作。