我对azure队列消息的生产部署有一些奇怪的行为: 队列中的一些消息显示延迟很大 - 分钟,有时10分钟。 当我们将消息放入队列时,请问你有关设置delayTimeout的问题 - 我们没有为该消息设置delayTimeout,因此消息在放入队列后几乎应该出现。 那时我们没有太大的负担。所以我的实例没有工作量,能够快速处理消息,但它们不会出现。
我们的服务每月处理数百万条消息,我们能够确定10-50条消息处理时间非常大,因为我们在客户面前失败了SLA。
有谁知道可能的原因是什么?
如何克服?
有没有人遇到类似的问题?
答案 0 :(得分:1)
排除故障的一般概念:
您确定消息已排队等待处理 - 即queue.addmessage操作成功返回,然后您等待10分钟 - 这意味着您可以排除任何客户端重试策略等因为问题。
时间计算是否有可能受到某种时钟偏差问题的影响。例如 - 如果其中一个工作者角色拉动消息与其他工作者角色关闭时,您可以看到这一点。
在消息显示为延迟的情况下,负责拉取消息的工作者角色是否实际失败或崩溃是否有可能。如果客户端调用GetMessage但在invisibilityTimeout设置指定的时间内没有响应适当的确认,则该消息将再次可见,因为队列服务假定客户端未处理该消息。您可以通过查看这些消息需要更长时间的出列计数来判断这是否是一个影响因素。可以在此处找到更多信息:http://msdn.microsoft.com/en-us/library/dd179474.aspx。
在一天中的某些时间,您从队列中提取项目的工作人员数量是否可能不足,而延迟只是由于队列填充速度快于从队列中提取消息所导致的。
您是否启用了队列日志记录,然后查看是否可以找到特定操作(查看e2elatency和serverlatency)。 http://blogs.msdn.com/b/windowsazurestorage/archive/tags/analytics+2d00+logging+_2600_amp_3b00_+metrics/。您还应该启用客户端日志记录并尝试确定客户端是否存在连接问题,并且重试逻辑可能正在启动。
最后,如果这些似乎都没有帮助,请将您的服务器日志(最好是客户端日志)以及您的帐户信息(无密码)发送给Microsoft网络公司的JAHOGG。
杰森
答案 1 :(得分:0)
Azure Service总线在BrokeredMessage类中有一个名为ScheduledEnqueueTimeUtc的属性,它允许您设置将消息添加到队列的时间(有效地创建延迟)。
您确定在您的代码中没有设置此属性,这可能是导致延迟的原因吗?
您可以在此网址找到有关此内容的更多信息:https://www.amido.com/azure-service-bus-how-to-delay-a-message-being-sent-to-the-queue/
答案 2 :(得分:0)
如果您使用WebJobs处理来自队列的消息,则可能是由于WebJobs配置。
来自MSDN forum post pranav rastogi:
从0.4.0-beta开始,(WebJobs)SDK实现了随机指数退避算法。因此,如果队列中没有消息,SDK将退回并开始减少轮询。
以下设置允许您配置此行为。
队列保持为空时的MaxPollingInterval,是检查消息之前等待的最长时间。默认为10分钟。
static void Main() { JobHostConfiguration config = new JobHostConfiguration(); config.Queues.MaxPollingInterval = TimeSpan.FromMinutes(1); JobHost host = new JobHost(config); host.RunAndBlock(); }