问题标签 [azure-storage-queues]

如果我要使用 Azure.Storage.Queue 从队列中获取消息

我可以设置可见性超时，但是当尝试使用 Azure.WebJobs (SDK 0.4.0-beta) 属性将 webjob 自动绑定到队列时

IE

有没有办法在属性上设置可见性超时？JobHostConfiguration().Queues 中似乎没有选项。如果没有办法覆盖，那是标准的30秒吗？

这个方法将如何被触发。

WebJob 主机是否只是对存储队列进行轮询。还是存储队列引发新消息事件，该主机订阅？

编辑：在哪里可以找到我在 Azure 中的存储帐户的“用户”和“密码”？（见下文）。

我只是尝试在 python3.4 中使用 python sdk 创建一个队列，但使用以下代码：

我得到：

问题是我正在尝试创建一个带有单个队列的 ubuntu VM 的 linux 自动扩展场。当此队列包含多于 x 条消息时，场会扩大规模，而不是使用 1 个 VM，而是使用 2 个或 3 个。

我已经有了我的虚拟机，我配置了可用性集和负载平衡，但我在队列中停止了。

有人可以帮忙，那就太好了！

谢谢

回答

我终于在这里找到了答案 在哪里可以找到我的 Azure 帐户名称和帐户密钥？

感谢 Jason Hogg - MSFT 指出了我真正的问题，我认为这是另一回事。

我正在使用 Azure 队列，我想知道如何使用 azure-sdk-for-python 禁用 Nagle 算法。是否有允许轻松做到这一点的参数？

谢谢 ！

我想让我的队列每 90 分钟重试一次失败的 webjobs，并且只尝试 3 次。

创建队列时，我使用以下代码

但是，当模拟失败的网络作业尝试时，队列使用默认的重试策略。我错过了一些东西。

我当前的进程以以下方式运行：

1.) 用户在前端应用程序中输入 URL 进行分析

2.) 前端验证 URL 并在包含 URL 属性的表中创建 URL 记录

3.) 前端在表中创建/更新一行，跟踪 URL 所处的处理阶段（每个 URL 都有自己的内部 ID）

3.A) 状态码更新为“排队”状态

---- 表格定义：

4.) 前端向包含提交 URL 的内部 ID 的 Azure 存储队列发送消息

第一条消息发送到队列后------------>

4.A) 在 UI 中创建一个对象供用户单击（以“刷新”数据）

4.B）用户在创建的对象上单击（这很可能会发生）一旦创建（如果验证则立即）

4.C) 另一条消息被发送到包含 URL ID 的队列

<--------------------------------

5.) 一个正在运行的 azure webjob（后台任务）不断拾取这些消息并开始处理

6.) 网络作业确定此 URL 是否已准备好进行处理

.....它准备好开始处理如果

• 它是新的（LastUpdated 字段为空）
• 附加到项目的状态代码表示错误
• 距离上次更新已 15 分钟

.....如果它退出

• 消息中的 ID 无效
• 附加的状态代码表示它目前正在处理中
• 距离 LastUpdated 不到 15 分钟

一旦确定被认为可以继续...

• 如果是新的，webjob 会将 LastUpdated 更新为 Datetime.Now
• 在流程的每个步骤开始时，状态代码都会更新以反映这一点

• 在该过程的最后，LastUpdated 被更新为当前时间

• 一个 try catch 围绕着这个过程

a.) 如果过程出错，则更新状态代码以反映

b.) 一条新消息被推入队列进行重试

确定 URL 是否可以解析的函数：

队列消息通过这个函数进入：

...现在的问题是，这个连续运行的 webjob 一次可以接收多条消息（我想将其扩展到更多的 webjobs 从同一个队列中读取）

如何确定 IsReadyToParse() 函数实际上反映了当前的处理状态？

如果数据库即将将状态代码更新为“正在处理”，但另一个线程刚刚读取了状态代码并给出了 OK 以继续该过程怎么办？

我需要生成相当多的报告，一个报告可能需要大约 5 分钟才能生成，大量的数据，许多不同的来源。

客户端将消息发布到 Azure 存储队列。有一个工作角色处理消息并生成报告。

如果我想扩大规模，假设我最终有 10 个工作角色，它们将处理来自队列的消息并生成报告。然后我将像这样将消息添加到队列中：

• 消息 1：处理 1 - 5 的报告
• 消息 2：处理从 6 到 11 的报告............
• 消息 10：处理 50 - 55 的报告（范围可能不准确）

如果我的工作角色 1 将获取第一条消息并对其进行锁定，但该过程需要 5 分钟，则锁定将过期并且消息将在队列中再次可见，因此工作角色 2 将接受并开始处理它...等等

如何避免只使用一次队列消息，记住任务很长？

我在我的 azure webjobs（控制台应用程序）中的功能正在正确地完成工作并从我的队列中获取消息，但我需要一种方法来控制“时间可见”选项或能够在收到消息后从队列中删除消息.

功能：

我知道当您以编程方式访问队列时，它是您传入的参数。但是我没有以这种方式访问​​它。在 webjobs 应用程序中使用 azure sdk 的正确方法是什么？

编辑：

可见性选项是从作业从队列中提取消息到消息重新出现在队列中的时间（因为该过程尚未完成并假定它失败）。在我的情况下，默认的 30 秒不足以让进程一直运行。

参考（部分：如何：利用其他选项使消息出队）： http ://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-queues/

我知道QueueTrigger当队列中有新消息可用时，会调用一些东西。然而，这种“框架风格”的 WebJobs 让我很难正确初始化我的环境。

这就是我想自己轮询队列的原因，基本模式是这样的：

我的问题是，在 WebJob 中连续运行时，这种方法是否存在潜在问题？如果是这样，避免“框架式”WebJobs 的可能替代方法是什么？

编辑

根据 Victor 的要求，这里有一些关于我为什么不想使用这种QueueTrigger方法的更多信息。基本上有两个原因。

第一个在上面已经提到了，就是框架调用了一个带有QueueTrigger属性的方法。这意味着我必须将所有初始化都放在该方法中。

我们的 Web 应用程序中有一个两阶段 IoC 容器（每个应用程序和每个请求），我想让 WebJobs 尽可能靠近 Web 应用程序，所以我想使用那个两阶段 IoC在 WebJobs 中也是如此（每个应用程序的 IoC 会进行一些繁重的初始化，然后在所有请求中重用）。这样做的结果是我必须将每个应用程序的容器放在静态变量或单例中，以便我可以从静态QueueTrigger方法访问它。这是我不愿意做的设计怪癖（IMO，Microsoft 做的太多了，例如，Thread.CurrentCulture或者HttpContext.Current- 这真的是一种反模式并且会损害可测试性）。

针对上述情况的完美 WebJobs SDK 将使基础设施（后退计时器、毒物处理等）可作为服务使用，以便主控制流始终保留在应用程序中。这可能适用于 SDK 的所有功能，也可能不可能，我对 SDK 的了解还不够，无法判断。

第二个原因是开发者的便利。我们有一个分布式团队，有时在离线环境中工作。从我在这里和这里阅读的内容来看，不可能使用存储模拟器在本地运行 WebJob 应用程序并让它出列消息。使用我现在采用的自我轮询方法，这就像一个魅力。

我希望有人能澄清一些关于 Azure 存储队列及其与 WebJobs 交互的事情：

1. 要执行重复的后台任务（即添加到队列一次，然后以设定的时间间隔重复），有没有办法更新在 QueueTrigger 函数中传递的相同消息，以便可以扩展其租约（可见性）作为重新排队和避免到期？

2. 通过上述重复后台作业的模式，我还试图找出一种“按需”删除/过期作业的方法。由于在 WebJobs 的上下文之外这似乎是不可能的，我正在考虑将要在表存储中删除的消息的 messageId 和 popReceipt 存储为持久缓存，然后在 QueueTrigger 函数中传递消息时执行用于执行 DeleteMessage 的表查找，以便不再重复该消息。

任何建议或提示表示赞赏。干杯:)