我们生活在一个实时信息持续可用的世界当中。我们编写的应用程序需要以简单的方式可靠且迅速地路由给众多的接收者。更为重要的是，我们需要找到改变信息接收者的方式，而无须频繁地重写它们。应用程序信息经常会沦为孤岛，新的程序如果不将原始信息的生产者重写（或者推倒重来）的话就无法对其进行访问。
你也许会自言自语：“好吧，不过消息队列或者RabbitMQ 如何帮助我来解决这些问题呢？”
让我们先来反思下面的场景为何如此熟悉。
你刚刚为公司的杀手级Web 应用实现了一个非常棒的认证模块。
它看起来非常不错。
对于每一个页面单击，程序代码会非常高效地和认证服务器通信以确保用户只能访问他们能够访问的页面。你有点沾沾自喜，因为公司的世界顶级牛油果分布网站上的每一次用户单击都会触发你的代码。
但是，正在这时，老板忽然进来和你说公司需要记录每次成功和失败的权限尝试，以便进行数据挖掘。
在你婉转地表达了这应该是认证服务器的工作时，老板没好气地通知你，你无法访问那些数据。认证服务器将数据以适当的格式记录下来。现在这成为你需要解决的问题。
仔细思考了目前的情况之后，你的脑袋一阵剧痛。你发现自己不得不去修改认证模块，还有可能在处理的时候中断每个页面。毕竟，这些精彩的代码几乎涉及所有的站点访问。
●●●●●
好了，先不要心累。小编帮你按下“简单模式”按钮，让时间回到一开始开发认证模块的那一刻。
让我们假设你从第一天开始就决定在设计中好好利用消息队列。
通过使用RabbitMQ，你聪明地利用消息队列解耦了模块和认证服务器。认证模块被设计为在每一次页面请求时，发送一条认证请求消息到RabbitMQ。然后认证服务器监听RabbitMQ 队列并接收该请求消息。一旦请求被获准，认证服务器会向RabbitMQ 发送一个应答消息。RabbitMQ 会将该消息路由到认证模块所监听的那个队列。
在这种模式下，老板的需求不会再让你头疼了。你会发现自己不需要碰模块或者重写一个。所有需要做的是编写一个简单的应用程序连接到RabbitMQ 并且订阅认证请求。无须更改任何代码。之前编写的代码都不需要知道发生了什么变更。这太简单了，以至于你脸上露出了满意的笑容。这就是消息通信的力量！它让你的日常工作变得如此轻松。
消息队列（message queuing）使用消息将应用程序连接起来。这些消息通过像RabbitMQ 这样的消息代理服务器在应用程序之间路由。这就像是在应用程序之间放置一个邮局。现实的情况是，这个解决方法并不仅仅针对的是金融行业实时通信问题，它同时也解决了我们开发人员每天要面对的问题。作为作者的我们并没有金融服务行业的背景。当我们需要扩大应用规模的时候，我们搞不清楚什么是“企业消息通信”。我们和你一样只是开发人员，想要解决的这个问题就是处理庞大的实时信息，并把它们快速路由到众多的消费者。我们要在不阻塞消息生产者的情况下做到这一点，同时也无须让生产者知道最终消费者是谁。RabbitMQ 帮助我们轻松解决这些常见问题，并用一种基于标准的方法来确保应用程序之间相互通信，而不管应用是用Python、PHP 还是Scala 编写的。
