好的,所以我对消息排队感兴趣。我已经对这个问题进行了大量的研究。我读过“编程windows azure”(关于Azure Queues),我阅读了大量关于Azure服务总线的教程和信息,我观看了关于消息传递模式的9频道视频等。
但是我只是不明白:如何在现实场景中使用它?所有示例只是将一个字符串或一个包含一些数据的对象放入队列中,并从“另一侧”的队列中读取它。但是,您如何知道如何处理这些数据?例如:我可以尝试将Customer,Order和Address保存到数据库中,因此我将这3个对象放在队列中以便在另一侧读取它们将它们放入我的数据库中。我怎么知道如何处理这些物体?
我有一些问题:
我认为这是我头脑中嗡嗡作响的大部分问题。我希望有人能为我解决这个问题。
答案 0 :(得分:7)
在最简单的示例中,假设您将要执行的操作序列化到队列,然后是参数的序列化版本:
问:Delete: User 5
这很好,因为您的工作者角色可以阅读并相应地采取行动。在这个例子中似乎不是一个很大的好处,因为排队可能只需要删除就可以,但是如果你想在所有用户上做BI那会怎么样?在等待同步请求进行处理时,您的网页或应用程序永远不会刷新。但是,如果您将该请求推送到队列:
问:RunSome2HourProcess: User *
现在你可以返回你已经排队等待操作,并继续你的快乐方式,而从队列中拉出的服务器将能够在闲暇时进行处理。
更重要的是,这可以实现更好的规模方案。如果最后一条消息被拆分怎么办?所以,不是做所有用户,而是做了类似的事情:
Q RunSome2HourProcess: User A*-M*
Q RunSome2HourProcess: User N*-Z*
两个azure worker角色会分割负载并并行处理您的信息。
还有许多关于重试,工作流程,跨角色异步通信等的方案,但这应该为您提供一些理由,说明在正确的情况下排队可能是好的。
所以,在这些例子中: 1.我们将动作和标识符/查询放在排队的项目中。队列中的工作者角色轮询将知道如何处理它。
您可以在服务层和处理层之间使用队列。您可以在处理层之间使用队列。您可以在同一层中使用队列。天空是极限
我通常每次操作都有1个队列。所以在上面的例子中,我有Run2HourProcess Queue,只需将参数写入其中。并为任何其他进程类型创建新队列。但它们非常灵活,因此取决于开发人员。
除非它是一个长时间运行的读取(即样本中的缩略图生成示例或慢速数据处理的结果),否则您可以快速地访问数据库。
答案 1 :(得分:2)
请注意,单个工作器实例(即VM)可以读取您想要的任意数量的队列。你只需要编写代码即可。如果你有很多队列没有看到很多流量,这是降低成本的合理方法。另一种方法是将多种消息类型组合成一个队列。这样你只有一个地方可以查找消息。
或者,您可以让许多工作人员从同一队列中读取,以便将工作均匀地分配到他们身上。
答案 2 :(得分:0)
除了Rob提到的内容之外,消息队列还用于处理可以等待(在队列中)直到自由工作者可用的流量突发。
我相信Azure Service Bus,队列和主题利用封面下的消息排队来完成相同的操作。我也看到AppFabric托管的Workflow Foundation可能也会做同样的提示。