在Rebus中发布时，如果MSMQ未运行或MSMQ服务中的其他错误，则会引发异常。在发布之前是否有内置的解决方案（在Rebus中）进行检查？或者我必须使用.Net服务控制器？
关于使用SQLServer作为传输，WAN的性能和可靠性如何？ Rebus是如何做到的？是否有一些示例代码或什么？
Transport(t => t.UseMsmq...)
Transport(t => t.UseSqlServer...)
答案 0 :(得分：0)
在Rebus中发布时，如果MSMQ未运行或MSMQ服务中的其他错误，则会引发异常。在发布之前是否有内置的解决方案（在Rebus中）进行检查？或者我必须使用.Net服务控制器？
如果我是你，我会尝试await bus.Send(..)然后捕获可能引发的任何异常。通过这种方式，您可以更好地处理所处理的错误类型，并避免您遇到的竞争条件（*）
我没有关于在这种情况下捕获异常时该怎么做的一般建议。
风险通常很低，实际上构建一个可以克服它的机制是没有意义的，因为你可能会将你想要发送的消息的内容记录为ERROR而不是让某人手动处理它。
但有时候建立一些本地发件箱可能是有意义的。或者可以用来临时存储无法发送的消息的东西。但是，由于MSMQ是一个本地运行的服务，您可以像监视所有其他Windows服务一样进行监视，并且在与其进行通信时不会涉及远程处理，因此您可以使其比其他任何东西更可靠。
关于使用SQLServer作为传输，WAN的性能和可靠性如何？ Rebus是如何做到的？是否有一些示例代码或什么？
如果您的要求适中，使用SQL Server作为传输可以正常工作。 SQL Server实际上并不是一个消息队列，并且它不会处理长队列（如10或100的数千条消息），因为队列长度会影响接收性能。
此外，它会要求你在发送和接收消息时进行远程处理，所以我猜你在发送时很难让它像MSMQ一样可靠（这并不重要）接收时很多，因为端点只会在断电后再次恢复连接时恢复 - 但是当您第一次发送时，可能是在Web请求中，您真的希望传输能够处理该消息）。
the samples repository中有一堆示例，如果您想将SQL Server用于所有内容，Rebus.SqlServer repository会有一些可能很有趣的测试。例如。 TestSqlAllTheWay测试很有趣IMO：）
（*）如果你这样做：
如果MSMQ在1和2之间停止/破坏/无论如何，你都会得到一个例外。