消息選擇器vs Tibco EMS上的消息過濾主題

Question

我正在使用Tibco EMS主題進行客戶/服務器通信的客戶端服務器應用程序。

在我們的一個用例，我們需要發送消息每劈了過來> 200K「科目」分鐘的幾百萬。

每個客戶都對他需要訂閱的一小部分主題感興趣。

的問題是，這些實現是比較合理的：

1. 送過來一個主題的所有消息，並使用消息選擇通過相關科目進行過濾。

2. 爲每個主題創建一個非靜態主題，並讓客戶端訂閱相關主題的主題。

Answer 1

消息選擇器據說會略微影響性能...這是有道理的。 所以基本上，你必須弄清楚權衡參數： 一方面，消息選擇器的利潤多少，另一方面，你能容忍他們的性能成本。

總之，諸如消息傳遞架構（您的問題）和容量/性能測試等活動最終會爲您提供答案。

關於信息架構，也有很多的問題要問：

• 有多少不同的學科，你呢？
• 如何動態是，列表（它經常變化）
  • 子問題：如何在客戶知道改名單的？
• 是否存在層次結構？

您的問題高度依賴於對象的類型和數量及其性質。

消息選擇器在主題相關時可能非常有用，而某些訂閱者只對一個子集感興趣。

示例1：一個Topic REPORTS，帶有JMS頭「ReportType」。 在這種情況下，某些客戶端migth傾向於對所有消息進行scrubscribe，而其他客戶端可能會訂閱「ReportType = Sales或ReportType = Weekly」。 如果主題列表一直在變化，那麼這個例子可能會非常粗略......什麼程序有興趣獲得所有的報告，事件是它不知道的事件（它們必須被自我描述爲有用的）

示例2：如果主題在層次結構中相關... EMS和MQ中的訂閱可以到一個特定的分支。想象一下3個主題：報告，報告，週報和報告.SALES 客戶可以在EMS中報告REPORTS。* ...這是在沒有消息選擇器的情況下完成的。

示例3：非靜態主題。在這個例子中，你隨時創建主題...但是不得不擔心許多事情：測試縮放比例，向客戶端獲取主題列表，管理主題的棄用，讓客戶端收聽很多主題（非常困難。 ..倍數連接???）等

祝你的設計，

邊注：至於你瞄準了......不要猶豫，看FTL性能（另一TIBCO產品）或像RabbitMQ這樣的產品，如果您的容量/性能測試不滿意EMS並且不介意丟失JMS功能。 EMS功能超強，可能需要很多，但其他產品可以更輕，更注重性能。