访问Azure Service Bus的可靠性如何？

Question

我有一个运行第三方服务器进程的Azure VM。此服务器进程通过调用我提供的可执行文件通知我重要事件，并将一些数据作为命令行参数传递。

此数据需要排队并由其他工作人员处理。

这些通知不会错过，这一点非常重要，所以我想知道：

• 是否可以接受（根据我的要求）将邮件直接排队到Azure Service Bus？

• 或者我应该首先排队到本地MSMQ，然后让另一个工作人员从MSMQ读取消息并将其推送到Azure Service Bus？

由于

Answer 1

对Service Bus的访问非常可靠，但您必须始终构建解决方案以应对“瞬态故障”。这样您就可以检查是否发生了某个故障（队列中的临时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）。唯一的缺点是目前没有开箱即用的存储转发功能。

希望这有帮助

Answer 2

Azure Service Bus保证99.9％的可用性（每年不超过8.76小时）。资料来源：http://www.windowsazure.com/en-us/support/legal/sla/

由于需要在服务器之间移动部署，因此瞬态错误是Azure平台的自然组成部分。它们是Azure基础架构“转移”部署导致的问题，可能导致请求失败。重新尝试请求就是解决问题所需的全部内容。

关于如何进行的真正问题是你是否能负担得起丢失数据。在任何系统中，如果您需要某种保证数据不会丢失，您需要编写消息代码，以便在将消息标记为“已发送”之前确认将消息传递给收件人。

如果在Azure队列和应用程序之间放置MSMQ服务，则仍然需要处理此本地队列可能无法使用的可能性 - 如果您需要知道，则无法点击即可忘记消息不会丢失。必须有收据确认和重新发送您未收到确认信息的机制。