我发现Rebus包含FileSystemMessageQueue。这似乎太棒了，不可能是真的，所以我想问几个问题：）
-
线程安全/过程安全
-
是交易吗
-
为什么它使用JSON作为序列化格式（与二进制序列化程序相比，它不是增加了POCO的限制吗？）
-
没有公共汽车，它能单独工作吗？（就像单独的dll，而不是服务）
-
对于少量的消息，它可以取代MSMQ吗？我的意思是，如果我们谈论的是本地（非网络）消息，而不是资源密集型消息，那么它如何与MSMQ进行比较？它会和MSMQ一样好吗？
提前感谢
FileSystemMessageQueue一开始是一个有趣的实验，因为我想使用Dropbox作为传输工具-这似乎确实有效，但我没有以任何方式测试过它，除了让传输工具通过Rebus的常规传输合同测试并在几次用户组会议上展示之外：）
因此：请理解，你将是测试运输工具的人，如果你真的使用它，你几乎会立即成为世界上最有使用经验的人：）
</disclamer>
1） 传输会跟踪当前正在处理的消息文件，以确保不会两次接收同一个文件，因此可以安全地让多个线程在同一个端点中接收消息。
不过，您不能有竞争的消费者，因为目前没有可以跨越多个进程的锁定（但可能可以通过使用操作系统锁定文件并在处理消息所需的时间内保留文件句柄来完成）。
2） 不。它至少满足一次与Rebus中所有其他传输相同的交付保证，但它不是事务性的，也不能以原子方式提交工作。
我已经让传输将传出消息的实际写入推迟到您在消息处理程序中完成自己的工作之后，这样收件人就不会很快看到消息了——但理论上，您可能会遇到这样的情况，即发送了一堆传出消息，然后删除收到的消息文件失败，这将导致再次收到相同的消息——这就是为什么它被称为"至少一次"；）
3） 它使用JSON，因为这是一种将对象写入文件的简单方法（即使实际的消息体是使用配置的序列化程序序列化和编码的）。
4） ？？？我不明白你的问题：）
5） 是和否-我想，如果我们谈论本地而不是资源密集型消息，它将和MSMQ一样好。
我还没有执行任何负载测试，但我猜它在消息量方面会比MSMQ慢得多。我确实认为它能够传输比MSMQ大得多的消息，因为（据我所知）MSMQ仍然有每个消息4MB的硬上限。