在单个消息中向Azure队列添加多个元素

本文关键字：添加 元素 队列 Azure 单个 消息 | 更新日期: 2023-09-27 18:03:35

我正在与AzureStorageAccount和CloudQueueClient进行交互，与此msdn示例中描述的方式类似

CloudStorageAccount storageAccount = CloudStorageAccount.Parse("some connection string");
CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();

和添加一个元素到队列(删除一些锅炉板):

var queue = queueClient.GetQueueReference("queuename");
var message = new CloudQueueMessage("myString");
queue.AddMessageAsync(message);

这意味着我可以添加"myString"到我的队列。太好了。如果我反复调用这些代码行，我可以多次添加"mystring"。也不错，但效率不高。

如何在一条消息中向队列添加多个项目?

我研究了一下，发现实体组事务，这可能是一个合适的选择。然而，这看起来与我一直在做的事情非常不同，并且没有真正给我任何代码示例。是否有任何方法可以使用这个并继续使用Microsoft.WindowsAzure.StorageClient库来构建我的消息?

在单个消息中向Azure队列添加多个元素

发送多个消息的一种方法是构建包含单个字符串值(或对象)列表的包装器类，例如将其序列化为JSon对象，并将其作为消息的有效负载发送。这里的问题是，根据对象的大小，您最终可能会超出消息的大小限制。所以这不是一个推荐的实现。

在某种程度上，我正在处理一个需要每秒发送大量消息的系统;它被大量分发。我们没有对多个消息进行批处理，而是在多个存储帐户之间创建了一个消息队列碎片。可伸缩性需求促使我们采用这种实现。

请记住，Chunky vs Chatty适用于发送更多信息，以避免往返，从而优化性能。消息队列与性能关系不大;它更多的是关于信息的可伸缩性和分布。换句话说，在这种环境中，最终的一致性和分布式扩展是受欢迎的模式。我并不是说你应该忽略矮胖和健谈，但你应该把它们用在有意义的地方。

例如，如果你需要每秒发送100万条消息，那么更大块的调用是一个选项;分片是另一个。我通常喜欢分片，因为它的可伸缩性边界更少。但在某些情况下，如果问题足够简单，分块可能就足够了。

我认为没有必要在一条消息中向队列中添加多个项目，因为最佳实践是使消息和相应的消息处理程序尽可能小。

在这里谈论效率低下是很难的。但是，当消息的数量增长到真正影响性能时，您可以使用BatchFlushInterval属性对消息进行批处理。否则，请遵循使用服务总线代理消息传递提高性能的最佳实践

更新:

通过在内部(例如列表)对消息进行批处理，您至少需要解决以下问题，这些问题可能导致无法管理的解决方案:

  • 跟踪消息的大小，以免超过最大消息大小限制
  • 找到放弃、完成和移动特定消息到死信队列的方法
  • 自己实现批处理策略
  • 跟踪大消息处理时间，并在花费太长时间时实现锁定

PS如果你能概述你的问题的目的，那么可能会找到一个更好的解决方案。

相关文章：