如何在现实场景中使用消息队列?

Leo*_*ens 8 messaging message-queue azure azure-queues

好的,所以我对消息排队感兴趣.我已经对这个问题进行了大量的研究.我读了'编程windows azure'(关于Azure Queues),我阅读了大量有关Azure服务总线的教程和信息,我观看了关于消息模式的9频道视频等.

但我不明白的是:如何在现实场景中使用它?所有示例只是将一个字符串或一个包含一些数据的对象放入队列中,并从"另一侧"的队列中读取它.但是,您如何知道如何处理这些数据?例如:我可以尝试将Customer,Order和Address保存到数据库中,因此我将这3个对象放在队列中以便在另一侧读取它们将它们放入我的数据库中.我怎么知道如何处理这些物体?

我只有一些问题:

  1. 将哪种数据放入队列中.可能是一个命令,它在读取时执行,因此队列中的所有内容都具有相同的接口,并且对象本身会弄清楚该怎么做?
  2. 在什么层之间使用队列?我正考虑将内容放入服务层的队列中(在验证之后)并在数据访问层中读取它,以便将其放入数据库中.
  3. 应该有多少队列?您想要连接的图层之间只有一个队列,或者它们之间有多个队列(可能出于不同的目的,虽然我想不出任何其他目的)?
  4. 这种松散耦合形式允许我们对请求进行排队,以便稍后处理它们(例如:当我们想要重新启动数据库时).这很酷但是如果我想读取数据而不是写它呢?然后数据库应该在线.我应该通过队列读取数据还是我的服务层只是从数据访问层提取数据并将其传递给表示层?

我认为这是我头脑中嗡嗡作响的大部分问题.我希望有人能为我解决这个问题.

Rob*_*odi 7

在最简单的示例中,假设您将要执行的操作序列化到队列,然后是参数的序列化版本:

问: Delete: User 5

这很好,因为您的工作者角色可以阅读并采取相应的行动.在这个例子中似乎不是一个很大的好处,因为排队可能只需删除就可以了,但是如果你想在所有用户上做BI那会怎么样?在等待同步请求进行处理时,您的网页或应用程序永远不会刷新.但是如果你将该请求推送到队列中:

问: RunSome2HourProcess: User *

现在,您可以返回已排队等待操作,并继续您的快乐方式,而从队列中拉出的服务器将能够在闲暇时处理.

更重要的是,这可以实现更好的规模方案.如果最后一条消息被拆分怎么办?所以,不是做所有用户,而是做了类似的事情:

QRunSome2HourProcess: User A*-M*

QRunSome2HourProcess: User N*-Z*

两个azure worker角色将分割负载并并行处理您的信息.

还有许多关于重试,工作流,跨角色异步通信等的场景,但这应该为您提供一些理由,说明为什么在正确的场景中排队可以很好.

因此,在这些示例中:1.我们将操作和标识符/查询放在排队的项目中.队列中的工作者角色轮询将知道如何处理它.

  1. 您可以在服务层和处理层之间使用队列.您可以在处理层之间使用队列.您可以在同一层中使用队列.天空是极限

  2. 我通常每次操作都有1个队列.所以在上面的例子中,我有Run2HourProcess Queue,只需将参数写入其中.并为任何其他进程类型创建新队列.但它们非常灵活,所以这取决于开发人员.

  3. 除非它是一个长时间运行的读取(即样本中的缩略图生成示例或慢速数据处理的结果),否则您可以快速访问数据库.


Bri*_*chl 2

  1. 嗯,你可以把你想要的任何东西放在那里。这只是一条消息,因此您的各层可以达成一致的任何内容都将起作用。我们放入消息来指示何时应发送电子邮件、何时需要处理视频等。
  2. 我不一定会考虑层之间的排队,而是会考虑面向用户的实时进程(例如,Web 服务器)和后台处理之间的排队。使用排队来执行您不希望 Web 角色在用户等待时花时间执行的操作。
  3. 你想做多少就可以做多少,真的。如果队列消息有一个字段表明它们的含义,那么您可以假设将所有内容放入一个队列中,尽管我不一定建议这样做。我们有大约六个队列:一个用于发送通知,一个用于视频处理,一个用于报告生成请求,等等。
  4. 我绝对不会使用队列作为数据存储和检索。它只是不适合这项工作的工具,就像尝试使用 TCP 来存储数据一样。

请注意,单个工作实例(即 VM)可以读取任意数量的队列。您只需这样编写代码即可。如果您有很多队列但流量不大,那么这是降低成本的合理方法。另一种选择是将多种消息类型组合到一个队列中。这样您就只有一个地方可以查找消息。

或者,您可以让许多工作人员从同一个队列中读取数据,以便将工作均匀地分布在他们身上。