Jak*_*ner 5 size message azureservicebus
我们需要在ServiceBus主题上发送大量消息.目前的大小约为10MB.我们最初的做法是在BlobStorage中保存一个临时文件,然后发送一个参考blob的消息.压缩文件以节省上传时间.它工作正常.
今天我读了这篇文章:http://geekswithblogs.net/asmith/archive/2012/04/10/149275.aspx 建议将消息分成较小的块,然后在接收端再次聚合它们.
我可以承认这是一种"更清洁的方法",避免了往返BlobStore的往返.另一方面,我更喜欢保持简单.分裂机制引入了更高的复杂性.我的意思是他们从一开始就没有把它包括在ServiceBus中的原因一定是这样的...
有没有人尝试过现实生活中的分裂方法？
有更好的模式吗？
小智 5
我刚才写了这篇博客文章,目的是使用Service Bus实现拆分器和聚合器模式.在寻找更好的选择时,我偶然发现了这个问题.
我同意最简单的方法可能是使用Blob存储来存储消息体,并在消息中发送对它的引用.这是我们正在考虑的客户项目的情景.
我记得几年前,发布了一些示例代码,它们将从客户端应用程序中抽象出Service Bus和Storage Queues,并在需要时处理大型消息体的Blob存储使用.(我认为这是微软的CAT团队,但我不确定).
我无法通过快速谷歌搜索找到样本,但因为它可能已经过了几年,它将会过时,因为Service Bus客户端库从那时起已经有了很大的改进.
当消息大小太大时,我使用了消息拆分,但由于这是批量遥测数据,因此无需聚合消息,我可以在接收端处理一些较小的批次,而不是一个大的信息.
分离器 - 聚合器方法的另一个缺点是它需要会话,因此会话启用了队列或订阅.这意味着所有消息都需要会话,甚至更小的会话,并且会话ID也不能用于实现中的其他目的.
如果我是你,我不会相信博客文章中的代码,它是很久以前写的,从那以后我学到了很多东西:-).
Blob存储方法可能就是这样.
问候,
艾伦
| 归档时间： |
|
| 查看次数： |
3567 次 |
| 最近记录： |