Pub/Sub 和基于内容的订阅答案

【问题标题】：Pub/Sub and Content-Based SubscriptionsPub/Sub 和基于内容的订阅
【发布时间】：2012-08-03 21:28:14
【问题描述】：

我正处于设计一个事件驱动架构（基本发布/订阅）的系统的初始阶段。尚未选择实际的工具和框架，所以这个问题是概念性的，而不是特定于技术的（尽管它将在 .Net 中完成）。

一个近乎完美的类比是金融交易系统。想象一个服务器不断接收市场数据（实时或间隔——没关系）。服务器将发布特定证券的定价更新。就这个问题而言，假设有 1000 种证券正在被服务器“观察”并发布。

有 100 个客户端应用程序订阅了此服务。每个客户只会对正在发行的证券的一小部分感兴趣。

如果客户端收到所有 1000 种证券的消息，则必须对其进行解析，这显然会增加网络流量并增加客户端的负载。

另一方面，必须在服务器端解析消息内容似乎会在发布/路由时增加负载。

在这种类型的架构中通常如何处理？

【问题讨论】：

我看过几个在 MVC4 应用程序中使用 SignalR (js) 的演示。 SignalR 将允许您将特定更新从服务器推送到每个单独的客户端。这将允许您根据每个客户端的需求进行过滤，并通过消除客户端轮询来减少网络流量。值得一试。

【解决方案1】：

看看 RabbitMQ 提供的一些教程

请特别注意，您可以使用路由和主题将消息传递给适用的客户端。这里的“服务器”“可以简单地将消息放到队列中，客户端可以简单地根据他们订阅的路由/主题监听某些消息。可能还有很多其他选项，但这似乎是一个不错的选择。RabbitMQ 有一些可用的 .Net 客户端，我对他们的产品非常满意。

我也使用过 IBM MQ 和 MSMQ，但我更喜欢 Rabbit。主要是因为它基于 AMQP，这是一个开放协议，让我可以使用 .Net、Python、Java 等进行连接，而不是专有驱动程序或尝试将所有内容包装在 JMS 中。绝不是专家，所以也许其他人对您的问题有更好的了解。

祝你好运。

【讨论】：

【解决方案2】：

通常，服务器是能够执行繁重任务的更强大的机器。由于客户端只需要信息的子集，我认为服务器应该解析信息并只向客户端发送他们需要的信息。

【讨论】：

【解决方案3】：

分发股票报价正是导致发布/订阅地址申请专利的用例，我们现在知道并喜欢 JMS 和其他消息传递技术中的“主题”（专利 EP0412232）。

在这种情况下，服务器将在包含股票代码的主题上发布股票报价（“报价”）...通常您会使用主题命名空间，它提供有关该代码的一些分层信息 - 例如NASDAQ.TECHNOLOGY.HARDWARE.AAPL。

客户端将使用主题通配符订阅一个符号或一组符号。发布/订阅机制将确保仅分发给正确的订阅者。使用多播网络可以使这非常有效。

因此，为了回答您的问题，在这种情况下，发布者（服务器）正在执行对消息进行分类所需的任何逻辑，然后在相关主题上发布。订阅者无需做太多工作即可获取相关消息。

【讨论】：

【解决方案4】：

根据您提供的简短描述，您的方案看起来非常适合 OMG DDS（数据分发服务）实施。这是一个语言中立的规范，有多种产品提供 C# API。

请参阅this Wikipedia entry 以获得非常简短的介绍和参考列表。

DDS 支持许多高级数据管理功能，例如强类型和内容感知数据总线、分布式状态管理和历史数据访问。其丰富的服务质量设置允许将大量复杂性从应用程序转移到中间件。

特别是，您描述的内容过滤要求是一项重要功能。一些可用的产品已经实现了复杂的过滤机制，这些机制可以很好地扩展，并且在网络上的流量与评估过滤器所需的 CPU 负载之间进行了明智的权衡。这些过滤器以 SQL 语法表示，例如 SELECT 的 WHERE 子句。

DDS 实施通常具有高度可扩展性和分散性。参与 DDS 基础设施的组件在空间和时间上都是解耦的。一些 DDS 产品部署在许多关键任务和业务关键系统中。

如果您有兴趣，那么我可以为您提供更多信息。我专注于 DDS 已有 10 多年了，我仍然喜欢它，我认为它是最有用的技术之一。

【讨论】：