一、什么是消息队列（MQ）
MessageQueue 是一个广泛应用在互联网项目中且非常重要的技术， MessageQueue 通常被用来解决在高并发压力下类似于流量削峰、服务解耦、消息通讯、最终消息一致性等这样的问题。
二、什么场景下使用MQ呢？
MQ 可应用在多个领域，包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、手游、视频、物联网、车联网等。
从应用功能上来讲。例如：
日志监控，作为重要日志的监控通信管道，将应用日志监控对系统性能影响降到最低。
消息推送，为社交应用和物联网应用提供点对点推送，一对多广播式推送的能力。
金融报文，发送金融报文，实现金融准实时的报文传输，可靠安全。
电信信令，将电信信令封装成消息，传递到各个控制终端，实现准实时控制和信息传递。
从功能角度考虑：
MQ 在实际应用中常用的使用场景主要有异步处理，应用解耦，流量削锋和消息通讯四个场景
2.1 异步处理
场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种：
1.正常串行的方式
注册信息写入数据库
发送注册邮件
发送注册短信
总共耗时150ms
2.并行方式（开启异步线程）
注册信息写入数据库
注册邮件+短信
总共耗时100ms
假设三个业务节点每个使用 50 毫秒钟，不考虑网络等其他开销，则串行方式的时间是 150 毫秒，并行的时间可能是 100 毫秒。 因为 CPU 在单位时间内处理的请求数是一定的，假设 CPU1 秒内吞吐量是 100 次。则串行方式 1 秒内 CPU 可处理的请求量是 7 次（1000/150）。并行方式处理的请求量是 10 次（1000/100）
小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？
答：引入消息队列，将不是必须的业务逻辑，异步处理，改造后的架构如下：
按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是 50 毫秒。注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是 50 毫秒。因此架构改变后，系统的吞吐量提高到每秒 20 QPS。比串行提高了 3 倍，比并行提高了两倍。而且主流消息队列都支持集群，也可以解决处理慢的情况。
当然了，也不光注册这个场景，还有上传文件啊，解析Excel啊，都可以考虑引入队列，然后搞一个传输中心就可以了。
2.2 应用解耦
场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。如下图：
传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败，订单系统与库存系统耦合
如何解决以上问题呢？引入应用消息队列后的方案，如下图：
订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功
库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作
假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦
2.3 流量削峰
流量削锋也是消息队列中的常用场景，一般在秒杀或抢够活动中使用广泛。
应用场景：秒杀活动，一般会因为流量过大，应用系统配置承载不了这股瞬间流量，导致系统直接挂掉，即传说中的“宕机”现象。为解决这个问题，我们会将那股巨大的流量拒在系统的上层，即将其转移至 MQ 而不直接涌入我们的接口，此时MQ起到了缓冲作用。
2.4 日志处理
日志处理是指将消息队列用在日志处理中，比如 Kafka 的应用，解决大量日志传输的问题。架构简化如下
日志采集客户端，负责日志数据采集，定时写入kafka队列
kafka消息队列，负责日志数据的接收，储存和转发
日志处理应用：订阅并消费kafka数据
常用的日志收集架构有：
ELK/EFK
三、MQ产品对比
目前主流的MQ主要有：
RabbitMQ
RocketMQ
kafka
Activemq
3.1 MQ对比
**MQ**
**描述**
RabbitMQ
erLang开发（高并发语音），对消息堆积的支持不算太好，当大量消息积压的时候，会导致Rabbit性能下降。每秒钟可以处理几万到几十万条消息。
RocketMQ
java开发，面向互联网集群化功能丰富，对在线业务的响应时延做了很多的优化，大多数情况。而且由于是java开发，如果想进行定制化扩展也比较方便
Kafka
Scala开发，面向日志功能丰富，性能最高。当你的业务场景中，每秒钟消息数量没有那么多的时候，kafka的时延反而会比较高，所以，Kafka不太适合在线业务场景。
Activemq
java开发，简单，稳定，性能不如前面三个。小型系统用也ok，但是不推荐。
3.2 主流MQ的优缺点
RabbitMQ
RocketMQ
Kafka
Activemq
协议
AMQP
AMQP
自行设计
AMQP
跨语言
支持
支持
支持
支持
优点
单机吞吐量：
万级
健壮、稳定、医用、跨平台、支持多种语言；
功能支持：
MQ功能完备
高扩展性：
支持事务
单机吞吐量：十万级
可用性：
非常高，分布式
架构：
消息可靠性高
功能支持：MQ功能完备
高扩展性：支持事务
单机吞吐量：百万级
可用性：分布式的非常高
依赖ZK可动态扩展节点高性能高吞吐，消息可指定追溯
单机吞吐量：万级
可用性：非常高
功能支持：
MQ功能完备
高扩展性
缺点
Elang语言难度大，很难扩展,研发人员较少
目前只支持java及c++；
严格的顺序机制，不支持消息优先级，不支持标准协议
项目比较陈旧，官方社区在5.X之后对其维护越来越少
综合评价
适用于稳定性要求优先的企业级应用
阿里系，国内互联网公司使用居多
在日志和大数据方向使用较多
小型系统比较适用，但是因为维护越来越少，建议不用
中小型软件公司，建议选 RabbitMQ，一方面，erlang 语言天生具备高并发的特性，而且他的管理界面用起来十分方便。正所谓，成也萧何，败也萧何！他的弊端也在这里，虽然RabbitMQ 是开源的，然而国内有几个能定制化开发 erlang 的程序员呢？所幸，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的 bug，这点对于中小型公司来说十分重要。不考虑 rocketmq 和 kafka 的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以 kafka 排除。可以考虑阿里的 rocketmq.
大型软件公司，根据具体使用在 rocketMq 和 kafka 之间二选一。一方面，大型软件公司，具备足够的资金搭建分布式环境，也具备足够大的数据量。针对 rocketMQ,大型软件公司也可以抽出人手对 rocketMQ 进行定制化开发，毕竟国内有能力改 JAVA 源码的人，还是相当多的。至于 kafka，根据业务场景选择，如果有日志采集功能，肯定是首选 kafka 了。具体该选哪个，看使用场景。
我们在进行中间件选型时，一般都是通过下面几点来进行产品选型的：
1）性能
2）功能支持程度
3）开发语言(团队中是否有成员熟悉此中间件的开发语言，市场上此种语言的开发人员是否好招)
4）有多少公司已经在生产环境上实际使用过，使用的效果如何
5）社区的支持力度如何
6）中间件的学习程度是否简单、文档是否详尽
7）稳定性
8）集群功能是否完备
如果从以上 8 点来选型一个消息队列，作为一名熟悉 java 的程序员，当遇到重新选择消息队列的场景时，我会毫不犹豫的选型 rocketmq，除了监控管理功能不友好外，从其它方面来说，它真的是一款非常优秀的消息队列中间件。而且如果你的项目是用java编写的话，使用rocketmq在排错以及优化上，都可以自行进行定制。