0

我们有一个持续处理大量文件的现有系统。粗略地说，每天大约有 300 万个文件，大小从几千字节到超过 50 MB 不等。这些文件从收到文件到完成使用，会经历几个不同的处理阶段，具体取决于它们所采用的路径。由于这些文件的内容和格式，它们不能被分解成更小的块。

目前，这些文件通过的工作流是僵化的，并且由具有固定输入和输出的代码决定（在许多情况下，一个订阅者成为一组新文件的发布者）。然而，这种缺乏灵活性开始给我们带来问题，所以我正在寻找某种能够处理新需求的发布/订阅解决方案。

大多数传统的发布/订阅解决方案都将数据包含在实际有效负载中，但潜在的大文件大小超出了许多消息传递平台的限制。此外，我们有多个平台在使用：文件根据其路径在 Linux 和 Windows 层中前进。

有没有人考虑到以下目标的任何设计和/或实施建议？
1. pub 和 sub（Linux 和 Windows）的多平台
2. 持久存储/存储和转发支持
3. 可以处理大型事件有效负载并在所有订阅者都得到服务后适当清理
4. 路由/工作流通过配置完成
5. 订阅者可以根据变化的标准订阅一组过滤的已发布事件（例如，只给我特定类型的文件）

我已经对许多服务总线和 MQ 实现进行了大量研究，但还没有完全确定足够的设计方法来正确评估哪些工具最有意义。感谢您的任何意见。

4

2 回答 2

0

A1。我在以前的工作中开发了类似的系统。我们没有在消息中传递多 MB 的有效负载，而是将其存储在文件服务器上，并且只传递了 UNC 文件名（消息是 Java RMI，但几乎任何东西都可以工作）。

A2。我最近开始使用 Windows Communication Foundation。对我来说幸运的是，我只支持 Windows，不需要这么大的消息。但是文档说该协议是独立于平台的，并且可以选择使用其流式消息传输功能来传递大量数据。

在这两种情况下，我认为您必须在自己的代码中满足您的#4 和#5 要求。

于 2010-09-01T18:27:38.027 回答
0

如果您的客户端是内部客户端，您可能需要查看 ActiveMQ。ActiveMQ 确实支持高达 2GB 的数据（我认为）并且还支持 blob 消息。它保证交付和处理（通过交易）。

希望这可以帮助。

于 2012-10-23T19:48:12.003 回答