如何在Azure中创建“独特”队列？

Question

我有以下理论问题。

我希望能够在Azure应用程序中创建每个角色的多个实例。至少2，以确保它的工作24/7（或近24/7）。

这对于侦听数据的客户端前端和角色很容易。

对于处理数据并将结果保存在Blob /表存储中的工作角色也很容易，假定每个工作角色处理它自己的一组数据以创建单个结果。

但我遇到了这个应用程序的“中间”的问题。

在最简单的情况下，如果我可以创建一个Azure存储“distinct”队列（没有两个消息是相同的），那么这很容易。但据我所知，这是无法完成的，尤其是因为您一次只能下载32条消息。

所以，我需要某种控制器角色......我想。这个角色可以确保工作人员的角色不会互相干扰。

但是，这意味着控制器角色不能有多个实例！

我该如何解决这个问题？

编辑：

我看我可能已经给出关于我的问题，信息太少。

我知道Azure队列是如何工作的;我知道，一旦邮件出队，它将不会在一段时间内或其他角色可用，或直到它被删除。

问题是，我不能只用随机，唯一的数据填充队列，比如GUID。

下面是对问题的更为扎实的解释。

• 监听器角色侦听客户端数据，并将该数据放入基表中，然后通过队列通知该表的特定部分已被更改。
• 监听器角色可能会报告表中的同一部分已被多次修改 - 它们不跟踪队列中发生了什么，以及它已经在发生了什么，因此他们只是沿着“hey ，我为这个客户修改了这个位“（例如）。
• 工作人员根据听众提供的信息创建或刷新特定文件（主要是斑点）。目前，只有一名工作人员下载整个队列，检查不同的消息，然后根据需要刷新所有文件。添加第二个工作者会导致问题：由于队列通常不包含不同的值，因此两个工作人员可能会开始在同一个输出文件上工作，并相互中断。

因此，我正在寻找一个不同的队列，或者至少提供了一种方法来检查是否还没有放置特定的消息。

如果服务总线是唯一的出路，那就这样吧，但最好让解决方案尽可能简单。;）

Answer 1

服务总线队列确实具有唯一消息的概念（这可能是你的意思是不同的）。有两种类型的队列之间在这里很好的比较：

http://preps2.wordpress.com/2011/09/17/comparison-of-windows-azure-storage-queues-and-service-bus-queues/

在弹性的基础架构可以用锁来解决具有单个进程的问题。您可以使用Blob存储作为锁，通过smarx的BLOB岗位作为证明：

http://blog.smarx.com/posts/managing-concurrency-in-windows-azure-with-leases

不过，我会考虑你的整个架构，并尽量减少你使用的一些角色。我列出了一些这方面的争论在最近的一篇博客：

http://coderead.wordpress.com/2012/03/23/three-tier-architecture-in-the-cloud/

Answer 2

But as far as I know, this cannot be done, especially since you can download only 32 messages at a time.

情况并非如此。从队列中读取项目时，项目不会在给定的时间内出现在队列中（可配置）。处理完成后，您可以将邮件出列。生成队列ID可以是唯一的&最简单的&直接使用GUID的方式。您可以使用它来开发一个读取唯一关键项目的系统。

有人使用队列的最终原因是为了解决多个工作者角色从队列中输入没有任何问题的复杂性。

Answer 3

如果前端角色登录请求到Azure存储队列，那么队列可以由工人做分布式处理利用的请求。当一个工作者实例从队列中读取消息时，该消息在任何其他工作者实例中对于给定的时间量不再可见（可以通过定期重新更新消息上的租约来增加该消息）。这可以防止两名工人处理相同的消息。

或者，您可以使用模式来自行选择控制器实例。该模式表示控制器的进程存在于所有角色实例中。实例启动时，该进程首先尝试获取对象的排他锁，如租用Azure存储区blob对象。第一个获得租约的人成为“管理员”，其余的人睡觉等待，并定期检查是否可以再次出租。这允许另一个实例接管控制器，如果第一个变得不可用（它以说话的方式变成自我修复）。

我thik第一种方法将是我的第一选择，因为它不需要很多复杂的编码。但是，根据你想要完成的事情，如果你愿意投入时间，第二个也可以是一个体面的解决方案。