消息队列 中间件 （ MQ ）可以说是大型分布式系统中必备的一个组件，它的一个重要的功能就是实现架构上的 解耦 。目前市面上存在的比较常见的有 RabbitMQ 、ZeroMQ、ActiveMQ和Kafka等，他们各有各自的优缺点，这里不作详细介绍，有兴趣的可以结合不同的应用去做实际的对比分析，本文以RabbitMQ为例子来作介绍。
RabbitMQ是基于AMQP协议的一个开源实现， Server 端用Erlang语言编写，支持C、Java、 Python 、PHP、 Ruby 等常见语言。它除了具备优异的性能之外，更重要的一点是支持消息的持久化，消息的可靠性可以得到相应的保障。
一、安装过程
简单附上一个 CentOS 系统下的安装教程。
安装依赖
安装RabbitMQ
安装过程还是比较简单的，完成之后需要检查防火墙对应的端口是否可用。
二、应用场景
1.削峰降流
这个很好理解，比如秒杀活动中，我们就经常用到消息队列来防止后台服务挂掉，同时也解决一部分并发的问题。
2.异步处理
假如用户注册成功时需要发注册邮件，传统的做法是以串行的方式进行，用户信息入库成功后发送邮件，这种方式严重影响服务端的响应时间。
引入消息中间件之后，注册成功与否不再受到邮件服务的影响，服务端响应时间也明显缩短，这种方式几乎是所有高并发应用所采取的一种策略。
3.架构解耦
例如淘宝双11购物节用户下单时订单系统使用通知库存系统、用户发帖时图片鉴定等场景，这里我们以发帖为例。
传统的做法是帖子入库之后调用各种 RPC 服务（积分RPC接口、图片鉴定RPC接口、数据分析RPC）。
这里就存在一些坑在这里了，当有新的业务要接入的时候，发帖服务就需要跟着做调整；或者某个RPC服务做了修改，发帖服务可能就会受到影响。服务之间存在严重的耦合，负责这块服务的人估计会很难过。
怎么解决以上的坑呢？我们只要引入一个消息中间件就可以解决以上的问题，结构变为这样：
发帖服务只需要跟消息中间件打交道，其他服务方也只需要订阅消息就可以了，各个服务之间的关系就不用再纠缠不清了。
小结
如果调用链上下文不存在强依赖关系，使用消息中间件不失为一种合理的选择。
