rebus - Rebus 文件系统消息队列

Question

我发现 Rebus 包含 FileSystemMessageQueue。这似乎太棒了，所以我想问一些关于它的问题:)

1. 它是线程安全/进程安全的吗

2. 是事务性的

3. 为什么它使用 JSON 作为序列化格式（与二进制序列化程序相比，它不会增加 POCO 的限制吗？）

4. 它可以在没有总线的情况下单独工作吗？（就像单独的 dll，而不是服务）

5. 对于少量消息，是否可以替代MSMQ？我的意思是，如果我们谈论本地（非网络）而不是资源密集型消息传递，它如何与 MSMQ 进行比较？它会和 MSMQ 一样好吗？

提前致谢

Answer 1

最初是一个有趣的FileSystemMessageQueue实验，因为我想使用 Dropbox 作为传输工具 - 这实际上似乎有效，但我没有以任何方式测试它，除了让传输通过 Rebus 的通常传输合同测试并在几个用户组会议等:)

因此：请理解，您将成为测试传输的人，如果您使用它，您几乎会立即成为世界上使用它的最有经验的人:)

</disclamer>

1) 传输跟踪当​​前正在处理哪些消息文件，以确保不会收到两次相同的文件，因此您可以安全地让多个线程在同一个端点接收消息。

但是，您不能有竞争的消费者，因为目前没有可以跨越多个进程的锁定（尽管可以通过使用操作系统锁定文件并在处理消息所需的时间内保留文件句柄来完成）。

2) 不。它满足与 Rebus 中的所有其他传输相同的至少一次交付保证，但它不是事务性的，它不能以原子方式提交其工作。

在您在消息处理程序中完成自己的工作后，我已使传输延迟实际写入传出消息，因此收件人不会很快看到消息 - 但理论上您可能会遇到发送了一堆传出消息，然后删除接收到的消息文件失败，这将导致再次接收到相同的消息 - 这就是为什么它被称为“至少一次”;）

3) 它使用 JSON，因为这是一种将对象写入文件的简单方法（即使实际的消息正文已使用配置的序列化程序进行序列化和编码）。

4）？？？我不明白你的问题:)

5) 是和否——我想如果我们谈论本地消息而不是资源密集型消息，它会和 MSMQ 一样好。

我没有进行任何负载测试，但我猜它在消息量方面会比 MSMQ 慢得多。我确实认为它能够传输比 MSMQ 大得多的消息，因为 MSMQ 仍然（据我所知）每条消息的硬上限为 4 MB。