在發佈 - 訂閱系統中處理事件的不同方式有哪些？

Question

在一個發佈 - 訂閱系統中，每個用戶等待幾種類型的事件，是否有比簡單的交換機更好的處理解決方案？

假設我們有2個發佈者，Pub1和Pub2; Pub1發送兩種類型的事件Pub1-eventA和Pub1-eventB，與Pub2相同，分別爲Pub2-eventA和Pub2-eventB

另一方面，我們有一個客戶端Sub1訂閱Pub1和Pub2的事件;

你將如何管理在Sub1監聽器中處理這些事件？

這裏一些可能性：

一個監聽器，一個大的開關（難以維持）：

Listener{ 

    HandleEvent(event){ 

    if(event.type == Pub1-eventA) 
     Action1.execute(); 
    if(event.type == Pub1-eventB) 
     Action2.execute(); 
    if(event.type == Pub2-eventA) 
     Action3.execute(); 
    if(event.type == Pub2-eventB) 
     Action4.execute(); 

    } 

} 

一個偵聽器和一個關聯映射：

各事件類型

Map<event-type, Action> ActionMap 

Listener{ 

     Action = ActionMap[event-type] 

     Action.execute(); 
} 

一個聽衆：

ListenerPub1-eventA{ check(event-type); Action1.execute(); } 
ListenerPub1-eventB{ check(event-type); Action2.execute(); } 
ListenerPub2-eventA{ check(event-type); Action3.execute(); } 
ListenerPub2-eventB{ check(event-type); Action4.execute(); } 

Answer 1

在「一個聽衆，一個大開關」和「一個聽衆和一個關聯地圖」中，每個事件仍然會以一種單獨的方法結束，但您必須在代碼中維護事件的調度。

發佈 - 訂閱消息系統最重要的貢獻是將發佈者和訂閱者分離。所以消息路由應該是你的中間件的責任。如果你的中間件是不能消息路由，那麼我建議去爲每個事件類型的一個偵聽器，以便：

1. 您不必維護消息路由/自行調度
2. 每個聽衆將有一個單一的責任
3. 如果有任何擴大規模的情況下，你可以添加更多的偵聽器的任何消息類型，而不會觸及不相關的監聽器。

這就是我能想到的。

我希望這會有所幫助。