1

我不是高级程序员，但我已经部署了一段时间的应用程序并开发了小型完整系统。

我开始听说诸如 RabbitMQ 之类的排队系统。可能是，我从未开发过任何必须使用排队系统的系统。但是，如果我不使用它，我会担心，因为我不知道该怎么做。我已经在他们的网站上阅读了 RabbitMQ 教程，但我不确定我为什么要使用它。我不确定这些中的任何一个是否不能通过没有附加组件和常规数据库或类似的常规编程来实现。

有人可以用一个小例子解释为什么我会使用排队系统。我的意思不是一个hello world的例子，而是一个实际的场景。

非常感谢您的时间

  • R M
4

3 回答 3

5

One of the key uses of middleware like message queues is to be able to send data between non homogenous systems. The messages themselves can be many things. Strings are the easiest to be understood by different languages on different systems but are often less useful for transferring more meaningful data. As a result JSON and XML are very popular for the messages. These are just structured strings that can be converted into objects in the language of choice at the consumer end.

Additional useful features:

  • In some MQ systems like RabbitMQ (not true in all MQ systems) is that the client handles the communication side of things very nicely.
  • The messages can be asynchronous. If the consumer goes down, the messages will remain until the consumer is back online.
  • The MQ system can be setup to varying degrees of message durability. They can be removed from the queue once read or remain until the are acknowledged. They can be persistent so even if the MQ systems goes down message will not be lost.

Here goes with some possibly contrived examples. A Java program on a local system wants to send a message to a system on the connected through the internet. The local system has a server connected to the internet. Everything is blocked coming from the internet except a connection to the MQ. The Java program can publish the message to the MQ with out needing access to the internet. The message sits on the queue until the external system picks it up. The Java program publishes a message, lets say XML, and the consumer could be a Perl program. As long as they have some way of understanding the XML with a predefined way of serialization and deserialization it will be fine.

于 2012-10-10T20:53:43.863 回答
3

MQ 系统往往在“即发即弃”的情况下工作得最好。如果一个事件发生并且需要通知其他人，但源系统不需要来自其他系统的反馈，那么 MQ 可能是一个不错的选择。

如果您了解 MQ 的优缺点，但仍然不明白为什么它非常适合特定系统，那么它可能不是。我见过使用了 MQ 但不需要的系统，结果并不漂亮。

我见过的大多数情况下它都很好地解决了不相关系统之间的集成（通常是开箱即用的类型系统）。假设您有一个接受订单的系统，以及一个不同的系统来完成订单并发货。在这种情况下，订单系统可以使用 MQ 将订单通知履行系统，但订单系统没有兴趣等待履行系统收到订单。因此，它将消息放入队列中继续前进。

于 2012-10-10T21:05:12.043 回答
1

这是一个非常简化的答案，但它给出了一般的想法。

让我们从电话与电子邮件的角度来考虑这一点。假装一分钟电子邮件不存在。要完成工作，您必须给每个人打电话。当您通过电话与某人交流时，您需要让他们在他们的办公桌前才能联系到他们（假设他们在工厂并且听不到他们的手机铃声）:-) 如果您希望联系的人不是'在办公桌前，您被困在等待他们回电话之前（或者更有可能，您稍后再给他们回电话）。你也一样——在有人打电话给你之前，你没有任何工作要做。如果多人同时打电话，你不知道，因为你一次只能处理一个人。

但是，如果我们有电子邮件，您可以将您的请求与其他人“排队”，在他们方便的时候回答（但更有可能忽略）。如果他们确实忽略了您的电子邮件，您可以随时重新发送。您不必等待他们在办公桌前，他们也不必等到您挂断电话。工作量均匀，事情运行得更加顺利。作为额外的奖励，您可以将不想处理的消息转发给您的 peons。

在系统工程中，我们使用术语“紧密耦合”来定义像上面的电话场景一样工作的程序（或程序的一部分）。它们彼此非常紧密地依赖，经常在程序的各个部分之间共享实现。在这些程序中，数据按串行顺序处理，一次一个。这些系统通常很容易构建，但有一些重要的缺点需要考虑：（1）更改程序的任何部分可能会导致整个代码的级联更改，这会引入错误；(2) 系统的可扩展性不是很好，通常必须随着需求的增长而报废和重建；(3) 系统的所有部分必须同时运行，否则整个系统将无法运行。

基本上，如果程序非常简单或者有一些特殊的原因需要使用紧密耦合的程序，那么紧密耦合的程序是好的。

在现实世界中，事情要复杂得多。程序不可能那么简单，以紧密耦合的方式开发企业应用程序成为一场噩梦。因此，我们使用术语“松散耦合”来定义由许多较小部分组成的大型系统。这些部件具有非常明确的边界和功能，因此可以更轻松地完成系统的更改。它是面向对象设计的精髓。消息队列（如 RabbitMQ）允许在各种程序和程序的各个部分之间进行类似电子邮件的通信，从而使工作流程更像与人一起工作。然后，添加额外的容量就变得很简单，只需在需要的地方启动和额外的计算机即可。

显然，这是一个粗略的简化，但我认为它传达了总体思路。构建使用消息队列的应用程序使您能够利用云服务提供商部署可大规模扩展的应用程序。这是一篇关于云设计的文章：http: //blogs.msdn.com/b/silverlining/archive/2011/08/23/designing-and-building-applications-for-the-cloud.aspx

于 2012-10-20T04:26:19.690 回答