Events 基于事件的消息传递系统（zeromq、OpenDDS等）

我正在尝试设计一个基于事件的消息传递系统，其工作原理如下：

假设一家商店里有多种产品，它们的价格每天都在变化。客户可以登录到该应用程序，并请求（通过SMS）知道特定日期（比如从登录日期起1个月）特定产品的价格

---

使用zeromq时如何引入事件的概念（如上所述）？OpenDDS更适合这样的场景吗

阅读您的用例与其说是“事件”，不如说是分布式访问建模对象（在本例中是您的产品）的“状态”（在本例中是潜在的历史价格）

DDS作为一种开放标准技术，通过使用发布/订阅消息与关系数据建模的智能组合，提供对共享数据的分布式访问，直接支持这一点。它还标准化并支持大量的服务质量（QoS）策略，这些策略既可以与数据的生产者/消费者相关，也可以与数据“自身”相关。在您的用例中，数据的“持久性”QoS将允许DDS基础设施维护数据对象的每个唯一标识的“实例”（在DDS术语中称为主题）的历史数据

在DDS方法中，重要的是为特定用例确定适当的“数据模型”，在您的情况下，它看起来非常简单，即产品具有唯一的产品代码（在DDS中是“关键属性”的ID，如在RDBMS中），可能是描述，然后是价格。每次价格变化时，将发布该数据类型的新“实例”，并且由于其QoS策略将被定义为持久性，因此将由中间件（通常由DDS实现的一个或多个“持久性服务”进行维护）

DDS中的应用程序订阅这些主题，并将自动提供产品主题的历史数据。一些DDS实现允许基于内容、时间和/或体积（数量）的组合指定历史数据交付的细化。在您的用例中，它将是“正确的产品”（通过ID或名称）和时间的选择

最后，假设您的系统是“网络支持的”，即应该在互联网规模上工作，可能支持基于云的数据永久存储，以便在PC、移动设备等上进行分布式访问。那么我建议您看看Vortex（www.prismtech.com/Vortex）。请注意，还提供了Vortex OpenSplice产品的开源版本（www.prismtech.com/dds community）

---

祝你好运

解决方案似乎需要结合三到四种不同的技术

（1） 一些存储技术，如数据库，用于保存长期信息和支持自定义查询。基本上保持“数据静止”。经典的RDBMS可能非常适合

（2） 一种消息传递技术，用于更新状态、获取状态更改通知、发出信号并协调不同应用程序和进程之间的集成。消息传递中间件技术，如DDS/RTPS、ZeroMQ、JMS/AMQP似乎最适合于此

（3） Web客户端和服务器技术。类似于客户端和Node.js的Java脚本或其他HTTP/REST后端

（4） 协议调解和集成技术。允许集成不同协议和技术的东西。例如，通过获取消息远程检测对数据库的更改，在HTTP/REST服务、消息传递技术和数据库之间进行集成，在SMS和后端之间进行集成，等等。Apache Camel和企业服务总线提供的各种功能

我和我最熟悉的建筑系统是以DDS为中心的信息平台。如果您选择DDS，那么不同的DDS供应商已经提供了很多这样的构建块。例如，在web上搜索时，我发现了与Apache Camel Integration和Node.js的集成。汉斯已经提到了PrismTech的Vortex。RTI已经准备好了与关系数据库（）的集成，因此在数据库上所做的任何更改都会反映在消息总线上，反之亦然，以及与Web/HTTP/REST（）和其他几种已经提到的Web技术的集成

您可以采取的另一种方法是围绕ESB开发您的方法，并使用它为不同技术提供的适配器。这可能是最简单的方法之一，但它有一个缺点，即所有内容都将由ESB代理，这可能对您的应用程序不重要，也可能对许多应用程序不重要。您可能想看看我写的这篇文章，其中描述了一些折衷：

---

杰拉尔多

对不起，我忘了提一个重要的细节。应用程序将无法访问数据库。它必须从网页中检索信息。因此，假设用户希望在1月1日知道产品的价格，那么应用程序必须在该特定日期访问该网站。另外，另一个细节是，产品的价格可以在一天中的任何时候更改。