标签: azure-queues

我目前正在为基于分布式事件的系统组建一个参考体系结构,其中事件使用普通旧表(没有SQL Server Service Broker)存储在SQL Server Azure数据库中.

将使用工作者角色处理事件,工作者角色将轮询队列以获取新的事件消息.

在我的研究中,我看到许多解决方案允许多个处理器处理队列中的消息.我遇到的很多模式的问题是当多个进程试图访问单个消息队列时管理锁定等的复杂性.

我知道传统的队列模式是从一​​个队列中拉出多个处理器.但是,假设可以按任何顺序处理事件消息,是否有任何理由不在队列与其队列处理器之间创建一对一关系,只是在不同队列之间进行负载平衡？

queue_1 => processor_1
queue_2 => processor_2

此实现避免了管理跨多个处理器的队列并发访问所需的所有管道.事件发布者可以使用任何负载平衡算法来决定将消息发布到哪个队列.

事实上,我在任何搜索中都没有看到这种实现,这让我觉得我忽略了这个设计中的一个主要缺陷.

编辑

这篇文章引发了关于使用数据库表作为队列与MSMQ,Azure队列等的争论.我理解我可以使用许多本机排队选项,包括Azure AppFabric中的持久消息缓冲区.我已经评估了我的选项,并确定SQL Azure表就足够了.我的问题是讨论针对单个队列使用多个处理器而不是每个队列使用一个处理器.

我已经构建了一些利用 Windows Server 上的 MSMQ 的应用程序。我想将这些移植到基于 Azure 的 Web 应用程序中，这有助于我解决过去面临的一些安全和信任障碍挑战。

我的问题是，我能否期望 Windows Azure 存储的消息队列方面的行为与 MSMQ 相同？

我知道,如果一个工作者无法处理队列中的消息,它将再次变为可见,并且您必须对此进行编码(幂等).但工人是否可以将消息两次出列？根据我的日志记录,我似乎看到了这种行为,我不知道为什么.我甚至删除了之间的消息去获取下一条消息,似乎我再次得到它.

我已经看到大多数队列示例作为轮询机制.是否可以将其更改为队列的列表.因为轮询可能会影响工人的表现.

是否可以在Azure Queue中将更新/更新到期时间从7天更改为10天或7天到1天？

Azure队列中的PopReceipt和Next Visible字段有什么用？

我有非常基本的架构：

Web API 队列中的消息在 Queue 和 Worker（后台处理服务）中出队并处理消息。

问题是 Web API 不知道 Worker 何时处理了消息。

Worker 是否可以提醒队列消息已成功处理，并且队列将“处理完成消息”事件发送回 Web API？

我正在考虑的一种解决方案：

Web API 对消息进行排队后，它每隔几秒检查一次消息状态：

如果消息状态为“Peck-Lock” -消息仍在处理中。

如果在队列中找不到消息- 消息已被处理（成功或不成功并不重要）。

但是微软没有现成的解决方案吗？

我试图用Azure创建一个新的存储队列,但它没有解释就一直崩溃,创建表工作正常,这是相关的代码:

        private CloudTable userTable;
        private CloudTable petTable;
        private CloudQueue healingQueue;

        public override bool OnStart()
        {
            CloudStorageAccount storageAccount = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("connectionString"));
            CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
            userTable = tableClient.GetTableReference("users");
            userTable.CreateIfNotExists();
            petTable = tableClient.GetTableReference("pets");
            petTable.CreateIfNotExists();

            // This is where I create the queue: //
            CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();
            healingQueue = queueClient.GetQueueReference("healQueue");
            healingQueue.CreateIfNotExists(); // This line makes the code crash.
        }

代码崩溃符合healingQueue.CreateIfNotExists();解释(400) bad request

表创建得很好所以我假设存储帐户没有问题,我能做什么的想法？

我使用Azure PowerShell创建条目并将条目添加到Azure队列,如下所示:MSDN:将Azure PowerShell与Azure存储一起使用 - 如何管理Azure队列.

这是我的PowerShell脚本:

$storeAuthContext = New-AzureStorageContext -StorageAccountName '[my storage account name]' -StorageAccountKey '[my storage account key'
$myQueue = New-AzureStorageQueue –Name 'myqueue' -Context $storeAuthContext
$queueMessage = New-Object -TypeName Microsoft.WindowsAzure.Storage.Queue.CloudQueueMessage -ArgumentList 'Hello'
$myQueue.CloudQueue.AddMessage($queueMessage)

这在第一次运行时工作正常.

第二次,我明白了:

New-AzureStorageQueue:队列'myqueue'已经存在.在行:1 char:12 + $ myQueue = New-AzureStorageQueue -Name'myqueue'-Context $ storeAuthContext + ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo:ResourceExists :( :) [New-AzureStorageQueue ],ResourceAlreadyExistException + FullyQualifiedErrorId:ResourceAlreadyExistException,Microsoft.WindowsAzure.Commands.Storage.Queue.NewAzureStorageQueueCommand

在.NET Azure Storage API中有cloudqueue.createifnotexists(MSDN),但我找不到Azure PowerShell中的等效项.

PowerShell创建Azure存储队列的最佳方法是什么(如果尚不存在),否则引用现有队列？

我应该CreateIfNotExistsAsync()在每次对Azure队列进行读/写之前先打电话吗？

我知道它会导致REST调用，但是它在队列上执行任何IO吗？

我正在将.Net库用于Azure Queue（如果此信息很重要）。

我已经看到这个问题表达了很多，但我还没有找到一个可行的解决方案。

简而言之，我定期有大量的处理操作要完成。每个操作都由 Azure 函数处理。每个操作都会调用数据库。如果我有太多的并发函数同时运行，这会导致数据库过载并出现超时错误。因此，我希望能够限制一次运行的并发 Azure 函数调用的数量。

我已将函数切换为队列触发，并根据我在网上看到的内容以多种方式调整了 batchSize / newBatchThreshold / maxDequeueCount host.json 设置。我还在我的函数应用程序设置中将 WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT 应用程序设置设置为 1，以防止生成多个 VM。

然而，每次我填满那个队列时，多个函数会不加选择地产生，我的数据库会崩溃。

如何限制并发操作的数量？