问题标签 [azure-queues]

我是新的 Azure 开发人员。我的场景类似于经理将通过网站/wp8 发布新主题/队列，并且工作人员应该在 wp8 中获得有关新添加的主题/队列的通知（通过推送通知）。此时我已经准备好所有的部分，例如主题/队列创建，发送接收。但它在拉动的基础上起作用。含义管理器可以创建主题并发布消息。然后工人必须订阅主题以接收消息并每次拉动以检查是否有任何新内容？

所以我想根据通知制作这个系统。我的意思是每当主题用户中新添加的任何内容都应该收到通知（通过推送通知）。那么你能建议我如何实现这个目标吗？如果添加或删除主题等，是否会从服务总线生成任何事件？提前致谢！

我正在处理将数据存储在 azure 队列存储中，为此目前我有 2 个数据类型类，如下所示

并且为了将记录插入队列，我正在使用以下方法

我需要从不同的队列中读取

在这里，我只想使用 1 个队列存储（因为会有更多的任务项）所以任何人都可以建议我如何将不同类型的对象组合到一种类型的对象中？

注意：ToBinary 和 FromMessage 是简单的扩展

谢谢。

从 CodeReview.Stackexchange 重新发布，因为它只是伪代码

我正在建立一个任务处理器工作者角色。任务被插入到一个简单的数据库表（Guid、Json 字符串、状态）中，然后将 Guid 推送到一个天蓝色的消息队列中。然后，工作者角色将从队列中弹出消息，从数据库中检索 JSON 指令并处理该任务。

我试图确保我已经涵盖了幂等性和重试的所有极端情况，并提出了以下伪代码。

我的主要问题是我的“ProcessTask”阶段是非事务性的（HTTP Posts & Service Calls to external services），重复调用会很糟糕（Mkay）

有人可以仔细检查一下，看看是否有任何我没有发现的极端情况。

让我们假设数据库中存在具有以下信息的任务。

以下伪代码涵盖以下情况。

1. 工作人员检索消息，及时处理，更新数据库并删除消息。
2. ＃1，除了它需要比 30 秒的隐身超时时间更长但仍然成功。
3. 消息处理失败，需要重试。
4. 消息多次处理失败，超出允许的最大出列数。

出于幂等性的原因，该计划是利用 Azure BlobStorage AquireLease 机制将关键代码片段用作文件锁。

伪代码

任何人在 iOS 上使用 Windows azure，以及如何访问 Windows azure 活动目录......请帮助我下面的主题我将在编码中设置下面提到的主题的值是什么......

WAAD_LOGIN_URL WAAD_DOMAIN WAAD_CLIENT_ID WAAD_REDIRECT_URI WAAD_RESOURCE WAAD_SERVICE_ENDPOINT

请提前给我帮助谢谢:)

我有一个 CloudQueue 的 Windows Azure 队列。我用来queue.GetMessage从队列中检索消息，但它返回 null。

我初始化我的队列如下：

之后，我在该队列中添加 CloudQueueMessage，如下所示：

当我检查消息计数时：

我得到的计数等于 1，但是当我尝试获取消息时：

我retrievedMsg有null。

我很困惑。我没有代码，但在这个方法中。但是每次我检索到的消息都是空的。

有任何想法吗？

假设我不打算使用每个角色的多个实例，而是在负载增加时增加 VM 大小。

想法：在每个角色之间使用内部端点，以发送角色 A 已将角色 B 的作业放入队列和表中的通知（使用两者，以使角色确定作业至少完成一次且最多一次）？

它解决的问题：没有角色必须不断地轮询任何队列，而是只在通过内部端点之间的通道通知时轮询它，并且只轮询直到队列为空。

这是一个合理的解决方案，还是会带来可能的问题？

或者考虑到低交易成本（每 100.000 次读取 0.005 美元？），这只是不必要的开销。每天大约需要 1000.000 次事务才能达到 XS 工作者角色实例的成本。

我正在创建一个允许用户对事件进行投注的赌场类型游戏，并且我计划使用 Microsoft Azure 作为处理和数据存储（表存储）的后端。我正在寻找有关如何验证信息并通知用户任何更新的任何想法。

理念： 该应用程序允许用户对事件下注，例如在线博彩公司（PaddyPower、Ladbrokes 等）。

工作流程：

• 用户对某个事件下注
• 活动结束后，投注结算并通知用户任何奖金
• 转到第 1 步

场景（简化）：

• 活动开始后用户不应该下注
• 应通知用户任何问题和奖金

过程：

解决方案 1 - 使用队列： 当用户下注时，一条消息将被放入队列（供所有用户使用）并由 Worker Role 处理。

如果下注对赛事来说太迟了，或者玩家最终赢得了赌注，则需要通知他们结果。

因此，每个活动用户都有自己的队列，客户端应用程序会轮询任何更新。这将允许客户端应用程序获取任何通知并将其显示给用户。

解决方案 2 - 使用 WCF 和队列： 当用户下注时，他们连接到 WCF 服务，它会进行事件开始检查，如果有任何问题，他们会立即收到通知。

将任何通知返回给用户的唯一方法是使用解决方案 1 中的 Queue 方法。

笔记：

• 上面的场景是游戏的简化版，但是机制是一样的，所以我只是在寻找好的架构思路
• 我不打算使用通知服务，因为我计划将此应用程序同时用于移动设备和 Facebook，并希望在所有设备上都有相同的体验
• 我正在使用表存储，而不是使用 SQL Azure
• 如果更有意义，我愿意使用服务总线

那么哪种解决方案是理想的，还是有更好的解决方案？

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

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

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

如何克服？

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

全部 ，

我们需要开发一个基于 azure 的平台，用户可以在其中配置多个制药仪器，开始对其进行测量并分析测量数据。基于 azure 的平台中的典型组件如下

1 - 基于 .NET 的 4 客户端应用程序在连接到每个仪器的计算机上运行。此客户端应用程序应从 azure 平台接收开始测量命令，执行测量并将结果更新回 azure*

2 - 一组服务[可能基于 REST]，将从客户端应用程序获取结果并更新云上的数据库

3 - 一组可用于对数据进行分析的服务和业务逻辑

4 - 一个 asp.net 网络应用程序，用户可以在其中查看仪器详细信息、开始测量等

Azure 平台和客户端应用程序之间有两种通信方式，即客户端需要将结果更新到 azure，而azure 需要通过客户端应用程序在仪器上启动测量

在这种情况下，Azure 平台与客户端通信的推荐方法是什么。是不是以下任何一种

1 - 在客户端和服务器之间创建一个双工服务，并提供一个回调接口来启动测量

2 - 使用 Azure 消息队列为每个客户端创建命令队列。当需要开始测量时，一条消息将被放入队列中。客户端应用程序将始终从队列中读取并执行命令

或者我们有任何其他方法可以做到这一点，任何帮助表示赞赏

许多开发人员使用服务总线来集成应用程序的某些部分。服务总线使用哪个平台都没有关系。例如，它可以是 Azure Service Bus Queue，它集成了 Web 应用程序和云服务。

您如何在本地使用此类应用程序很有趣。您是否在每个本地开发人员站上安装 Azure 服务总线？或者，也许您在服务器上为所有开发人员使用一些测试消息队列？或者甚至有一个模拟队列？

看看有经验的人如何在现实世界的应用程序中解决这个问题会很好。任何评论都会有所帮助。

谢谢！