我有一个运行第三方服务器进程的 Azure VM。该服务器进程通过调用我提供的可执行文件来通知我重要事件，并将一些数据作为命令行参数传递。
这些数据需要排队等待另一个worker处理。
不要错过这些通知非常重要，所以我想知道：
是否可以（根据我的要求）将消息直接排队到 Azure 服务总线？
或者我应该先排队到本地 MSMQ，然后让另一个工作人员从 MSMQ 读取消息并将它们推送到 Azure 服务总线？
谢谢
【问题讨论】：
标签： azure azureservicebus
Azure 服务总线保证 99.9% 的可用性（每年不超过 8.76 小时不可用）。来源：http://www.windowsazure.com/en-us/support/legal/sla/
瞬态错误是 Azure 平台的自然组成部分，因为它需要在服务器之间移动部署。它们是由 Azure 基础架构“转移”部署引起的问题，可能导致请求失败。重试请求即可解决问题。
关于如何继续的真正问题是您是否能够承受丢失数据的后果。在任何系统中，如果您需要某种保证数据不会丢失，您需要编写消息代码，以便在将消息标记为“已发送”之前确认已将消息传递给收件人。
如果您在 Azure 队列和应用程序之间放置一个 MSMQ 服务，您仍然必须处理此本地队列可能不可用的可能性 - 如果您需要知道，则无法一劳永逸消息不会丢失。必须有一个接收确认和一个机制来重试你没有得到确认的消息的传递。
【讨论】：
对服务总线的访问非常可靠，但您始终必须构建解决方案以应对“瞬态故障”。通过这种方式，您可以检查是否发生了某个故障（队列中的临时 404、您身边的连接问题等）。 这些故障称为瞬态故障，您应该重试它们。为此，Service Bus 客户端具有内置功能，您可以在客户端上指定 RetryPolicy。有不同的重试策略可用，您可以创建自己的（ExponentialBackoff 等） 检查：http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.servicebus.messaging.messagecliententity.retrypolicy.aspx
如果您需要您的客户端应用程序能够脱机工作，那么您可能需要构建一些自定义存储转发功能（您提到了 MSMQ，您也可以使用 Service Bus for Windows Server）。唯一的缺点是目前没有开箱即用的存储转发功能。
希望对你有帮助
【讨论】：