消息选择器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功能超强，可能需要很多，但其他产品可以更轻，更注重性能。