2

我在天蓝色队列消息的生产部署中有一些奇怪的行为：队列中的一些消息出现很大延迟 - 几分钟，有时是 10 分钟。当我们将消息放入队列时，请询问有关设置 delayTimeout 的问题 - 我们没有为该消息设置 delayTimeout，因此消息在放入队列后应该几乎立即出现。那时我们没有很大的负担。所以我的实例没有工作负载，并且能够快速处理消息，但它们只是没有出现。

我们的服务每月处理数百万条消息，我们能够识别出处理的 10-50 条消息延迟非常大，因为我们在客户面前未能达到 SLA。

有谁知道可能是什么原因？

如何克服？

有没有人遇到过类似的问题？

4

3 回答 3

1

故障排除的一些一般思路：

  1. 您确定消息已排队等待处理 - 即 queue.addmessage 操作成功返回，然后您等待 10 分钟 - 这意味着您可以排除任何客户端重试策略等作为问题的原因。

  2. 时间计算是否有可能受到某种时钟偏差问题的影响。例如 - 如果其中一个提取消息的工作人员角色与其他工作人员角色的关闭不同步，您可以看到这一点。

  3. 在消息似乎被延迟的情况下，负责拉取消息的工作人员角色是否可能实际上失败或崩溃。如果客户端调用 GetMessage 但未在 invisibilityTimeout 设置指定的时间内以适当的确认响应，则消息将再次变为可见，因为队列服务假定客户端未处理该消息。您可以通过查看这些耗时更长的消息的出队计数来判断这是否是一个促成因素。更多信息可以在这里找到：http: //msdn.microsoft.com/en-us/library/dd179474.aspx。

  4. 您是否有可能在一天中的某些时间从队列中提取项目的工作人员数量不足，并且延迟仅仅是由于队列的填充速度快于您从队列中提取消息的速度。

  5. 您是否为队列启用了日志记录，然后查看是否可以找到特定操作（查看 e2elatency 和 serverlatency）。 http://blogs.msdn.com/b/windowsazurestorage/archive/tags/analytics+ 2d00 +logging+_2600_amp_3b00_+metrics/。您还应该启用客户端日志记录并尝试确定客户端是否存在连接问题以及重试逻辑是否可能启动。

最后，如果这些似乎都没有帮助，您能否将服务器日志（最好是客户端日志）连同您的帐户信息（无密码）一起发送给 Microsoft dot com 的 JAHOGG。

杰森

于 2014-04-30T22:02:16.527 回答
0

如果您使用 WebJobs 处理来自队列的消息，则可能是由于 WebJobs 配置所致。

来自pranav rastogi的MSDN 论坛帖子：

从 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(); 
}
于 2016-10-03T00:03:20.287 回答
0

Azure 服务总线在 BrokeredMessage 类中有一个名为 ScheduledEnqueueTimeUtc 的属性，它允许您设置将消息添加到队列的时间（有效地创建延迟）。

您确定在您的代码中没有设置此属性，这可能是延迟的原因吗？

您可以在此网址找到更多信息：https ://www.amido.com/azure-service-bus-how-to-delay-a-message-being-sent-to-the-queue/

于 2016-01-18T17:01:02.493 回答