我不是高级程序员，但我已经部署了一段时间的应用程序并开发了小型完整系统。
我开始听说像RabbitMQ这样的排队系统。可能是，我从未开发出任何必须使用排队系统的系统。但是，我担心如果我不使用它，因为我不知道该怎么做。我已经在他们的网站上阅读过RabbitMQ教程，但我不知道为什么我会使用它。我不确定是否有任何这些无法通过常规编程实现，没有额外的组件和常规数据库或类似的。
有人可以解释为什么我会使用一个小例子的排队系统。我的意思不是一个问候世界的例子，而是一个实际的场景。
非常感谢你的时间
答案 0 :(得分：3)
MQ系统倾向于在“即发即弃”场景中发挥最佳作用。如果事件发生而其他人需要通知它，但源系统不需要来自其他系统的反馈，那么MQ可能是合适的。
如果您了解MQ的优点和缺点，并且仍然不理解为什么它适合特定系统，那么它可能不是。我见过使用MQ但不需要MQ的系统，结果不是很好。
我见过的大多数场景都是不相关的系统（通常是开箱即用型系统）之间的集成。假设您有一个接受订单的系统，以及一个填充订单并运送订单的不同系统。在该场景中，订单系统可以使用MQ来通知订单履行系统，但订单系统无需等待履行系统接收订单。所以它将一条消息放入队列继续。
答案 1 :(得分：1)
这是一个非常简化的答案，但它提供了一般性的想法。
让我们从电话与电子邮件的角度考虑这个问题。假装电子邮件不存在一分钟。要完成工作，您必须给每个人打电话。当您通过电话与某人通信时，您需要将他们放在他们的办公桌上以便联系他们（假设他们在工厂并且听不到他们的手机铃声）:-)如果您想要联系的人不是在桌子上，你会等到他们回复你的电话（或者更有可能，你稍后再回电话）。对你来说也一样 - 除非有人打电话给你，否则你没有任何工作要做。如果有多个人同时打电话，你就不知道，因为你一次只能处理一个人。
但是，如果我们收到电子邮件，您可以将您的请求与其他人“排队”，以方便他们回答（但更可能忽略）。如果他们忽略了您的电子邮件，您可以随时重新发送。您不必等待他们在办公桌前，他们不必等到您不在电话旁。工作量平衡，事情运行得更顺畅。作为额外的奖励，您可以转发您不想要处理的消息。
在系统工程中，我们使用术语“紧密耦合”来定义与上述电话场景类似的程序（或程序的一部分）。它们彼此非常依赖，通常在程序的各个部分之间共享实现。在这些程序中，数据按顺序处理，一次一个。这些系统通常很容易构建，但有一些重要的缺点要考虑：（1）更改程序的任何部分可能会导致整个代码的级联更改，这会引入错误; （2）系统的可扩展性不高，通常必须随着需求的增长而废弃和重建; （3）系统的所有部分必须同时运行或整个系统不起作用。
基本上，如果程序非常简单，或者有一些专门的理由使用紧密耦合的程序，那么紧密耦合的程序是好的。
在现实世界中，事情要复杂得多。程序不能那么简单，以紧密耦合的方式开发企业应用程序成为一场噩梦。因此，我们使用术语“松散耦合”来定义由许多较小的部分组成的大型系统。这些部件具有非常明确的边界和功能，因此可以更容易地完成系统的更改。它是面向对象设计的精髓。消息队列（如RabbitMQ）允许在各种程序和程序的各个部分之间进行类似电子邮件的通信，从而使工作流程更像人们的工作流程。添加额外的容量然后就可以在任何需要的地方启动和附加计算机。
显然，这是一个严格的简化，但我认为它传达了一般的想法。构建使用消息队列的应用程序使您可以利用云服务提供程序部署大规模可伸缩的应用程序。这篇文章讨论了云的设计： http://blogs.msdn.com/b/silverlining/archive/2011/08/23/designing-and-building-applications-for-the-cloud.aspx