我们有一个现有的系统，可以持续处理大量文件。粗略地说，每天大约有300万个文件，大小范围从几千字节到超过50 MB。这些文件从接收到完成消费时经历了几个不同的处理阶段，具体取决于它们所采用的路径。由于这些文件的内容和格式，它们不能分解成更小的块。
目前，这些文件所经过的工作流程是严格的，并且由具有固定输入和输出的代码决定（在许多情况下，一个订户成为新文件集的发布者）。这种缺乏灵活性开始引起我们的问题，所以我正在寻找一种能够处理新要求的某种pub / sub解决方案。
大多数传统的pub / sub解决方案都具有实际有效负载内的数据，但是大的潜在文件大小超出了许多消息传递平台的限制。此外，我们还有多个平台：根据路径，文件在Linux和Windows层中都会进展。
有没有人有任何设计和/或实施建议，并考虑到以下目标？
1. pub和sub的多平台（Linux和Windows）
2.持续存储/存储转发支持
3.可以处理大型事件有效负载，并在所有用户都得到服务后适当清理
4.路由/工作流程通过配置完成
5.订阅者可以根据不断变化的标准订阅一组已过滤的已发布事件（例如，只提供特定类型的文件）
我已经完成了大量的服务总线和MQ实现，但还没有足够的设计方法来正确评估哪些工具最有意义。感谢您的任何意见。
答案 0 :(得分：0)
A1。我在以前的工作中开发了类似的系统。 我们没有在消息中传递多MB有效负载，而是将它存储在文件服务器上，并且只传递了UNC文件名（消息传递是Java RMI，但几乎任何东西都可以工作）。
A2。我最近开始使用Windows Communication Foundation。对我来说幸运的是，我只支持Windows，而且我不需要这么大的消息。然而，文档说协议是独立于平台的，并且可以选择使用其streaming message transfer功能传递大量数据。
在这两种情况下，我认为您必须在自己的代码中满足＃4和＃5要求。
答案 1 :(得分：0)
如果您的客户是内部客户，您可能需要查看ActiveMQ。 ActiveMQ确实支持最多2GB的数据（我认为）并且还支持blob消息。它保证交付和处理（与交易）。
希望这有帮助。