0

我有一个问题如下:

服务器进程 1

  • 不断向数据存储发送发生的更新

服务器进程 2

  • 客户端联系服务器,服务器查询数据存储并返回结果

问题是,进程 1 和进程 2 发回客户端的结果是完全不同且不相关的。

如何分解这个?您是否只有一个进程不断发送数据,并将协议定义为具有对应于返回类型是 1 还是 2 的位?

你有两个过程吗?那么他们如何共享数据存储(它只是一个结构而不是数据库)?

谢谢!

4

3 回答 3

1

听起来您想在“某处”流式传输您的一系列整数,并将它们收集在数据存储中。在我的系统中,我将传感器读数流式传输到数据库中,并允许它们直接访问 Web 客户端,为它们提供实时功率读数。我写了一篇关于为什么数据库不适合实时数据的博客文章——尽管它非常适合保存数据以供以后分析。

我会让第一个服务器进程成为一个扭曲的服务器,它使用txamp将整数流式传输到RabbitMQ。任何需要实时数据的客户端都可以订阅 RabbitMQ 中的流,也可以使用 Txamp。Web 浏览器客户端可以使用Orbited 这里是一个工作示例

在您的设计服务器 1 中保存到数据库。您可以改为让 server3 从 RabbitMQ 收集数据并将其流式传输到数据库。我计划有一个服务器来收集数据块并渲染图形以存储到中央文件共享。

不要创建自己的消息传递系统,RabbitMQ 已经过良好测试、可扩展,并且可以在出现问题时保留您的“消息”(原始数据)。

于 2009-10-01T23:28:36.670 回答
1

如果您可以限制自己使用 Twisted,我建议使用Perspective Broker。它本质上是一个 RPC 系统,不太关心“客户端”和“服务器”的概念——无论是 TCP 连接的发起者还是响应者都可以在 PB 中启动 RPC 调用。

因此服务器 1 将接受带有回调对象的注册调用,并在有新数据可用时调用回调。服务器 2 根据客户端的需要提供各种 RPC 操作。如果它们对相同的数据进行操作,我会将两台服务器放在一个进程中。

于 2009-10-01T20:41:30.477 回答
0

为什么不使用数据库而不是“只是一个结构”?关系数据库和非关系数据库都提供了许多实际优势(使用它们的单独进程,处理复制[[和/或快照,备份,...]],如果您需要“查询”时提供丰富的功能,等等等等)。

最坏的情况是,“只是一个结构”可以由完全专用于它的第三个进程处理(基本上模仿任何数据库引擎会提供的东西——尽管引擎可能会做得更好更快;-),让你在至少保持良好的分解(两个服务器进程都与“数据存储进程”交互)。

于 2009-10-01T20:16:28.307 回答