比如某系統有三個子系統，登入系統、積分系統群、日誌系統群。

一個使用者登入了系統，將傳送通知給積分系統叢集和日誌系統叢集，要求積分系統叢集和日誌系統叢集都能接收到完整的登入實現通知，類似於主題模式，同時在其中任一個系統群中不能讓一個訊息被叢集中的多個系統重複處理，這類似於佇列模式。

實際業務場景特點:

子業務系統都有叢集的可能性

同一個訊息會廣播給關注該類訊息的所有子業務系統

同一類訊息在叢集中被負載消費

業務的發生和訊息的釋出最終一致性

需要解決的問題:

不同業務系統分別處理同一訊息，同一業務系統負載處理同類訊息 解決訊息傳送時的一致性問題 解決訊息處理時的冪等性問題 基於訊息機制建立事件匯流排

問題:不同業務系統分別處理同一訊息，同一業務系統負載處理同類訊息

使用ActiveMQ的虛擬主題解決方案

釋出者:

將訊息釋出到一個主題中，主題名以VirtualTopic開頭，如VirtualTopic.TEST

消費者:

從佇列中獲取資訊，在佇列名中表明自己身份，如Consumer.A.VirtualTopic.TEST，通過這種方式把主題中的訊息自動中轉到佇列中，由佇列負載處理 此流程類似於下圖:

問題:解決訊息傳送時的一致性問題

使用記憶體日誌的解決方案

記憶體日誌可持久化到本地檔案，同時支援叢集複製，若當前業務子系統掛掉也能保證訊息不丟失

問題:解決訊息處理時的冪等性問題

所謂冪等，簡單地說，就是對介面的多次呼叫所產生的結果和呼叫一次是一致的。擴充套件一下，這裡的介面，可以理解為對外發布的HTTP介面或者Thrift介面，也可以是接收訊息的內部介面，甚至是一個內部方法或操作。

那麼我們為什麼需要介面具有冪等性呢？設想一下以下情形：

• 在App中下訂單的時候，點選確認之後，沒反應，就又點選了幾次。在這種情況下，如果無法保證該介面的冪等性，那麼將會出現重複下單問題。
• 在接收訊息的時候，訊息推送重複。如果處理訊息的介面無法保證冪等，那麼重複消費訊息產生的影響可能會非常大。

使用記憶體日誌的解決方案

消費者在接收訊息後，去記憶體日誌中查詢該訊息是否被處理過，若沒有，則呼叫業務進行處理，處理成功後更新記憶體日誌，確認訊息。

問題:基於訊息機制建立事件匯流排

系統之間的訊息釋出類似於事件，傳送者就是事件的發起人，消費者就是事件的影響人，這樣的架構方式稱為事件驅動。

什麼是事件驅動架構?

事件驅動架構(EDA)定義了一個設計和實現一個應用系統的方法學，在這個系統裡事件可傳輸於鬆散耦合的元件和服務之間。簡單來說一句話"有事我叫你，沒事別煩我"

事件驅動架構模型

首先有三個業務系統，使用一個事件匯流排簡化業務系統之間的事件釋出，業務系統B、C通過事件匯流排提供的方法進行事件註冊，業務發起系統A使用事件匯流排提供的方法發起事件，這樣事件匯流排就封裝了訊息的傳送和接收以及記憶體日誌的處理，但這樣事件匯流排還不具備訊息中介軟體的功能，所以事件匯流排還需定義一個抽象的訊息提供者，再根據不同的訊息中介軟體提供具體的訊息提供者，比如"activemq等"