我正在尝试设计一个基于事件的消息系统，其工作方式如下：
我们假设商店里有多种商品，价格每天都有所不同。客户可以登录该应用程序，并请求（通过短信）知道特定日期（特别是登录日期后1个月）特定产品的价格。
使用zeromq时如何引入事件概念（如上所述）？ OpenDDS更适合这种情况吗？
答案 0 :(得分：0)
阅读您的用例可能更少关于“事件”，而不是分布式访问建模对象（在本例中为您的产品）的“州”（在这种情况下是潜在的历史价格）。
DDS作为一种开放标准技术，通过结合关系数据建模的发布/订阅消息的智能组合，提供对共享数据的分布式访问，直接支持这一点。它还标准化并支持大量服务质量（QoS）策略，这些策略可以与数据的生产者/消费者以及数据“本身”相关。在您的用例中，数据的“持久性”QoS将允许DDS基础架构维护数据对象的每个唯一标识的“实例”的历史数据（在DDS术语中称为主题）。
在DDS方法中，重要的是确定特定用例的正确“数据模型”，在您的情况下，它看起来非常简单，即具有唯一产品代码的产品（ID将会在DDS中是一个“关键属性”，就像在RDBMS中一样，可能是描述，然后是价格。每次价格变化时，将发布该数据类型的新“实例”，并且其QoS策略将被定义为PERSISTENT，然后由中间件维护（通常由一个或多个'耐久性服务'维护DDS实施的一部分）
DDS中的应用程序会订阅这些主题，并会自动提供产品主题的历史数据。一些DDS实现允许基于内容，时间和/或量（量）的组合来指定用于递送历史数据的细化。在您的用例中，可以选择“正确的产品”（按ID或名称）和时间。
最后，假设您的系统是'支持网络'，即应该在互联网规模上工作，可能支持基于云的永久存储数据，以便在PC，移动设备等上进行分布式访问。那么我建议看看Vortex（www.prismtech.com/vortex）。请注意，还提供了Vortex OpenSplice产品的开源版本（www.prismtech.com/dds-community）。
祝你好运！答案 1 :(得分：0)
似乎解决方案需要结合三种或四种不同的技术。
（1）一些存储技术，如数据库，用于保存长期信息并支持自定义查询。基本上是保持＆＃34;数据休息＆＃34;。经典的RDBMS可能非常合适。
（2）一种消息传递技术，用于更新状态，获取状态变化的通知，信号和协调不同应用程序和进程之间的集成。消息传递中间件技术，如DDS / RTPS，ZeroMQ，JMS / AMQP似乎是最好的。
（3）Web客户端和服务器技术。像客户端和Node.js或其他一些HTTP / REST后端的Java Script。
（4）协议调解和集成技术。允许集成不同协议和技术的东西。例如。通过获取消息，在HTTP / REST服务，消息传递技术和数据库之间进行集成，在SMS和后端之间进行集成等来远程检测对数据库的更改.Apache Camel和Enterprise Service总线提供的各种事物。< / p>
我最熟悉构建以DDS为中心的系统作为消息传递平台。如果您选择DDS，那么不同的DDS供应商已经提供了很多这些构建模块。例如，在网上搜索我发现与Apache Camel Integration和Node.js的集成。汉斯已经提到了PrismTech的Vortex。 RTI已经与关系数据库（https://www.rti.com/products/dds/database-integration.html）进行了现成的集成，因此对数据库所做的任何更改都会反映在消息总线上，反之亦然，以及与Web / HTTP / REST的集成（{{3} }），以及其他几个已经提到过的Web技术。
您可以采取的另一种方法是开发以某些ESB为中心的方法，并使用它为不同技术提供的适配器。这可能是最简单的方法之一，但它的缺点是所有内容都将由ESB代理，这可能或许多对您的应用程序无关紧要。你可能想看看我写的这篇文章，其中我描述了一些权衡：http://www.slideshare.net/GerardoPardo/london-connext-dds-conference-web-enabled-dds
了Gerardo