Rebus FileSystemMessageQueue

Question

我发现Rebus包含FileSystemMessageQueue。这似乎太大了，是真实的，所以我要问几个问题吧:)

1. 它是线程安全/过程安全

2. 难道事务

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

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

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

在此先感谢

Answer 1

的FileSystemMessageQueue开始了作为一个有趣的实验，因为我想用的Dropbox作为传输 - 这实际上似乎工作，但我没有以任何方式进行了测试，除了通过运输通过Rebus的通常运输合同测试，并在几次用户组会议等中展示出来之外。）

因此：请理解，您将成为测试运输工具的一员，如果您确实使用它你几乎可以立即成为世界上与t的一员他在用它最有经验:)

</disclamer>

1）运输跟踪哪些邮件文件，目前正在处理，以确保相同的文件不被接受的两倍，因此您可以放心地有多个线程在同一端点接收消息。

虽然你不能做competing consumers，因为目前没有可以跨越多个进程的锁定（可能可以通过使用操作系统锁定文件并保留文件句柄来处理消息所需的时间）。

2）不可以。至少一次至少一次作为Rebus中所有其他传输的传递保证，但它不是事务性的，也不能以原子方式提交其工作。

我已经让传输延迟了传出消息的实际写入，因为在消息处理程序中完成了自己的工作之后，消息对于收件人来说不会很快显示 - 但从理论上讲，可能会遇到这样的情况，即发送一组传出消息，然后删除接收到的消息文件失败，这将导致再次接收相同的消息 - 这就是为什么它被称为“至少一次”的原因;）

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

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

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

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